Hi,
I'm very interested by your plugin. have a git repo to follow your updates?
In advance, thank.
Le vendredi 13 juillet 2012 15:34:41 UTC+2, mpapo - Michaël Pailloncy a
écrit :
>
> Hi,
>
> Even if our goals are not the same, it seems that you need same
> functionnalities.
> I'm currently developing a plugin equivalent to your first idea ("Job
> Comparator Plugin") with the ability to merge parts of a configuration file
> manually.
>
> Then, it could certainly evolve into one of yours ideas.
>
> Michaël
>
> 2012/7/11 Daniel PETISME <[email protected]>
>
>> I'm also interested by such feature, there is my use case.
>>
>> 2 different organizations : Customer - Exploitation supplier. 2 Jenkins
>> instance identical (ie: 2 masters but same infra) aim to continuously
>> deploy on target environments (Dev, indus, Prod,etc.). The target
>> deployment environments should be identical.
>> Of course, the 2 organization don't have the same deployment process.
>>
>> *Customer:*
>> Deploy its app on its own environment thanks to Jenkins. Once it's good,
>> the customer tag the app and the jenkins job to the SCM tool and
>> communicate the tag name to the supplier
>>
>> *Exploitation:*
>> Pick the tagged Jenkins job, customize it and deploy the application
>> thanks to this job.
>>
>> An issue appears when the customer has to re-deliver an application and
>> the job has been updated. The Exploitation has to re-start from scratch.
>>
>> *List of the exiting tools already considered:*
>> The job config history plugin allows to make diff between the different
>> version of a job. IMHO, it must use to trace the change than to do roll
>> backs.
>> The job import plugin: allows to copy jobs from an instance to another
>> but it doesn't keep trace of the original job. The 2 jobs are totally
>> independent.
>> The SCM sync plugin: a config history++ it allows job versionnning and
>> rollbacks.
>>
>> *Ideas*:
>> *The easiest one
>> *Do the merge by hand each time.
>
>
>> *MDA approach*
>> Inspired from the Model driven architecture. If define job archetype on
>> all the instances (models) we should be able to apply a sort of
>> transformation to swicth from an archetype to another?
>>
>> *Work by increment*
>> Reconsider the concept of copied job. Instance of copy the whole
>> config.xml into a new_config.xml, we can imagine to reference the original
>> copied job and keep the increment.
>>
>> E.g: My_JOB_MVN3.xml = My_JOB_MVN3.xml + INCEREMENT.xml
>>
>> Instead of copying My_JOB_MVN3.xml we can image to have a repository of
>> jobs, and the increment just store the delta.
>>
>> *Object oriented approach*
>> The aim is to use inheritance for default values and override specific
>> behaviors.
>>
>> What's your thoughts?
>>
>
>
