The Art of Build Automation
Written by James on Tuesday, 18 of September , 2007 at 8:33 am
Build automation is the foundation of continuous integration. Continuous integration helps to identify problems quickly - sometimes immediately - before they delay your project. Whether a continuous integration build is executed immediately upon check-in or scheduled to run nightly, at the heart of it lies the automated build process. (For an excellent, detailed article on continuous integration, see Continuous Integration on Martin Fowler’s website).
So how does one create an effective automated build process? Just like any other project, stay agile: start with fundamental tasks, then add complexity based on the needs of the project. Don’t get stuck creating the Ivory Tower of build processes.
Start with the Basics
The most fundamental steps of an automated build process are:
- Get the code.
- Compile the code.
- Report what happened.
Between compile the code and report what happened, some choose to add deploy; however we’ll cover that in the next section, Baby Steps.
Get the code. Most version control tools, such as Subversion, are relatively easy to automate. Early versions of your build process will probably check-out the most recent version of the code from the trunk. However, as the process continues to develop, it may look to specific build branches in the version control repository or to specific revisions. Be sure that your script checks out all the code needed to successfully compile, including any shared libraries. If supporting shared libraries is too much of a chore, be sure to look into the practice of using externals (don’t just make copies of everything!).
Not using version control? Well you should be.
Compile the code. This is the most basic test of your code - if it doesn’t compile, it’s just text. When scripting this part of the process, keep in mind the correct build order, compiler options, and other switches (is this a debug, test, or release build?). For example, you probably want to enable detailed logging in test builds and probably always want to build the installation project last.
Report what happened. Some choose only to report errors, quipping “no news is good news.” This is true until you discover there was an error sending out error reports. So I recommend reporting everything that happens, even if it’s just to say “everything went well.” The report its self can be in the form of an email, an update to your projects Wiki, an entry in your tracking system, or all of the above. (To give an interesting example, I once saw a traffic light being used - red for complete failure, yellow for warnings, green for success).
Unless your project takes a long time to compile, these three basic steps probably won’t save you a lot of time. However, they do lay the groundwork for the more time-saving features that are further discussed below.
Baby Steps
Once the basics are done there are a few simple, arguably fundamental, features that should be added to the process to save amazing amounts of time. Some of these essential tasks are:
- Unit test
- Document
- Deploy
Unit test. If you are, or want to be, an Agile team you have probably already implemented unit tests using JUnit, NUnit, or a similar framework. If you are not unit testing, pick up one on of the Pragmatic Unit Testing books to find out what you’re missing and how to correct the situation. If your unit tests are already automated via a framework, simply call them during the build process. Make sure to be aware of tests that will interfere with external environments and only call such tests when it is safe. The XUnit frameworks have ways of categorizing and tagging each test and groups of tests, so identifying the correct tests to execute should be an easy task.
Document. If you are using a tool such as Javadoc, NDoc, or SandCastle then your automated build process is the ideal time to extract documentation from your code. Documentation extraction can be a lengthy, boring process that utilizes a significant portion of your CPU so it’s great when it can be done automatically for you on another machine or at least while you’re away getting coffee.
Deploy. This can be as simple as copying files to a “latest version” directory or, as your build automation script evolves, can become a full-blown installation complete with test data generation. Better yet, several installations could be created to represent common [test] environments. In some instances “deploy” is actually a live deploy; I’ve most commonly seen this used for content-only updates to websites.
Taking it to the Next Level
By now your build process should be helping out a lot: Developers are spending less time trouble-shooting and more time coding and QA is spending less time setting up environments and more time testing. So what next? Here are some ideas:
- Expand what you already have
- Get the timing right
- Enhance communications
Expand what you already have. Just keep improving what’s there, adding a tweak here and a nudge there to the existing build process. Improve reporting by hooking up that traffic light or updating that dashboard. Expand testing by adding all of your automated test suites (stress tests, integration/system tests, etc.). Continue to improve the deployment process by introducing virtualization, generating random test data, or synchronizing development, test, and production environments.
Get the timing right. As you expand what you already have, the build process may begin to take too long. You will also notice that not everything your build process does needs to be done every time. This is the time to start separating out different “types” of builds, and executing them when necessary. For example, a unit-test build can probably run on every check-in or several times a day; however a build that runs stress tests may need to run nightly so that humans aren’t bothered by bogged-down systems. This may also be the time to move to a build-server if you haven’t already.
Enhance communications. Have your build-process update your project repositories (version control, task tracking, wiki, calendar, and so on) with information from the latest build. For example: if bug-fixes have a “Pending Build” status in your task tracking application, your build process should mark them as “built” and forward them on to QA for verification. For milestone builds, you may want to automatically tag the code. If three builds fail in a row, a meeting could be automatically scheduled. You could add a code churn report to the project wiki.
Get the idea?
It’s OK to Have Fun
From traffic lights and cha-ching! sounds to text-messages indicating that it’s been a week free of build failures and it’s time for pizza and beer; it’s OK to have some fun with your build process… and it’s much easier when that process is automated.
Leave a comment
Category: Best practices, Agile, Automation, Version Control, Quality Assurance, Continuous Integration
- Add this post to Del.icio.us - Digg - reddit