The Agile Difference for SCM

of yester-year isn’t as high-level as the more popular modern programming languages in use today. And the power of interactive development environments in the last couple decades makes coding even that much more like a creative activity that affords rapid-feedback.

Tracking vs. Control, and Current Configuration

So if coding is regarded as a creative design activity (rather than a predictable construction activity), the expectation is that such activities should be less rigorously controlled and constrained than construction-activities because they require greater freedom, collaboration and innovation. And anything that stifles or interrupts the productive flow of creative, collaborative work adds a great deal of "friction" to the development process.

Therefore, heavyweight configuration management environments that make developers wait non-negligible periods of time for things like checkout-authorization, presenting and approving all files to be modified prior to coding, protracted build-and-test cycles, waiting for a new baseline to be promoted for use, etc. are considered detrimental to the health of an agile development environment.

Tight controls would be relaxed considerably so that sufficient tracking and auditing could still take place while still allowing the rapid, full-cycle closed-loop feedback that agile development mandates. And development will typically want to use the most recent working and tested state of the codeline rather than wait for a formal build and baselining activity that takes as long to baseline as it takes to complete a multiple development tasks.

Agile development will require what it deems the true "construction" portion of software development (namely build and test) to be as automated and integrated as possible so it can be executed as frequently and as quickly as possible. Development would be able to use the current configuration (latest baseline plus approved changes) as the basis for each development task, and rigorous build/test criteria prior to each Task-Level Commit in order to preserve codeline integrity and stability while still enabling rapid integration and test feedback.

Key Agile Practices and Their SCM Implications

So what are some of the key agile practices that organizations look to introduce? In a recent article, Peter Schuh identified a number of ways to add some agile without going to extremes:

• Automate and share the build process

• Implement a test framework and start writing unit tests

• Adopt a continuous integration process

• Plan and deliver in short iterations and small releases

• Identify and collaborate with your customer

• Manage your test data; don’t let it manage you
• Embrace collective ownership and share code

Let’s examine the impact that each of these has on SCM.

Automate and Share the Build Process

The build process is a core part of SCM. The fundamental SCM principles that apply are to always deliver a known reproducible build from a clean environment. This has a tendency to lead to a "build master" or build team producing the "golden build", and thus becoming a major bottleneck.

The agile recommendation is to make it easy for everyone to build the system at the push of a button. This saves time:

• It frees programmers from repetitive and mundane tasks

• Reduces time spent chasing down compilation and convergence issues
• Reduces dependencies and bottlenecks - people won’t get called back to fix the build.

Continuous Integration

A presentation and demonstration of a continuous integration framework at the recent BCS CMSG event demonstrated the advantages:

• Improving quality due to much more immediate feedback of integration problems
• Improved speed as it is done so often, problems don’t lurk unnoticed

Manage Your Test Data

There are various schemes to do this to this including one called ObjectMother. If you have any form of database then you will need to address this