Although we often focus on the soft skills required to be agile, technical excellence is also a necessity. To me continuous integration is at the heart of any agile team. Below are a couple of questions to judge how healthy your build process is:
- Is the build status visible to everyone?
- Does everyone in the team (yes, including the testers) understand how CI works?
- Do you build on every checkin?
- Does CI run unit tests on every checkin, and other longer tests at least once per day?
- Does CI check out from your repository and tag or label so you know exactly which version it is?
- Does fixing a broken build take priority over everything else?
- Do developers only checkin code if the build is green?
… the goal of CI is to confirm that we have working software at all times …
If you answered no, this should be one of the improvement actions you are discussing in retrospectives. Remember the goal of CI is to confirm that we have working software at all times. If we can isolate what broke the working software down to a single checkin (hopefully of only a few lines), then it is trivial to keep the software working. Why is this important? Well the agile manifesto reminds us that working software is the only measure of progress. If CI is broken we have no idea of progress!
If you answered yes to all of these then you have the basics in place. Well done! Take a look at the points below to take your build process from good to great.
How many manual steps are there from checkin to code being deployed on a server with usable test data? Building, deploying and testing code is what the team do all day. Before you even think about test automation, this is where you should automate first. Even if this takes 15 minutes per build, imagine how much time that is in 1 day, 1 sprint, 1 month….
- Commit to reduce this by one step each sprint.
How long does it take for CI to go green after a failure? The longer CI is red, the more code gets written that is not guaranteed to work on CI. The bigger this code is, the harder it is to find issues when it does break.
- Commit to shorten this time each sprint.
How long does it take for a developer to get feedback that their checkin was successful, i.e. a green build? If this is more time than it takes to get a cup of coffee or take a short break, developers are likely to start working on something else, which means a context switch if the build breaks.
- Commit to speed up your build process by a few minutes each sprint.
Want to know more? Here is a link to a comprehensive article by Martin Fowler on continuous Integration: http://martinfowler.com/articles/continuousIntegration.html