Backup and Store Jenkins Jobs and Configuration in Source Control such as GIT or SVN

Issue

  • I would like to automatically check-in and backup my Jenkins jobs via GIT. How can I manage separate masters with different jobs that move between the masters?
  • I would like manage plugin versions in a source control system.

Environment

  • CloudBees Jenkins Enterprise
  • CloudBees Jenkins Operations Center

Resolution

There are several options, depending on your organization’s SCM configuration and specific needs:

1) Use CloudBees Backup Plugin to take a “Local directory” backup which would be a snapshot of your $JENKINS_HOME/jobs/ directory. From here you can store the data in SCM for version control/history and disaster recovery purposes.

2) Use the Workflow MultiBranch Feature
provided by the Pipeline Plugin. It requires the workflow
definition to be stored in a Jenkinsfile in the project and will use it to build your project. As the job configuration
is stored in the SCM, it can be moved to another master.

3) If you need to perform backups of your masters, you could also use a Cluster Operation
on your CloudBees Jenkins Operations Center
instance to generate and gather the backups on all connected masters.

4) To capture plugin versions on your CloudBees Jenkins Enterprise (Client Master), you can use the run the Jenkins CLI to do this:
java -jar jenkins-cli.jar -s ${JENKINS_MASTER_URL} list-plugins
(append > myinstance_plugins.txt " to this command to capture the output as a text file, from which you can check-in to source control)

If you have CloudBees Jenkins Operations Center, you can similarly capture plugin versions:
java -jar jenkins-cli.jar -s ${CJOC_URL} list-plugins

This command will return the job definition XML to stdout which includes the section that does contain all of
the plugins available on the Update Center:
java -jar jenkins-cli.jar -noKeyAuth -s ${CJOC_URL} get-job CustomUpdateCenter

Have more questions? Submit a request

1 Comments

  • 1
    Avatar
    Lee Meador

    Two questions:

    1) Why the "multibranch" pipeline? Wouldn't the plain pipeline work?

    2) Where is the list of files that need to be saved? If the pipeline job is going to collect the files, we need information on which files.

    Perhaps the strategy is to take the latest zip or tar.gz file created by the backup job and update those in the scm. If so, it would store all the hpi and jpi files for plugin AND why would you need a list of plugins with versions. Further, hpi, jpi and war files aren't really good subjects for inclusion in an scm (as aren't most binary files). So, if the strategy is to use the backup zip/tar.gz, which files should be left out.

    I think this article needs some more detail so everyone doesn't have to duplicate the efforts.

Please sign in to leave a comment.