How I learned to stop worrying and love Jenkins - Specialmoves

How I learned to stop
worrying and love Jenkins

Specialmoves Labs

Written by Sunil Jolly,

I’ve written about Jenkins before but felt that a broader description of how we use Jenkins would be good to share. It’s interesting how many places still don’t use continuous integration tools like Jenkins and how many places don’t automate their deployment systems. Hopefully this will help them get started. We’d love to hear about people’s experiences of Jenkins and how they use it.

Life before Jenkins

Before we talk about Jenkins I think it’s worth talking about my experience of life before Jenkins, which will be familiar to most people! Here’s what might happen in an average working day.

  1. I would write some code and commit it.
  2. Occasionally a project manager or designer or someone equally focussed on interrupting my programming would ask to see the latest version of the project.
  3. I’d update my code and show him and then he’d ask if he could test it somewhere.
  4. I would then interrupt someone in charge of deployment and would ask them to deploy it somewhere.
  5. This person would probably groan (because they’re in the middle of something) and say that they could do it in 15 minutes.
  6. The project manager would roll their eyes and sit at their desk reading emails or updating a GANTT chart (or whatever project managers do) for 30 minutes (because the task the developer was doing took twice as long as expected).
  7. The deployer would open his FTP program and copy files up to the dev server, maybe missing a few files the first time and then having to do it a second time.
  8. The project manager would complain the work he wanted wasn’t there.
  9. The deployer would realise he hadn’t updated his code and do the process again.
  10. Three hours later the same thing the process would start again…

Phew! What a load of distractions for everyone. We haven’t even talked about deploying to staging or live environments yet. In among all of that things might break at any point, or deployments might go wrong and without a definitive version of the latest site nobody is sure what the exact state of the site is.


Jenkins to the rescue!

Here’s how that above process works at Specialmoves with Jenkins

  1. I write some code and commit it.
  2. 5 minutes later the code is on our dev environment without anyone having to do anything.
  3. The project manager looks at the dev environment knowing it has the latest work.
  4. When something breaks you can look at the dev environment to check the latest version.
  5. When QA or the project manager is happy with the build on dev, they click a button to deploy it to staging.

Simple! (I even added an extra staging deploy part in there to look extra clever) 

So, what is Jenkins?

The Jenkins CI (that’s its proper name) website describes it as “an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.”

What that means for us at Specialmoves is that we can get Jenkins to build our DotNet and Flash/Flex/AIR projects and deploy them for us, repeatedly and easily. This fits into Continuous Integration (CI) because Jenkins is constantly building and deploying the project. i.e. the dev site has all of everyone’s committed code continually integrated into it. 

I’m not going to get too deep into technical details since you can get those from the Jenkins website or via the excellent “Jenkins: The Definitive Guide” book but I’ll talk about what Jenkins does, step by step for a project like the Specialmoves (codename ‘Zeus’) website.


  1. In Jenkins there is a “Zeus” job which has the URL to our SVN repos for the specialmoves site. It checks out the project to a workspace for that job. Every 3 minutes it checks for updates and when it finds new code it triggers a build.
  2. Developer commits their code. 
  3. Jenkins detects the change, updates its workspace and triggers a build.
    The build part of the job uses a MSBuild plugin which you point at the .sln file for the project. It will build the project for us.
  4. Jenkins deploys the site to the dev environment,  using a FTP task to a specified server and directory. The dev environment now has all the latest code so everyone can see what’s going on.
  5. Set up a "Zeus - Staging Build" job which builds the project and deploys to the staging environment

It’s not difficult to do. The Jenkins install process is very quick and I reckon a newbie could get this kind of thing going in under an hour.

For a large project we maintain, we’ve expanded this into multiple Jenkins jobs to handle Flash builds and deployments to our CI, Dev, Staging and Live environments. It’s hard to imagine what we’d do without Jenkins.

We’ve also got tests and code quality tools running on Jenkins. But most importantly we have the Chuck Norris plugin running.

What next?

Our build and deployment set up is constantly evolving and although we’re getting better there’s still loads to do. On our list of things to get done are:

  • Create full pipelines from dev to live, passing a single build along that pipeline
  • Integrating JIRA (our task tracking tool) with Jenkins so that every build updates JIRA so that it’s clear what new functionality has been deployed. This is great for indicating what functionality is on each server too.
  • Having better data migration. Currently there’s still a manual aspect to our database handling which causes blockages in the pipeline

There are other tools similar to Jenkins such as Bamboo (which integrates into JIRA nicely), Cruise Control and Team City. We use Jenkins because it does everything we need and the community is great.

Hats off to Kohsuke Kawaguchi and the Jenkins team for building us something so useful. 

--- 

Sunil is Head of Development at specialmoves where he tries not to worry about deployment. @sunilj0lly

Follow us on Twitter @specialmoves