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?
>
