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. If that all sounds like
goobledegook to you, or if it makes sense but you’ve never used anything like it then
this post is for you.
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 a lot of people. Here’s what might have happened in an
average working day pre-Jenkins:
It’s a slow, error prone, painful process and we haven’t even talked about deploying to staging or live environments yet. A major problem is also that a lot of people are unsure what the exact state of the project is because they never know if what they’re looking at is up to date.
Jenkins to the rescue!
Here’s how that above process would work with Jenkins running.
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 awardwinning
application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.”
So Jenkins is a tool that can be used to do any kind of repetitive task, but the added bonus of Jenkins is that these repeated tasks can be monitored and report information and make it easy for people to initiate these tasks or have them initiated automatically.
So for example, you might have a .Net project which is the server aspect to a project with iOS and Android apps. Jenkins can build and deploy the .Net project whenever changes are made so the latest version is available. The iOS and Android applications can also be built when code is changed and can be deployed via tools like TestFlight.
The “continuous integration” part comes into play when you have multiple developers working on a project. Jenkins is constantly building the latest version of the project from all developers' code so your work is being integrated (and deployed) continually.
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 would for a .Net project with a simple HTML/CSS/JS frontend codenamed
If any of these steps fail, then Jenkins will send an email with details of the problem to people involved in the project and most importantly to the person who wrote the last piece of code that may have broken the build.
Setting up jobs for Android and iOS applications is very similar and follows the pattern of “get code”, “build code”, “deploy code”.
There’s even a Chuck Norris plugin to give you extra feedback about the state of your jobs. Now really, what more could you want?
I’ve described a basic, but powerful Jenkins job set up. This will do a lot for you, but it can be taken further.
The kind of things that you can get Jenkins to do that might be useful for you are:
There are lots of other tools similar to Jenkins of varying complexity and approaches. These tools are becoming increasingly popular as cloud services which can handle platform
configuration and provisioning as well as the code deployment aspect.
Jenkins has always worked well for me. It’s not the best looking tool, but it has a large
community, it’s simple but can be complex and it has a load of plugins for it.
Hats off to Kohsuke Kawaguchi and the Jenkins team for building us something so useful.