Getting Started with Agile SCM

• which is wasted time, or doing something else, which means that there will be down time unless the developer is looking at the screen when the process stops.
• It is repeatable. To change the set up, you change the set up process. By minimizing manual steps, you minimize the chance for error.

• It can be validated automatically. An automated set up process makes it possible to have low cost tests run periodically, so that you can detect errors that may creep into the set up process automatically.

To simplify workspace set up you will need to use some sort of tooling. This leads to a bootstrapping problem that can be addressed.

Bootstrapping
A good workspace set up process has very few, if any, manual steps. In practice, it’s difficult to automate every step of the process, so you should strive to have as few manual steps as possible.

To begin with you will need some tool in place to bootstrap the creation process. For example, if you start with a checkout from the source code repository, you will need a version control client. If you choose to start things off with a script, you need to be sure that the right version of the scripting tool is available on the target machine,

It is also important to make as few assumptions as possible about the environment, such as assuming that certain tools live in a certain place. This makes the build process fragile and not robust to change.

Rather than making a simple workspace creation process seem like an unreachable goal, you can get most of the benefits of automation by ensuring:

• The number of prerequisites is small. Ideally only one or two tools which are easy to install.
• The documentation for the setup changes rarely; any changes that affect existing workspaces should be reflected in the tool or build process.

• The workspace setup process verifies that the tools all have the correct versions, and if not, provide the user with some information about how to upgrade.

With these principles in mind, you can create a Getting Started page for your project that looks something like this:

• Install some basic tools that need to be installed once.
• Run a command to get a bootstrap build script.

• Update the source code

• Build. The build should configure any user customizable configuration files automatically.

Because, in the interest of getting a process working, we’re allowing that some tools can be installed manually it’s important that the build step verify that these tools are the correct versions. For example, your build script can have a “check-prerequisites” step that verifies that the build tool and complier are at an acceptable version, and fail with a message indicating that the developer needs to upgrade. While this is not as good as automatically upgrading, it is acceptable if the upgrades are infrequent, and developers are warned in advance. Treat core tool upgrades like changes to a published API.

We’ll work through an example using the java build tool maven. While this may not be something that suits your environment it will give you a sense of what is possible.

For Example- Starting a new Project
As it happens there is an open source project that already demonstrates the tooling we need to make it simple to create a new project from nothing: the Apache Wicket project. Wicket is a framework for building java web applications. Wicket claims to make building web applications simple and enjoyable. Its quick start page exemplifies this ideal. Figure 1 shows the dialog from the Wicket project QuickStart page. By completing the form,