The Build

The build must be repeatable. Performing a local build in an integrated development environment (IDE) is a great way for developers to analyze the isolated impact of their changes, but it is no way to build, package and deploy an application in a team environment. Local builds are a manually intensive process performed by individual developers with no guarantee of consistency. Skipping a step, working with older copies of source or incorrectly performing a build task are common mistakes that can result in a corrupt application. A repeatable build helps solve these problems by ensuring the steps executed to build, {sidebar id=1} package, and deploy the application are performed consistently each time. Fundamentally, a repeatable build consists of at least the following:

• It must be a clean compile with no syntax errors.
• It must be performed on the most current version of all source files.
• All application source files are compiled.
• The build should generate all units of deployment.
• The build should execute all relevant tests successfully.

Depending on your platform, tools are readily available that allow you to develop a repeatable build script. Ant is the most popular utility for J2EE development.

The build must be automated. Even with a repeatable build, time must be spent manually invoking the build process. Eliminating waste is a core tenet of successful agile teams, and that which is repeatable can be automated. Build automation frameworks allow you to schedule the build so that it is run at predictable intervals. Frequency of the build is a product of team dynamics. For smaller teams, it's useful to execute the build each time a change to the source code is released to the source repository. Larger teams may choose to execute the build according to a defined schedule, such as hourly, due to the heavy volume of released code. Project teams should experiment with frequency to address their specific needs.

CruiseControl is an example of a build automation framework for the J2EE platform that sits atop an Ant build script and executes the script based on configuration. Maven is a software management tool that helps manage the build, while also generating feedback aimed to provide the development team with additional project information. Buildix is a new agile development server that rolls together many of the utilities commonly used in a continuous integration environment.

The build must have a supporting infrastructure. In addition to build and automation tools, additional supporting infrastructure must be in place to support an automated and repeatable build. In Open Source Tools for the Agile Developer, I presented a suite of other useful utilities that aid agile development. Many of these must be present to create an automated and repeatable build.

• Source Repository. A master copy of source files is critical to ensure the build compiles and verifies the most recent version of the application. A source repository also provides easy access to latest copies of source, ensuring developers are able to easily setup the application development environment.
• Build Server. Executing builds frequently requires a dedicated machine. Without a build server, a developer playing the role of build master would be required to host the build on her machine, which is inefficient.
• Shared Environment. A successful build should be deployed to a shared environment. If you're developing web applications, a region accessible by developers and other project members, including clients, provides the opportunity for functional testing and client review.

The build should be extensible. Once an automated and repeatable build with supporting infrastructure is in place, the team can think about other aspects of the development lifecycle that can be automated. For instance, in Using Metrics to Drive Agile Software, I discussed quality, dependency and coverage metrics. Generating these metrics can be automated as part of a build process and subsequently published to a website or pushed to developers via e-mail, giving team members the rapid feedback they need.

Agile Environment

Investing time and energy toward developing an automated and repeatable build infrastructure offers significant rewards. To realize the full benefits of the process, the team must be rigid in enforcing some simple team guidelines.

• Golden Rule. A prime directive of agile development is sustainable forward progress. A failed build always represents a step back. Anytime the team experiences a build failure, it must become the priority of the team, above all else, to rectify the situation. No changes other than those correcting the problem should be released to the source repository until the application is successfully built.
• Synchronization Rule. Developers should release and update their local environment at least once per day with the master source repository. Waiting any longer than this increases integration risk.
• Release Rule. Avoiding build failures requires developers to exhibit more discipline while coding. Developers must write tests and code simultaneously. When finished, a local build should be performed, followed by synchronizing changes with the repository. Any differences between the local environment and the source repository should be resolved before releasing code. Developers should give careful attention to ensure they release all modifications to avoid a partial commit that may cause a build failure.
• Defect Rule. Fixing bugs should be done with agile practices in mind. Developers should first write a test case that recreates the defect. Initially, the test should fail, but after correcting the defect, the test should execute successfully. In addition to identifying and fixing defects, automating tests as part of the build ensures the defect does not resurface. When finished correcting the problem, source code changes including tests, should be released according to the Release Rule.

Activation

An automated and repeatable build is the cornerstone of any successful agile development team, enabling a plethora of important lifecycle activities. An agile environment is a living and breathing entity where progress is tracked in minutes, not weeks and months. Here are a few of the advantages you'll realize as the result of an automated and repeatable build.

• Incremental Growth. Iterative methods advocate incremental growth of the software system. Whereas some less agile methods encourage iteration plans attempting to predict incremental growth, agile teams experience incremental growth daily.
• Frequent Deployment. Early and frequent deployment to a shared environment avoids integration risk, and offers the team the opportunity to tweak application parameters and execute tests that are best suited for a shared environment. Delaying deployment increases the likelihood of experiencing configuration problems or application packaging issues.
• Functional Demonstrations. Early in the software lifecycle, most development teams aim to understand user requirements. Typically, meetings are held that emphasize driving out these requirements and documenting them based on discussions. As the software grows, functional demonstrations can be used to help gain additional insight to requirements in a different context.
• Constant Feedback. Extending the build with coverage, design and quality metrics allows the team to gain feedback on the integrity of the software. Potential areas of concern can be identified and corrected immediately upon discovery. Additionally, because the build is scheduled, teams can track progress and setback trends.
• Lifecycle Automation. An automated and repeatable build automates many of the mundane tasks previously requiring manual intervention. Build, tests, packaging, and deployment are automated and therefore occur regularly and often times without manual intervention.
• Adaptability. Your build serves as a system of checks and balances for the development team. Tests provide the courage to refactor. Refactoring is validated by frequent builds. And builds are deployed to a shared environment where they can be further tested and verified. The combination of these factors contributes to an environment where change is more easily accommodated.
• Grass Roots Agility. Even in organizations where agile development is a politically charged word, few can argue with the value of a functional product, especially once project stakeholders and clients experience the benefits.

Conclusion

Developing a robust automated and repeatable build is a process that requires constant attention throughout the development lifecycle. If you are currently suffering low software quality, ineffective response to change or integration issues, an automated and repeatable build allows you to take the first important step toward easing the pain. An automated and repeatable build also achieves the intended goal of all software development efforts: software delivery.

About the Author

Kirk is Chief Technology Strategist at QWANtify, where he leads based on his firm belief in the pragmatic use of technology. In addition to his work on large development projects, Kirk shares his experiences through courseware development, teaching, writing, and speaking at seminars and conferences. Kirk has provided training to thousands of software professionals, teaching courses on UML, Java J2EE technology, object-oriented development, component based development, software architecture, and software process.

{mos_sb_discuss:10}

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview