Continuous Integration

Print Friendly, PDF & Email

We now have an official Continuous Integration server hosted at It is restricted to UoB login via CAS Single Sign On. I have added a couple of people to access the server with full rights; Ed Crewe, Chris Bailey and myself. The idea to start with is to have an open access policy within Web Futures and Internet Development teams. This is so that anyone can create projects and jobs independently or as part of a project. We can review that process as we go. There may be a number of things that we will want to do to allow for builds to be successful, such as tools and modification to hosts. We can treat these on a case by case basis.


The basic model of CI is that you want to always build from a source code maintained repository to a staged deployment environment in a fully automated fashion with tests along the way which will halt the deployment process until fixed. You can add SVN repos yourself, try to manage tags for staged deployment phases of “dev”, “test”, “demo”, “train” and “prod”. You may just want to push automated builds to test and work freely on dev. You may want to always rebuild dev and work from a locally checked out copy of code on your workstation. Always push in a fully automated fashion to “test” so as to weed out any problems before going on to the next stage. If any discrepancies or errors are found write a test of some description and redeploy back to “test”. Once you are building without errors you can redeploy to one of the stages considered to always be stable; demo, train and prod. Whichever is relevant for the stage of the project you are working on. Try to do this as often as possible after each small batch of changes to keep the distance between steps of changes short. The time between deployment will differ depending on the project and how fast you can deploy. Keeping the deployment time as small as possible will allow for more freedom of development. Filtering the build process through these stages in this way should iron out glitches and make for a robust prod environment.

In terms of deployment mechanisms, for now, we are still encouraging the use of our existing scripts and methods. I’d like for people to make use of Bcfg2 wherever possible for pushing changes and would be very happy to open up access and guide you whilst starting to use it. Please, do feel free to drag me to one side to discuss whatever method you go for. The important thing is that we communicate about how we manage change. You may want to create mailing lists for commit logs to be broadcast to team members whilst you work and for build results to be sent out. Make a point of catching up regularly to discuss how things are going. Please, again feel free to include me in these discussions as it’s important for me to know how things are going and if this is working. Speeding up the processes for getting change on to servers may make the difference in this being successful.

In the beginning we will have problems with builds to prod which will require us to manually fix the prod site. For the being time we’ll allow SSH access to servers to do this, but the goal in time is that we do away with the need to manually fix things on prod and therefore SSH access. We’ll likely need to make some modifications to the way OS deployment is set up to better synchronise the system states the different staged machines will be in. We’ll also need to increase exposure to reporting and logging information.

I hope to test and deploy code from bcfg2 in a similar way, migrating from the current svn-commit-hook trigger and push to Jenkins. The form this will take is yet to come but I’m thinking something along the lines of specification code checkout, test syntax and client builds on dev/test hosts, possibly followed by some flavour of tagging in svn, then stamping a systems Business As Usual flag somewhere to signify it’s safe for clients to pull changes down or maybe use the existing fabric script to trigger an update across all hosts. If at any point where a build fails the BAU flag is set so no client can update until the build process is fixed and a manual reset of the flag is made.

Any comments on this are very welcome.