Jenkins for successful deployments
For our latest blog post I wanted to write something about a service which we’ve been using at Big Blue Door for the last couple of years, and has really helped streamline and automate our workflow. The service in question is called Jenkins, and it’s an open source automation server, which can be configured to support building, deploying and automating tasks across projects. I won't go into all of the technicalities - I’ll leave that to the dev team for another day - but instead I’ll focus on the benefits from a delivery perspective.
Internally we’ve configured Jenkins to complete a number of tasks for us including:
Merging code to our demo sites - this allows project managers and testers to review and test code on our dev site and then independently merge code up to the demo environment and repeat testing there. After successful completion, comms can then be done with the client, requesting their review prior to any live deployment.
Merging code to the master branch - after testing within the demo site and receiving sign off from clients, we can quickly merge code into the master branch so it is ready for the next live deployment.
Rebuilding demo sites - our standard setup is that our demo sites rebuild content from the live environments overnight so that all our testing is conducted with the most up-to-date content for accuracy. There’s nothing worse than testing with content that is months old! This job however allows us to trigger a rebuild of the demo site from live at any time - particularly useful if a client is completing a big push of content building on live and we want to check how that will look with the latest code we have been developing.
Rebuilding dev sites - like the point above this job allows us to rebuild the content on the dev site from the content on demo. Again this runs automatically on a daily basis but can be triggered manually whenever needed.
Rebuild sandpit - some of our clients have a sandpit site as well as dev, demo & live. This can be a code branch or just a safe area where they can test out new content - often useful when whole new sections or significant IA updates are being developed. The main difference between the sandpit site and demo is that it deliberately isn't rebuilt overnight, so content persists for internal review for longer. Periodically and with a client's agreement the Sandpit sites do need updating, and this job triggers that.
There are various other jobs that we’ve created which help track any failed builds, disabled builds, crons jobs and so on. There is also plenty of scope to extend this functionality into other areas - Jenkins as a system is very flexible so really can be tailored to your needs. Here’s a screenshot of some of our current jobs and the interface to help put things into perspective.
You can see, for example, to the left hand side of the jobs listed that you can add in some visual aids to check on the status of each job. The green circle, for example, shows that the last time that job ran it was successful and the ‘sun’ gives an indication that no recent jobs have failed and that things are stable - again this type of feature is completely configurable to your exact requirements.
For me this is a great system from a project management side because once set up by a sysadmin you can really empower your testing and PM team to take ownership of their tasks without having to keep bothering the technical team for small routine tasks “Can you just merge the code up to demo?”. This alone has been a huge time saver for us. The configuration you see above can also be differentiated per user based on a permissions system. This allows you to easily grant a PM one level of access (rebuild dev, demo, merge code) but perhaps restrict access to the more sensitive items such as the cron jobs.
Taking this a stage further however, and onto live deployments is where we’ve seen some significant gains. Our live deployments are setup on a completely separate Jenkins system, allowing us again to restrict access across the team even further. This means that only a small group can push code to the live environment. As Projects Director for example, I can merge code to the master branch and then deploy to live. The live deployment system is restricted to Big Blue Door's secure VPN for extra security, and includes automatic rollbacks should there be an issue with any deploy.
Jenkins allows you to monitor the code output from all jobs that you run so you can watch new features being deployed to live, backups being taken and so on. The system can be completely customised to your preferences and it’s something I’d recommend all development teams look into (or an alternative system). Watching live deployments and viewing the initial check, to see all the features are in default state as well as backups being taken, is incredibly satisfying, and more importantly reassuring that we have everything working as expected.
The initial upfront investment in setting Jenkins up was certainly a considerable one for us, including a separate server, sysadmin resource to install Jenkins, as well as creating the individual jobs, but it’s a decision that has saved us so much time in the long-run and helped streamline our workflow, meaning it’s certainly one I’d recommend to others.