Photo by Russell Lee. Library of Congress, Prints & Photographs Division, FSA-OWI Collection, Reproduction Number: LC-USF33-013141-M1.

Cases of canned salmon in warehouse. Astoria, Oregon, September 1941.

To create a Private Workspace (6) or to run a reliable Integration Build (9), you need the right components. This pattern shows you how to build a workspace easily from the necessary parts.

Note

How do you get the right versions of the right components into a new workspace?

Any software development activity you perform starts with a workspace where you have the components necessary to build, run, and test your software. You need the right versions of everything that makes up the system so that you can accurately diagnose problems before you check in changes.

You want to get the elements of your workspace easily so that you can reliably create an environment that allows you to do your work using the right versions of the software, whether you are working with the current active codeline or with an earlier version of the code base.

As Figure 7-1 shows, a workspace consists of more than just code. Some of the things you need include

Figure 7-1. A workspace is created from many things.

Some of these elements have natural origins. You could get source code from your version control system, copy installation scripts for some components, and get third-party-built components from a development server. You can get other things that are not in source control from a server. Multiple locations for various resources add a lot of overhead to tasks for already busy software developers. You spend most of your coding time using tools such as an IDE, a compiler, and your version control system, and copying files from multiple source points leaves opportunity for error.

If you get tired of performing many manual operations to update your workspace, you may decide to write your own tool to keep your self in sync, and you may even share the tool with the rest of the team. Although developing such tools will save you time, you still run the risk of having the tool get out of sync with any new locations or policies, and you may incur a maintenance burden for the tool that distracts you from your work.

You need to be sure to associate the right versions of each element. For example, you might switch versions of a third-party library in the middle of a product release cycle. You can keep people up to date about changes by communicating. You can tell them to use a new version of the database API classes, and they may remember to update at the right time. It is difficult, however, for people to keep track of these details reliably on their own. People could be in the middle of a task when they receive an e-mail about a change to a third-party component and forget to update their workspace after a task. It is difficult to remember what configurations went together for an earlier release.

A manual update process takes time. And if you missed the update notice, you may have a number of locations to check. This can take a lot of time, especially if the components are in different places.

Another issue is going back to the correct configuration at a certain point in time. You can maintain a list of configuration components and have people refer to it when re-creating a test environment, but that is prone to error.

You keep your source code in a version control system, and adding more places for people to look for things adds to the complexity of creating a new workspace. If it is too hard to create a workspace, you may feel a natural reluctance to keep up to date or to create another workspace to work on another codeline.

One Stop Shopping

Note

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

Make the mechanism you use to create a workspace simple and repeatable. You should be able to create a workspace that contains artifacts from any identifiable revision of the product, including third-party components and built artifacts such as library files. The mechanism should also make it easy to determine whether there is a new version of an existing element or a new component that you need when you are working on the tip of a development. Figure 7-2 shows this.

Figure 7-2. Populate Your Workspace from a Repository.

So Many to Choose From

Many times I have wanted to test our product while working from the tip of the active codeline rather than from the latest install. The latest install often lagged behind the codeline by a day or so, and I wanted to see whether a recent change that someone else made addressed a problem that I was having.

Because of the nature of the product and the structure of our organization, the development environment had only a portion of the configuration data and libraries from other groups up to date. There were nightly builds of these components, but they were staged into the development area when someone needed an update. So we could go for days or weeks without realizing that something had changed.

When I tried to test, there were many mismatches between the server and client components. After three days, I discovered the problem and wrote some scripts (with the help of our release team) to enable developers to get the latest library files and configuration files from the source control tree.

How did this situation arise? In part because of lack of communication between the release engineering team and the various product teams. And in part because of a desire to control change too much. It is admirable not to accept changes in an unexpected manner, but if a library component changed months ago, it is already in the product. If the development team cannot see a problem, they are wasting the company's time when they leave it to the QA team to find all the integration issues.

The problems start when developers can't reproduce bugs in their development environment because they are (unknowingly) out of sync with the released version. Or they are reluctant to work on the correct version of the code base because it takes too long to set up.

These places are in better shape than if they had no version control system, but they waste lots of developer time and energy.

There are many ways to implement this pattern, and the details depend on the features of your version control tool, your build environment, and, to a certain extent, your team's culture. There are three requirements for your implementation.

• It should be easy to use and repeatable. This is in the spirit of what Andy Hunt and Dave Thomas refer to as “Ubiquitous Automation” (Hunt and Thomas 2002a); (Hunt and Thomas 2002b).

• It should give you all the components you need to create a Private Workspace (6) for working on a particular state of your project, including build scripts and built objects.

• It should work for all versions of the project.

Some common implementations are using the version control system as a repository for all artifacts and using scripts in combination with the version control system.

Since you have a version control system, a straightforward way of implementing this pattern is to place all source files, configuration files, build scripts, and third-party components in it. Identify the set that is relevant to a particular version of product by using labels or creating a branch with the source codeline, third-party codeline, and so on. This makes it easy to create a new workspace. You issue the “get” command and specify the version of the product you want. You can now also identify when something changes. If a third-party component changes, your version control system's “update” command will get you a new version. If a component is the same as you already have, it will not update it (see Figure 7-3).

Figure 7-3. Version tree for a workspace

This way, the version control system mirrors the build environment, and the history of changes in the build environment can also be tracked.

If (a) the version control tree is not a direct mapping to the build tree and your version control tool does not provide an easy way to perform the mapping, or (b) there is some reason not to keep every component in version control (some version control systems do not handle binary files well, and you may need to keep library files elsewhere if they do not change frequently), use a script or a makefile that copies the appropriate versions of the appropriate files to the appropriate places, depending on the version you want. This might be the easiest and best way to populate your workspace with the result of a nightly build.

All your configuration files and so on can also be tied together. If a new database library needs new configuration settings, you can give them the same label or check them in to the tip of the version tree together.

Some tools you can use to help you create this script are “make” and ANT. Both have interfaces to common version control systems.