Hi folks ! Just dropped in this old thread while searching in my mailbox ...
I'm the maintainer of the SCM Sync config plugin and I would love you provide your use cases/POV in the Two way synchronization topic<https://issues.jenkins-ci.org/browse/JENKINS-8527> on JIRA. Frédéric Camblor <http://fcamblor.wordpress.com/> <http://www.twitter.com/fcamblor> Bordeaux JUG <http://bordeauxjug.org/> Board member Jenkins <http://jenkins-ci.org/> community member & plugin commiter Frédéric Camblor <http://fcamblor.wordpress.com/> <http://www.twitter.com/fcamblor> Bordeaux JUG <http://bordeauxjug.org/> Board member Jenkins <http://jenkins-ci.org/> community member & plugin commiter On Wed, Jul 11, 2012 at 1:16 PM, Daniel PETISME <[email protected]>wrote: > 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? >
