This chapter is from the book
This chapter is from the book
This chapter is from the book
Making a Start with Build Automation
You are ready to start build automation when you've managed to add all the source and supporting files into your repository. There are many approaches to build automation, starting with the simple batch file, right through to the use of a full-fledged build tool such as Ant or Nant.
NOTE
We'll cover Ant in detail during Hour 16, "Automating Your Software Development."
Any build script will follow this general outline:
Connect to the source code repository
Extract the latest versions of source
Extract any supporting libraries or binaries
Execute either a compile, or more likely, call the relevant make files for each project
Create deployment packages, if required
Call smoke tests
Log results (this might include email notification of status or update on the project Web site)
The classic Make utility is well known and used; it enables developers to perform both incremental and clean builds. Make checks the date of target files (intermediate binaries or target) and executes compiles if the target date is older than the source. The capability to incrementally build certainly lowers build time, but can mask unusual component dependencies. For this reason, the developer will call a clean build or rebuild; this builds all files regardless of date.
For increased flexibility and power, XP developers tend to use Ant as their build tool of choice. Ant is an open-source tool that is driven or controlled by a build file, formatted in XML. Ant also offers some integration with Junit and can be used to run post-build smoke tests. Nant is a recent addition to the XP build tool family and is modeled closely on Ant. The difference is that Nant is written for the Microsoft .NET framework and as such does not require Java. Development shops that are working with .NET should consider this tool.
Extreme Building with Continuous Integration
The value of frequent integrations is self-evident. The capability to spread the risk and pain across the development life cycle far outweighs any up-front work required. The extra work required to increase integration cycles is more perception than reality if you've established good working structures. Let's walk through our development model and see how we can increase build frequencies.
Developers work in pairs to write product code; they start by writing unit tests in their test framework (junit, cppunit, VBUnit, nUnit, and so on). Then, they write just enough code for the test to pass. After the unit tests pass, they run the complete test suite for the system on their own machine. The pair continues to work on the component until it integrates with the system on their machine and passes smoke tests. At this stage they will migrate the source to the integration machine.
NOTE
Your ability to run system-wide tests might be hindered to some extent by the development environment. At the very least you should apply some kind of smoke test against the system.
Alternatively, the team may opt to use an automated monitoring tool such as CruiseControl. CruiseControl was initially developed by ThoughtWorks, Inc. but is now open source and freely downloadable from SourceForge.net. Cruise Control monitors the source repository status and triggers a build based on freshly checked-in source. Figure 12.5 illustrates this workflow.
){kind=link}
Figure 12.5 Continuous integration in action.
Use of CruiseControl or similar homegrown build monitor will only work after the fully automated build is in place using a tool such as Ant, Nant, or simple make files.
The diagram shows a separate build machine, which is not mandatory in your quest for automating builds, but it does simplify setup somewhat. Also, moving to a separate physical machine underlines the symbolism of integrating. Even with increased build frequencies, the importance of adding completed code to the software shouldn't be underestimated by the team. With each integration the team is increasing the business value of the system, and the customer is inching closer to their goal.
Reducing Your Integration Obstacles
Automating integration and starting the process early will clear roadblocks for you, but obstacles might still remain. Improving the communication between pairs can reduce integration conflicts. The popular practice of listening to music via headphones to increase focus and remove distraction has no place in the XP world. Of course, Pair Programming would be difficult if headphones were in use! Spare developers; that is, the unpaired developers who are working on build automation, research, documentation, or some other task, might miss vital verbal cues if they mask background sound with headphones.
Developers can minimize any remaining communication problems by adding change comments into source or via the configuration management system. In the open space of the XP warroom there is still a place for solid, "just enough" change notes.
Basic development hygiene issues such as following code standards and keeping unit tests up to date will catch simple conflicts, as well.
There are some common problems that can trip up your build automation, some of which are listed for you in Table 12.1.
Table 12.1 Common Build Automation Problems
|
Problem |
Solutions |
|
Build times are too long |
Break down the build into a number of parallel streams, using a master build file. |
|
Ensure you are using the fastest compiler, for example Jikes rather than javac for Java. |
|
|
Buy faster hardware! |
|
|
Use incremental builds during the day and complete builds after hours. |
|
|
Use profiling tools to measure where the build bottleneck is. |
|
|
Distributed development stretches communication |
Use master/child build files, allowing each site to run its own builds. Integrate the complete suite at a predetermined time. |
|
Use a single integration machine, offsite developers can use virtual clients such as VNC or Terminal Server. |
|
|
Ensure that teams have adequate network bandwidth. |
|
|
Manage source control from a central repository. |
|
|
Use collaboration tools such as NetMeeting or ICQ to keep communication lines open. |
|
|
Too many source-code conflicts at integration time |
Commit your changes more frequently, and therefore minimize the number of changes. |
|
Use a single-integration machine or token to ensure only one developer is integrating at one time. |
So, we can reduce our integration obstacles by careful planning and good communication. The extra effort required to get your build automation up and running will be well worth it in the end!