Promote jobs from test -> staging -> production

[Jochen Hinrichsen]

Dear group,

we want to follow the same rules for Jenkins jobs that our software itself must confirm to: development in test, testing in staging, and the official version in a production environment. Copy and paste will always work, but i'm too lazy to do that for the 200+ jobs. Maybe something more git-ish?

From a first glance, i can see that everything credential related is different in the underlying xml configuration files. So a plain 1:1 copy of a job's external xml representation will not work.

Did someone out here already solve this problem?

Thanks in advance

Jochen

[JESSE_...@homedepot.com]

Jochen,

 

Here are a couple of approaches. They don’t reach the level of “solved” but food for thought:

 

Generate the xml from scratch every time. Downside is maintaining the domain-specific language, software, and accounting for the changes from one version of Jenkins to the next (as you mentioned with credentials).

 

Create several Template jobs for each job profile (disabled) in each instance (test, staging, production). Create copy-and-minimally-mutate programs that update only the relevant portions. Downside is similar: maintaining the DSL, the software, and making sure it works with many versions, and also assumes a kind of uniformity in your jobs. Also might be hard to update those already-mutated jobs.

 

Cheers,

 

Jesse

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/732d0cd3-a3de-4ee2-8c59-3fc96d991659%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

---

The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.

[Maciej Jaros]

Jochen Hinrichsen (2015-03-18 12:08):

Dear group,

we want to follow the same rules for Jenkins jobs that our software itself must confirm to: development in test, testing in staging, and the official version in a production environment. Copy and paste will always work, but i'm too lazy to do that for the 200+ jobs. Maybe something more git-ish?

From a first glance, i can see that everything credential related is different in the underlying xml configuration files. So a plain 1:1 copy of a job's external xml representation will not work.

If you have 3 Jenkins installations that are identical (i.e. two of them have jenkins-data folder copied at first) then you could simply copy config.xml between them. I'm not sure which of the files is used for credentials encryption but my wild guess is that its the `secret.key` file ;-).

Regards,
Nux.

[James Green]

Going off topic rather...

I just spoke out loud in our office the fragment "develop in test, test in staging, and run in production". Consensus here is that as an industry we have the names wrong. After all, non technical bosses expect testing before "going live", they have no idea what "staging" is intended to mean and frankly the term probably won't mean anything to many developers out there today.

... And back to topic.

--

[Jim West]

hi Jochen,

  Take a look at jenkins-job-builder. With templates and macros you you'd be set. We use this almost exclusively at work with 500+ jobs and it works great.

  Job descriptions are yaml files that we keep in git. Version controlled jobs FTW!

-jimW

Sent from my iPad

--

[Baptiste Mathus]

In the same area, there's the great Job DSL plugin https://github.com/jenkinsci/job-dsl-plugin

And congrats btw to Daniel Spilker & others, the plugin is absolutely great: works just perfectly, is moving fast and the doc is amazingly constantly up-to-date and complete.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/D6077E84-F7D7-40CE-9DEF-5BA58975AD5D%40jameswest.com.

For more options, visit https://groups.google.com/d/optout.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Jochen Hinrichsen]

Jobs as code - beautiful. Not to say that yaml doesn't cut it, but being a happy Gradle user the job DSL hits the sweet spot.

Awesome tip, thanks!