Getting Started with Agile SCM

A Motivating Story
A new developer, Jim, is joining your team today. You have been extremely busy, and you want to get Jim productive as soon as possible. The first thing you need to do is to help Jim get a development workspace set up. You’ve been meaning to automate the process for a while, but since setting up a workspace is something that you do only once in a while, you’ve been putting it off.

You point Jim to a wiki page that has instructions for setting up a developer workspace environment. Jim opens looks at the wiki page and follows the steps for  downloading and installing an assortment of tools, including the compiler, version control client, etc. Hours later, after installing the tools, if Jim remembers that the purpose of this activity was to develop software, Jim gets to the steps that tell him what command to execute to get the source code. He checks out the code and tries to build it. The build fails.

Jim re-checks the list on the wiki and realizes that he made a mistake on step 3. He fixes the problem and tries to build again. It compiles! But the tests fail part way through. After checking to see if he made a mistake, he grabs one of his colleagues who walks over with a USB Drive and says “You need a copy of this configuration file to run tests on a development box.”  Right before Jim leaves for the day, he can build the application.

Maybe tomorrow he can run the application on his machine and get to work.

The Repository Pattern
Having a well-defined process for setting up a development environment, the workspace, is the point of the Repository Pattern, which advises you to:

Have a single point of access, or repository, for your code and related artifacts. Make creating a developer workspace as simple and transparent as possible. [SCM]

The Repository advises you to create consistent workspaces for development, integration, etc. This enables:

• Reproducibility, by having the recipe for reproducing an environment under revision control, and reducing the “works for me” phenomenon.

• Productivity, by making it simple for developers to get started or create new workspaces for different projects.

• Efficiency, by automating the process, and also making it less error prone.
• Maintainability, by allowing you to create multiple workspaces for release lines.

In principle, you can attain the goal of reproducibility by having a “defined” manual process. Having a documented process made it possible for Jim to get started rather quickly compared to an ad-hoc one. Having a documented process puts Jim’s organization ahead of some.

The risks with having only documented processes are that manual processes are slow to execute, error prone, and difficult to maintain. And once a document shows signs of being out of date people will start ignoring it, thus leading to discrepancies between workspaces, negating the value of having documentation. The value of an automated workspace creation process is best expressed by the Agile Manifesto value working software over comprehensive documentation. [MANIFESTO] The simplest way to ensure that a workspace is consistent is to make it very easy to set one up.

An automated process for doing this sort of set up has all the benefits of the documentation only process, and also has these benefits:

• It will be faster by eliminating idle time. Most set up processes involve starting a process (a copy or a checkout), and then after the step is finished, doing the next one. During the set up the developer is either sitting idle, waiting for a process to complete,