Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Effective Build Management: Don't Build a House of Cards : Page 3

By exploring the latest techniques for automating build management you'll get a better understanding of the fundamentals and benefits of effective build processes as well as how they fit into an overall configuration management strategy.

Multiplatform Support on Execution
These days, many builds aren't delivered for just one platform. The system may need to run on a mobile phone or handheld, or in a Windows, Unix, or mainframe environment. For instance, imagine that you support both Windows and Unix. You might have a Microsoft Visual Studio project (or perhaps an nMake file) for the Windows platform and GNU Makefiles to support Unix. With an in-house solution, each platform would have its own build system with its own "wizard" to maintain its scripts and configuration. Both build systems would then need to be maintained each time a change is made.

A much more efficient approach would be to have a single interface and consistent set of features across all platforms. With a next-generation build solution, build administrators can select what type of target is being built on which platform and the tool will automatically generate rules such as those in the makefile script shown in Listing 1.

Integration with Development Environments
If you're shopping for a build solution, there are a few other key factors to keep in mind. For instance, most builds are invoked manually. A developer using an IDE triggers a build by selecting a menu option, or the "build wizard" runs the build script with the right arguments and parameters. These different types of build invocation change depending on the build stage, and at the higher stages the build manager may not even have physical access to the machine (the system test machine could be in a data center across the globe). Therefore, it is critical for build systems to manage remote builds and offer integration with multiple developer tools.

Comprehensive Auditing and Logging
In most script-based systems, a log of the script execution acts as a way of verifying exactly what has been done during the build, but this is normally very detailed and technical in nature. Sometimes these logs are even a straight list of compile and link lines that must be checked manually.

An enterprise-class system, on the other hand, can provide a variety of reports and logs for manual verification of the build. Audit reports can verify that the files in the build exactly match the approved configuration in the CM system before the build, and similar logs after the build can be used to verify exactly what has been done. And, if information regarding the build is captured in a relational database, graphical reports and dashboard metrics can be generated. An example of a useful measurement might be "rate of compilation failure of modules in a particular component of the system in the last two weeks."

More Benefits of CM Integration
Of course, this again points to a key issue: to achieve a truly repeatable and reliable build, it is essential to use a build system that integrates with your CM tool. The CM system can then be used to review and approve the changes before automatically pushing altered code out to the appropriate build area. It can also maintain a history of who completed the build and capture a baseline of the build area so that the contents can easily be reproduced.

Some of the best CM systems even manage the build itself (i.e., they can record dependencies, rules, compilers/tools, and options) so they don't just baseline the build area, but provide a complete snapshot of the entire build environment.

Storing dependencies in the CM system not only help make builds reproducible, it also provides the data necessary for complex impact analysis—almost a form of time travel. With comprehensive impact analysis capabilities, it's possible to run "what-if" scenarios and actually answer the question "if I modify this piece of code, what components, deliverables, or customers will be affected?" before you change anything.

Ensuring that outputs and deliverables are included in the impact analysis process is typically done one of two ways. They either can be stored in the CM system, or footprint information can be added to them. This information then serves as a reference back into the CM system to identify which baseline or configuration the deliverable came from. By preserving them in this manner, it is possible to back track to the list of fixes and enhancements made in that release of the product.

Finally, flexibility is essential. Depending on the size of your project and team, you may have varying levels of requirements for a build system but be sure to choose a solution that can grow and change with your future needs.

Peter Raymond is a Solutions Architect for Merant. He provides architecture and design guidance to support Merant's R&D activities, ensuring that as products are designed, built, and modified they are secure, scalable, re-usable and flexible. He has more than eleven years experience in the software configuration management industry. Reach him by e-mail .
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date