Private Developer Workspaces: Where the Development Process Meets SCM Process

• accept the change. This includes, among other things, code, libraries, and databases.

You should be able to create a Private Workspace with a simple process not too different from:

• Install a version management client.
• Check out the files for the appropriate version of the application
• Execute a script to build, configure and deploy your application

There may be some extra steps, to be sure, but you want to automate as many steps as possible to ensure that the process is reproducible.

Allowing developers to create Private workspaces easily is a core element of the Agile Cycle.

The Agile Cycle

Agile software development relies on feedback. The simplest form of feedback is how tests execute. Figure 1 shows the steps that we repeat the following steps frequently

• Code to develop the specified feature
• Unit Test as we Code
• Before we are ready to commit we update our workspace from the codeline and build so that we can see that we are not breaking the build
• We run a Smoke test that tests the entire system.
• If the Smoke test passes, and we want to commit our changes we do so, otherwise we repeat the cycle until we have a good build. In most cases you will want to commit changes frequently.

Figure 1: The Agile Cycle

The Patterns

The Patterns

The Patterns

A Private Workspace is not useful on its own, and it is important to understand the patterns that define its environment. Figure 2 shows how the Private Workspace pattern fits in the context of the other SCM Patterns. The key patterns in establishing a workspace are

• Private Workspace, which defines what a workspace is
• Private Build, which allows you to verify that the system works
• Repository, which provides the tools that allow you to create the workspace,
• Smoke Test, which gives you a way to check that your changes have not broken the build,
• Unit Test, which allows you to test your specific changes in detail.
• Integration Build, which provides a way to verify that all of the changes that were coded and tested in the private workspace really do integrate together.
• Codeline Policy, which is how you communicate how the development process works.

Private Workspace enables Active Development Line and relies on Repository, Integration Build and Private System build to work.

Arguments Against Private Workspaces 
One item that seems to raise issues from time to time is the requirement for copies of the database schema. You can apply these rationales to any other resource issue.

The common issues that arise are computing resources (machines to run the databases on), complexity of setup, and that databases are the province of a different team (the "Database Team"). While there may well be exceptions, in most cases these rationales are often not valid reasons to deny this important productivity improvement tool. Let's address these in turn.

The Cost of Resources
Cost of resources is often overstated. The first thing to consider is the cost of not having these resources in place. Consider the amount of effort you expend working around not having these resources. One major one is the coordination cost of having to time private changes to a shared schema with the work of others. You may have to spend time waiting for the resources, your test cases may disrupt the work of others (by design if you are working on an issue that could break the whole application, or by accident if you make a mistake). Developer and tester time is relatively expensive compared to hardware, and delays also can mean slipped schedules and missed market opportunities.

Also,