Continuous integration: The next level of build enlightenment |
 |
By Mike Gunderloy, Contributor
12 Sep 2005 | SearchVB.com |
|
|
A lot of software developers are unrestrained toolmakers. It's easy to understand why: when faced with a repetitive process or a boring task, we're the ones with the ability to bang together some code to take the repetition and the boredom and make them the computer's problem rather than our own. Over time we accumulate ever-more-complex tools in our quest to make our lives easier.
A good example is one of the latest things to hit Visual Basic development: continuous integration. Though it's been around for a while, you might not yet have run across this technique or the tools that support it. It's worth taking a few minutes to learn the basics, so you can decide whether it makes sense to investigate seriously for your own team and projects.
To understand how continuous integration fits in, it helps to consider how a typical software project grows up. When you're first developing a new application, you can get by with simply compiling in your IDE of choice (Visual Studio .NET for most VB developers these days), or by invoking your compiler from the command line.
But if you're doing a professional job, the simple act of compiling the code is far from the only step involved in building the final product. Typically, you need to get the most recent version of the source code from your source code control server, build the application, run the unit tests, perhaps build the documentation, and run other tools such as code coverage checkers or automated standards conformance checkers. Then you might need to run another program to build the installer, send e-mail notifications to various team members, and copy the final product to an FTP server or share on your LAN.
As the number of steps involved in producing an actual build of the software increases, the chances of forgetting one or doing it wrong increase. Worse, different members of the team start to develop different ways of doing things, and the result is inconsistent results -- recognized by the plaintive cry "but it works on my machine!" This leads to the second stage of build enlightenment: the use of automated build tools. These tools let you create a script listing all of the different programs and actions that go into building your application. When it's time to create a new build, you just execute the script, which works the same way every time. Some teams use home-grown batch or command files for this purpose, but in the VB .NET world most will gravitate to a GUI tool such as Visual Build Professional or FinalBuilder, or an XML-based one such as NAnt.
Identifying the weaknesses in the automated build approach is what leads to continuous integration. First, even if every member of the team has the build script, there's always the worry about whether every machine is set up the same way. Do you all have the same tools? Are all the libraries the same version? Is everything installed in the same place? Second, build scripts don't do any good if you don't remember to run them. Continuous integration tools (in the .NET world, the best known ones are CruiseControl .NET and Draco.NET) sidestep both of these difficulties, and so bring you to the third level of build enlightenment.
((Content component not found.))
Here's how it works. First, you set aside one computer to be your "build machine." This computer will be the one that churns out all of the builds of your software, day after day, without fail. You install all of the software you need: libraries, compilers, tools such as compliance checkers and setup builders, and so on. Then you install a continuous integration tool and write a continuous integration script. Such a script can have many steps, but typically these can be grouped into three sections:
1. The first part of the script lays out the conditions that trigger a new build. These can be as simple as "build the application every night at 3AM," but more typically the build machine monitors your source code control repository and builds the application every time someone checks in a change (hence the "continuous" in the name).
2. The second part of the script lists the tasks that the build machine must do to build the software. This is similar to the script used by any auotmated build tool.
3. The third part of the script handles transmitting information on the state of the build back to the team. Typically, the build server will maintain a Web page with up-to-the-minute status information on whether the most recent build succeeded or failed. They can also send e-mail when a build is finished, and some even tie into client-side applications that you can run to notify you directly when something goes wrong.
Using continuous integration still requires some discipline, but when it works, it can be a tremendous boost to productivity. The key is to check your code carefully on your own computer before checking it in. At that point, the build machine takes over, integrating it with the code from the rest of the team, and running the full suite of tests for your product. The end result is that if anything goes wrong, the whole team knows quickly - and when nothing goes wrong, you have the comfort of knowing that you're moving forward in a steady, repeatable fashion, with a product that you can ship any time without pain. And that's worth a lot.
Mike Gunderloy is an independent developer and author working in eastern Washington state. His recent books include Painless Project Management with FogBugz (Apress) and Coder to Developer (Sybex). You can read more of Mike's work at his Larkware Web site, or contact him at MikeG1@larkfarm.com.
|
|
|
|
