Characteristics of the Agile SCM Solution

and change history. The SCM tool should offer a solution that feels as simple as Windows Explorer or any other operating system CRUD operation.  Agile SCM solutions must enable the Developer to change their file names anytime they want and present them with an easy to understand interface to connect file history when and where appropriate.

Refactoring Support is probably one of the biggest challenges facing the SCM Tool market.  There are tool vendors that are working hard to better support Refactoring. I predict that over the next several years, Refactoring Support in the SCM Tools market it will be relatively commonplace. 

3- Continuous Integration

One of the four core values of agile software development is, "Working Code over Comprehensive Documentation."  Working code is a highly valued concept for any agile project.  A way to ensure that the code in the repository is in working condition is to perform periodic and automated Integration builds and tests.

Since we know that the Development Team values working code, it should be as simple as requiring that they update their workspace, build the application and run their tests against it prior to committing their changes to the repository. This approach, while important to the entire development process, works most of the time and is relatively inexpensive. However, there's no guardrails to getting non-working code into the repository, and there are holes to relying solely on this development process.

There are cases when the application will unit test fine in a Developer's environment but nowhere else. I call this the, "It Works on My Machine" scenario. This can occur when a Developer writes to a new library or piece of code that is not yet checked into the repository. When they build and test the application in their development environment, everything works fine - on their machine. When they check in their changes but forget to check in the new library or miss a file change, it stops working for everyone else.

The Continuous Integration approach constantly measures the quality of the application and offers independent feedback to the Development Team on a regular basis. An implementation may initiate the Integration Build upon a check-in event. The build occurs on a separate integration machine with a known configuration. Then a suite of automated tests is run against the resulting build. The results are formatted into an email and sent to the Development Team. Other implementations can be kicked off periodically (say every 60 minutes) if there have been changes to the repository since the last Integration Build.  As you've probably noticed, a Continuous Integration approach requires a fully automated build process.

4- Automated Builds

Automated builds seem to be one of the most misunderstood concepts in what we do.  I break them down into three types of builds: Developer Build [Private System Build], Release Build [No match in the Pattern Language, but similar to Integration Build] and Integration Build [Integration Build].  The Developer Build is what the Developer uses in their private workspace to compile the application for unit testing.  The Release Build, which uses the same process as the Developer Build, also includes the labeling of the release, the check in of targets, creation of BOMs, other reporting, etc.  The Integration Build, which also uses the same process as the Developer Build, hooks in a test harness but doesn't typically apply any labels.  The section refers to automating the Developer Build. The benefits of investing in a fully automated build system for your application are numerous indeed. Automated builds provide speed, consistency, predictability, quality and traceability.

Developer builds occur constantly throughout the development