Transitioning from Hudson to Jenkins is actually quite simple once you get into it. Whilst we were making our transitions we found some issues and some approaches to help speed things along in the future. Below are the bits of advice I thought most useful when changing to Jenkins. I hope you find them useful.
Do not install Jenkins along side Hudson
At first I had the bright idea that I could install Jenkins on the same box running Hudson. The thought was that I could slowly transition our tests across whilst the tests continue to run. However I was mistaken. When installing Jenkins it will find the Hudson directory and attempt to transition the workspace for you. At first this sounded perfect, and it would have been if I was running Hudson 1.395 or earlier. Jenkins will attempt to update the workspace regardless of the version but on newer versions the workspace may not work. On Hudson 3.3.3 I found that jobs had been created with the same names but they didn’t do anything. No other settings were moved across.
If you have to install and setup Jenkins on your Hudson box make sure you backup the Hudson directory first so you can roll back if needed.
Create a separate backup workspace first
If you are transitioning from Hudson to Jenkins or setting up Jenkins for the first time, this tip will be useful. This is more a personal choice of mine but I recommend creating a Jenkins workspace on a new box first. Get all of your jobs working as intended. I recommend setting up all the jobs you need even if they are intended to be on different boxes. Once done enter the Jenkins directory and make a backup copy of the jobs folder. This folder contains the config files for all the jobs and if copied into a new Jenkins workspace the jobs will be added for you. Once you have a copy of the workspace, search through it for all paths in the files. The paths will be absolute, alter them to have unique identifiers followed by a relative path. For instance.
Now you have a backup of the jobs, when setting up an additional box you can replace the identifiers with the new boxes path, copy over the jobs and enable the ones you wish to use. The great thing in Jenkins is that the workspace for jobs is not stored in the jobs folder, so creating this backup does require moving the code base of each job.
Document the Jenkins setup
When you first set up Jenkins, whether you are transitioning from Hudson to Jenkins or not, you should document every step. From the options chosen during the installation process to the plugins you add. Keeping a step by step guide of the Jenkins set up will make your life easier if / when you choose to expand your test suite to new boxes. The step by step guide will ensure each box is set up with the same settings and another it missed. If there is anything that you need set up outside of Jenkins, script as much as you can. Running scripts will cut down on the chances of losing a setting.
If you have taken my advice and created the back up jobs directory, ensure to include a list of identifiers and how to replace them in the steps. When we did this we found that the set up of Jenkins workspace took a day to manually create the different jobs, it took around 30 minutes to set up a new box using the backup jobs directory and a step by step guide.
Check your plugins
Once you have Jenkins installed double check the plugins available. Jenkins has a whole host of plugins to give you access to additional functionality. The ones you need or want will depend on your usage. The three I found most useful for our transition were.
MultipleSCM plugin – This allows a job to pull from multiple repositories.
Heavy Weight plugin – Allows a job to require a number of executors to run.
Python plugin – Allows you to write python code directly in the job instead of using a script.
I hope you have found these steps useful. Please feel free to tell me what you consider the top tips for transitioning from Hudson to Jenkins.
IDRsolutions develop a Java PDF library, a PDF forms to HTML5 converter, a PDF to HTML5 or SVG converter and a Java Image Library that doubles as an ImageIO replacement. On the blog our team post about anything interesting they learn about.