Jenkins Plugins - part III - Towards Continuous Delivery

This is a continuation of my mumblings about useful Jenkins plugins (see previous posts here and here). As we progress towards continuous delivery I learn a lot about new plugins.

Today I would like to present few more plugins, which are really, really helpful especially for build pipelines. A lot of what I put here I learned from the following sources (kudos to the authors!):

OK, to the point now.

  • Exclusion plugin, https://wiki.jenkins-ci.org/display/JENKINS/Exclusion-Plugin Very useful if few build use the same resource - e.g. a test database. All you need to do is to update configuration of all jobs using this resource and as a result they will never run in parallel but wait for others to complete.
  • Parametrized Build, https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build extremely helpful for more sophisticated jobs. For example, our deployment to test and production environment takes advantage of this plugin, by providing options which allow to parametrize deployment. For example we can choose if we do a full deploy or a predeploy (which means we only upload artifacts to servers), which modules should be deployed, should db be cleaned (on test env, of course) etc. There are also some default values set so the same job can be used to deploy automatically.
  • Build Name Setter Plugin, https://wiki.jenkins-ci.org/display/JENKINS/Build+Name+Setter+Plugin allows to name your build using some patterns, for example the name of my builds now provide information about:
    • what was it - compilation, integration-tests or maybe gui-tests
    • what SVN revision was used
    • build number (incremental)

    example names are "gui/1234-24" which means that these were gui tests, from SVN revision 1234, and that it was 24th build of this job.

  • Clone workspace, https://wiki.jenkins-ci.org/display/JENKINS/Clone+Workspace+SCM+Plugin A must-have if you plan to create some build pipelines. It allows you to reuse workspace of one job for another job. For example, you can have one job running mvn clean compile and two other jobs reusing its workspace and running unit and integration tests respectively. What for? First, it allows you to build always the same SVN revision. Second, it allows to divide large task into several smaller.
  • Build Pipeline Plugin, https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin It does a nice randering of downstream jobs, so you can really see your pipeline and watch the progress of build.
  • Join Plugin, https://wiki.jenkins-ci.org/display/JENKINS/Join+Plugin which allows to express things like "run job C after A and B are finished". This lets you run A and B in parallel. For example this is how our unit (A) and integration tests (B) are run, and then a WAR package (C) is created. There is an minor issue with Build Pipeline Plugin (see above) - everything works fine but jobs after join are displayed twice on pipeline view which doesn't look nice.
  • Parametrized Trigger, https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin Allows to pass parameters from one build to another. The way we use it is to pass SVN revision from the first build in our pipeline to all other builds, so we can set meaningful build names (using Build Name Setter Plugin).

So all this is used to create a nice pipeline which consists of few small jobs. The main point is that they all operate on the same SVN revision (the first job does mvn clean test-compile and the rest of jobs reuse its workspace). Nice.

Well, we haven't finished yet (still a lot to do before we can claim to have continuous delivery) but this build pipeline on our Jenkins serves us pretty well. :)

 
 
 
This used to be my blog. I moved to http://tomek.kaczanowscy.pl long time ago.

 
 
 

Please comment using