Ed Gibbs talks about the pain of not insisting that builds be buildable from any environment.
Tag Archives: build
Will The Build Bottleneck Put The Brakes On Agile?
There is a great article in the SD Times called Will The Build Bottleneck Put The Brakes On Agile? which talks about the use of both version control and an automated build process in which to receive feedback on the “health of the software” more frequently.
Our group has used Open Source products for this kind of thing for a few years (I think we started using CruiseControl at version 1.0, as Keith and I tend to be those “high risk”, early adopter types) with excellent results. The ability to have the software you are developing automatically build from source to deployment packages (we have both the traditional tarballs and ISO images for a Windows product) is an excellent way to remove a ton of unproductive manual labor from your processes and get builds to QA.
One of the great features of this kind of system that isn’t really publicized in the article is the ability, upon build failure, to notify the committers to the current build that a build failure has occurred. This allows a proactive response to these kinds of failures rather than the typical “one guy watches the build and hunts down the guy who broke it” process that most companies normally go through when one person handles build duties.
The other nice thing about this? It makes it really easy to rotate “buildmaster” duties throughout the department. In our case, we built a system around the open source tools in order to help people manage the build, and utilized functionality in CruiseControl like the JMX interface in order to allow people to kick builds without having physical access to the server. This allows us to control what is going on with the server, but still allow anyone with sufficient role based permissions to access the system in order to manage the day to day activities around a build.
We have also implemented CodeStriker, an online code review tool in order to try and keep people out of meeting rooms and give them the ability to comment on source code at the line level, per project, from wherever they happen to be at the time. This has been another really great addition to our process and has reduced the amount of paper each person had to fill out during a code review. We now have documentation of all items raised during the reviews, who raised them, and what the status is of each. The tool also provides full integration with CVS and Subversion.
I’m glad an article like this has come out. These sorts of automated processes need to become the norm in order for IT to be able to get out of the rut it has been in for the last few years in which the manual effort required to produce a software release prevents it from delivering on the things the business needs. Read it. Think about it. Then give it a try.
Here’s some software resources to get you started:
- CruiseControl – Build Automation Software
- Apache Ant – Build Tool
- Subversion – Version Control System
- JUnit – Unit Testing Framework for Java
- CodeStriker – Online Code Review Tool
Keith, did I leave anything out?