Agile SCM

This article originally appeared in Configuration Management Principles and Practice by Anne Mette Jonassen Hass. Published by Addison Wesley, copyright 2003. All references to "this book" in the below text refer to Configuration Management Principles and Practice. For more information on what Agile SCM is refer to the Agile page on the CM Crossroads Wiki.

---

Appendix C

by Stephen P. Berczuk and Brad Appleton

 

Adapted, with permission, from Stephen P. Berczuk and Brad Appleton. 2003. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Boston: Addison-Wesley.

 

Software Configuration Management (SCM) is crucial to the success of agile projects. A team without effective SCM practices gets slowed down by the extra work each developer must perform when there is no easy way of synching up with his or her teammates. A well-designed and light SCM process actually speeds up the project.

This appendix is divided into two sections. In the first section, we identify key strategies, or patterns, that should allow the agile team to stay safe with an ultralight selection of SCM practices.1 In the second section, we describe how the SCM terms in this book map to the practices of the common agile project.

The key to understanding the agile mappings is to recall that agile projects rely on good, two-way dialogue with the user; delivery of running, tested code every two to twelve weeks; and frequent, early feedback on the quality of both the requirements and the design. With this three-layered safety net in place the following mappings become effective.

 

Keeping Agile Projects Safe

 

There are many aspects of SCM that are relevant to the agile project —the difficult part is knowing when to apply them. We want agility, not chaos. Some practices work together to build an effective development environment with the right amount of SCM practice.

Your agile project should use a simple branching structure. Branches of development for a configuration item’s source-code library files are commonly called codelines. One or two codelines are usually sufficient for agile projects that don’t require multiple parallel releases or variants.

The key concepts for organizing the evolution of your code are: a Mainline, an Active Development Line, and a Release Line. A Mainline is the single, central codeline that controlled library artifacts are checked in to. Having a single integration point makes it easy to re-create the latest state of the SCM-controlled items. An Active Development Line is a codeline that is set up with a Codeline Policy that permits ongoing work to be checked in without overly rigorous precheck-in validation. A Release Line is a codeline for system states that are available to customers for fixing system problems in preparation for your regular release cycle. A Release Line has a more restrictive Codeline Policy that ensures stability.

Having a Release Line simplifies the SCM rules and allows you to be a little less strict on the check-in policies for the Active Development Line. With these two separate codelines in place, the developers can make their hourly or daily changes into the Active Development Line, and the customer-release process can use the more carefully controlled Release Line.

Here is what a typical agile developer’s day looks like in terms of the SCM strategies or patterns they use:

Each developer works in a Private Workspace that contains the code that the developer is working on, populated from a Repository—a single point of access for everything that a developer needs to build his or her project. The developer gets external components from a Third Party Codeline. If he or she does not want to build the entire system from scratch, the developer can populate some of their workspace from an Integration Build, which is a snapshot of the codeline.

The developer, progressing through the day, will check changes into the Active Development Line so that they are visible to the rest of the team, as well as available for the integration build. Because the codeline isn’t required to be bullet-proof, the developer does not need to run exhaustive tests before checking changes in. But he or she should create a Private System Build, which is just like the Integration Build, and run a Smoke Test on the result to make sure that the check-in will not cause any problems. Since this cycle repeats with every developer, the current state of the system is available in the Integration Build.

The codeline may have mistakes in it, but they should be few and minor. The team relies on the Smoke Test to catch show-stopper defects and on Unit Tests to ensure that changes don’t change any interface behavior for the module that the developer is testing. After the Integration Build, the Regression Tests, as well as the full suite of Unit Tests, are run to catch integration issues. It is a trade-off, but it’s a reasonable one, since the only way to ensure a pure codeline would be to have a developer lock the entire codeline, run a full suite of tests, check in the changes, and then unlock the codeline. This approach would severely limit progress, and for agile projects you realize more value from changes in functionality early on. Once the project reaches a certain milestone, the code can be branched onto a Release Line, where a more restrictive Codeline Policy may be in effect.

 

Mapping Terms for the Agile Project

 

With those strategies in place, we can examine the main concepts in this book that need to be mapped for an agile project: • Change Control • Identification and Storage • Change Authorization • Integration and Build Management • Status Reporting

 

Change Control

 

Change control starts on Day One of an agile project! In two-way dialog with the user, customer or executive sponsors, the agile team elicits requirements in the form of feature requests and user scenarios. These requests may be for brand-new functionality, or for changes or additions to already implemented functionality. Developers estimate each requested chunk of functionality, and the customer then gives priorities for the features to work on over the next iteration.

Agile iterations are typically short (two to twelve weeks), so there aren’t usually many features to track for a given iteration. Requirements are managed by keeping track of the list of features for the current iteration, and a current backlog of requested but not yet implemented features. At the end of an iteration, the current backlog of requests, along with any new requests, are once again prioritized by the customer so that the developer can decide which set of features will be worked on during the next iteration.

This frequent reprioritization and selection process is the most common agile equivalent of a change control board (CCB). The customer drives the priorities and need for change while development accommodates those needs as much as possible in each iteration, focusing almost exclusively on the features for the current iteration.

In some cases, the features or change requests are written to the change-control system. In more informal projects, particularly Extreme Programming projects, requests are documented on a four-inch by six-inch white index card or two-foot by four-foot flipchart taped to the wall, whose text is updated throughout the iteration period, so that everyone who reads it sees the original request and the modifications that have been made to it.

 

Identification and Storage

 

Identification of configuration items is typically done with text and source code repositories using commercial and open-source version control tools such as CVS, Visual Source-Safe, Perforce, BitKeeper, and simple out-of-the-box installations of higher-end tools like ClearCase. Items are checked-out of and checked-in to controlled library storage (the Repository or “code base”) to and from a dynamic storage library called the developer’s Private Workspace.

A brief textual description is typically created to convey the overall source-code directory structure of the code base. Build scripts such as Makefiles or ANT recipes, along with the instructions necessary to successfully build the system with minimal recompilation, describe physical build-dependencies. Any special configuration files, or external tools, libraries, or databases required to build, install, or upgrade the software are often checked-in directly to the Repository, or else separately archived and versioned with noted dependencies of the corresponding compatible version(s) of the code base.

Releases and significant build milestones are identified in the code base using the “tag” or “label” facilities of the version control tool. The label makes it possible to reproducibly identify every revision of every file in the Repository that participated in the build or release.

The metadata maintained by the version control Repository, combined with the physical code structure description, and build and dependency information is typically sufficient identification for the agile project.

 

Change Authorization

 

The developer on the agile project is authorized to change the source code in two cases:

 

1. To implement an agreed-upon feature for the current iteration.

2. To improve the simplicity (readability and maintainability) of the source code.

 

Agile development teams work hard—as a matter of principle and through peer pressure—to develop only what the customer has requested for the current iteration, and to keep the design simple. They also are working in short iterations, and so they have less time in which to gold-plate their design. These factors together have the effect that very few gratuitous features get put into the code, which reduce the worries surrounding development change control.

Agile teams are typically authorized to make small refactoring changes at any time without prior management approval, provided that the code complies with team-defined coding conventions and continues to pass all the same tests as before. (Refactoring is revising the code structure without changing its functionality.)

Development change control is often informal. The source-code control system marks the changes, and may perform change notification automatically upon checkin or check-out. Changes are announced by e-mail between developers, or word-ofmouth when teams sit together. This works because of the small amount of goldplating, the short iterations, the close contact between developers and good testing habits.

 

Integration and Build Management

 

Agile teams work in short and frequent small releases, and even more frequent integration and building. Developers run Unit Tests and perform Private System Builds, and Smoke Tests before committing changes from their Private Workspace to the Active Development Line. Integration Builds must pass Regression Tests and may be rebuilt from scratch (to ensure build reproducibility) before being required to pass functional acceptance tests.

 

XP preaches continuous integration, in which changes are integrated many times a day or even several times each hour. Since the changes are very small and comprise the smallest possible set of consistent files for a testable chunk of functionality, the time to integrate and incrementally rebuild the system is very small.

Non-XP agile teams tend to build and integrate every day or two, often running a daily or nightly build that checks for build failures and immediately reports the results. If a build breaks, fixing the build becomes development’s top priority. Since all developers are typically required to do a Private System Build of their changes before check-in and ensure the code passes their unit and regression tests, broken builds tend to be infrequent due to such disciplined testing on such small sets of changes.

 

Status Reporting

A report of physical contents usually includes version label names and a manifest (or packing list) of all the files in the released build. In addition, a file name and revision ID is often maintained in each source-file. This enables (with help from the version control tool) reporting of a bill-of-materials (BOM) listing all the source- file names and revision numbers that were used to build the target executables and libraries.

A report of functional content usually includes all the features/requests that were implemented for an iteration. Each developed feature is typically associated with one or more tests that verify its proper implementation (for development) and functionality (for customer acceptance). Once again, simplicity is preferred in tracking tests to features: each functional test is associated with a named feature in a spreadsheet or simple tracking database, or on index cards (perhaps even on the back-side of corresponding story-card). Sometimes the functional test is expressed exclusively in the source code (and comments) that exercises functionality under test. Tests are automated to the greatest extent possible and stored as a regression test-suite that is run after every build. Testing results/status are usually reported with each delivered version of the software.

Some agile teams use a spreadsheet to track feature-lists and backlogs, or a simple database to track the requests. Some teams use simple out-of-the-box request/defect tracking systems or open source systems, the most popular of which at this time are Bugzilla, GNATs, and Jitterbug. In either case, the tracking system (or mechanism) can easily be used to sort and report requests by date, priority, estimate, and target iteration/release. These systems enable the agile team to report the status of implemented, and to-be-implemented, functional requests for any iteration.