Build Process Automation
Defining the Build
Any non-trivial software project can benefit from a standardised, formal build process. Delivering quality software requires that you have a quality process for producing the deliverables. Performing the steps involved in producing those deliverables manually is prone to error.
Defining the build process is something that should be done very early on in the development effort. Team development requires careful planning, and part of that planning should include the process to build deliverables. In many development teams, daily builds are used to provide a way of ensuring that the project is not missing its target. Daily builds help developers ensure that the project can deliver something at any time during the lifespan of the project. Quite often, when developers are working on different parts of the application, breakages can occur when those separate efforts are checked into your source code version control system (you are using one I hope!). Of course when this happens, it can result in down time for the rest of the team while those breakages are fixed. These sorts of breakages are often only discovered when you attempt to build the entire project from the latest version of the source code.
There are many tangible benefits in doing daily builds:
- Minimise risk : find out about incompatibilities when they occur. This makes it easier to manage these incompatibilities and easier to fix.
- Improved quality : The product is always in a usable state, so less time is spent dealing with quality issues later in the development cycle. This also allows testing to start very early in the development cycle, making it easier to deal with usability issues that testers may raise. When a bug is fixed, testers are able to verify that fix quickly.
- Speed up bug fixing : it is always easier and quicker to fix bugs when they appear rather than later, when more code may have to be examined to find the bugs.
There are no hard and fast rules on when and how the builds should be done, however, here are some suggestions to help you on your way:
Build at Noon Why? Well put simply, it's the least productive hour of the day, lunch hour. Have the developers check in any changes they have completed (more about this later) before noon, then who ever is responsible for the build process can kick off the build before they leave for lunch. Building during the day means that issues that arise from testing of the build can be addressed as soon as possible, while they are still fresh in the developer's minds. If the daily build is ok before the team finishes for the day, then no time need be wasted fixing it the next, the team is not held up, unable to compile because of some broken code checked in the previous day. Of course if the build takes too long then building during the day may not be practical.
Use robots, not people - Humans are not very good at repetitive tasks, often performing steps out of order, or missing steps altogether. An automated build process overcomes this by being able run the build process in a repeatable manner. And it doesn't get bored easily!
Build all, or not at all : "The Daily Build" should build the entire project, compiling every line of code in the project and produce every executable, dll or library. In other words, the build process should be producing all the deliverables that can be produced at the time. This avoids issues involving compatibility between dll's etc.
If the build fails, fix it and then build again - the longer issues that cause a build to fail are left, the harder they become to resolve. Fix the problems (be they erroneous code or design issues) as soon as possible, don't leave them on some todo list waiting for someone to remember to do it!
Label successful builds in your version control system - if your vcs supports the concept of labelled versions, then make use of this feature. This make it easier to revert to a "known good build" when things go horribly wrong or when some weird impossible to find bug rears it's ugly head.
Archive the binaries for each build - This will help you find those weird an impossible to find bugs. You can simply test the applications to find out when the bug began appearing, and along with labelled versions in your vcs, will give you a starting point for code changes that may be the cause of the problem.
QA the Build
Of course, doing a daily build is pointless unless there is some QA done on the deliverables. Early on in the development cycle, this will usually involve just making sure that the program loads and runs and that there are no show stopper bugs. As the project progresses, this QA process should be stepped up to exercise the entire application.
In some teams and projects, doing a daily build may not be practical. The main thing is to build often, and when you do build, do a complete build, if not daily then every second day or weekly. The less often you build the less the benefits outlined above will be realised.
Speeding up the Build Process
Why do you need to speed up the build process? Well, the closer you get to completing the project, the more often you will need to build, fixing those last minute bugs that always seem to crop up. If doing a build is a long complicated process, you won't be able to react to these last minute bugs very quickly, and it's quite likely that a mistake will be made somewhere.
There is only one practical way of speeding up the build process and that is by automating it. For simple single executable projects this may not be necessary, if all you have to do is load the project in your development tool's IDE and click on the build button. But for any projects that involve more than one step to arrive at the point where you have the deliverables (most often this will be the installation program), automating the build process is a must! You can of course not automate at all, and just document the steps that need to be done. That will work fine, provided the steps are followed in correct order and none are missed.
Reliability
An automated build process can help introduce a level of reliability that is impossible to achieve with a manual build process. A mentioned before, humans are really not very good at boring, repetitive tasks. How many times have you shipped a project deliverable only to find out (when a user calls up) that it has the wrong version of file, or a file is missing or the program install falls over because of a mistake you made during the build process.
An automated build process (once defined) will not make mistakes. If a file is missing, the build process can be stopped and the relevant people can be notified of the error. Once the error has been rectified, the build can continue. An automation tool can do the build over and over, exactly the same way as before.
In short, an automated build process can improve the quality of your software deliverables, and decrease the time to market.