Recently, I was having a discussion about automated build systems with a colleague. Primarily, we were talking about how important they are for Agile projects. As most of us have, I have witnessed varying levels of usage when it comes to automated build processes.
Looking at the software projects I have been involved with one message is clear…. the better and more frequent run the automated build system the higher the quality in the delivered product. Additionally, the risk is a signficantly lower as well.
In this discussion, I will not get into the specifics of a particular automated build system. I will focus on the reasons to have one.
An automated build system, gives the team a consistent daily goal – complete the work you agreed to do in your daily stand-up, get it unit tested with the testers by your side, commit the code, and make sure it does not break the team’s daily build. Perhaps, this does not need to happen every single day, but certainly many times per iteration.
Each engineer typically works on their parts of the product independently. This is almost always done in their own version of the checked out code. Since each engineer does not test the entire product every day. There is a certain amount of work that must be done when integrating the code. The smaller the amount of code to integrate into the main source tree, the easier it is. Its kind of like when you write a few hundred lines of code without compiling and you are presented with thousands of errors with the first compile. Just as compiling more frequently helps developers pinpoint problems faster, building the entire product helps the teams solve problems faster.
One of the most risky and painful parts of a waterfall project is that time when the code is all written, management has been told the code is 90% done (been that way for weeks), the only thing left to do is pull the pieces together and get the product into QA. However, when all of the individual code pieces are integrated together, a severe problem requiring weeks of refactoring is discovered. At this point, both the date and quality have been compromised. It is very difficult to achieve the true benefits of Agile if this same challenge occurs. Code integration must be frequent.
Recently, I heard of a situation where one of the teams was “accepting/completing” stories that were build on developer machines. The problem with this is the code that is “accepted” may not function the same way when combined with the code from other developers’ machines. The risks here are two-fold. First, teams could find themselves slipping dates as they are going through hardening or even worse having “dead on arrival” defects actually reach their consumers.
To me the best possible situation is to have a nightly build system that does the following:
- Builds all the target images automatically
- Creates an installable image
- Runs and automated installation
- Automatically conducts some basic tests
- Notifies the “entire” team if a problem occurs anywhere along the way.
As I write this, it occurs to me I could go on for days about the benefits of having an automated daily build system. However, I believe the point is made here. If you have an Agile project (actually any software project) and are not integrating and building your code every day, I recommend you do so. I was in charge of one project where when we added automated nightly processes, the change in team mindset and quality of committed code was earth shattering.
One closing comment on “build engineers”. Find a good one. Often times teams will assign members with less experience to be the “build engineers”. Having a solid build process is critical to the success of your project and should be staffed with the appropriate capabilities.