Featured Whitepapers

Tool Spotlight

Upcoming & Recent Webcasts

Home

Agile SCM

Private Workspaces: Where Development Process Meets CM Process

PDF

| Print |

E-mail

Written by Steve Berczuk, Brad Appleton and Robert Cowham

Wednesday, 15 March 2006 07:58

Software configuration management supports the delivery of application code in a reliable, repeatable manner. Having a CM process in place does nothing for the success of your organization unless you have mechanisms in place to develop application code reliably. Proper private workspace are a key element linking your SCM and your Development processes. In this article we discuss why they are important and how you can set up workspaces to help your team to be more effective.

I regard it a basic programmer's right that I should be able to, at any time, check out all the source code and build it.

-Caroline Foster on the Extreme Programming Yahoo Groups list, February 2003. Introduction

Being able to reliably create a version of your application that is consistent, regarless of where you are creating it is a key success factor for a project. All code starts in a developer workspace, and the more attention you pay to setting up the workspace, the better you will be in the long run. Private Workspace is one of the central patterns in the SCM Pattern Language[SCM Patterns]. This article also follows up on our promise to fill in some of the details from our February 2005 article The Importance of Building Earnestly Advantages of Private Workspaces

Effective private workspaces give you the following advantages:

Repeatability: Developers are building, testing and deploying many times a day. This gives you amble opportunity to find problems with the code and the deployment and install process before you unleash your code on customers (or Quality Assurance Teams). This repeatability leads to reproducibility.
Productivity: By providing a way for developers to control how and when they start working with new code you allow them to focus on the task at hand and minimize interruptions in thought (and enabling flow [flow]). This helps the individual. Likewise by providing build and test processes that developers run pre-commit, you catch integration issues before they make it into the repository, and improve the productivity of the team.
Progress: By enabling frequent integration and testing, you give developers more confidence in the codebase. This will enable them to feel more comfortable about integrating frequently, and moving forward in a regular fashion.
Accountability: Developing build and integration processes at the beginning of the process allows you to get the application to a point where you can demonstrate it to stakeholders earlier.

While it may not be trivial to create private workspaces, the benefits allow you gain make it well worth the effort.

What is a Workspace?

Before we go forward, let's define what a workspace is. A workspace is [SCM Patterns p 72]:

Code and other files that you are working on
Any locally built components, which you create from the source code (or retrieved from a repository in a controlled fashion).
Third party components at the correct version for the project.
Resources that you need to run and test the application. For example, if your application updates a database, you should have a private database schema, or if your application uses more than one schema, a private copy of the database,
Any tools that you need. If the tools are the same for all versions of your app, they can be centrally installed, or they are be associated with a specific component.

The key theme here is that you should have (in effect) a private copy of:

Any resource that you write to. This includes both "soft" entities such as source code and database space, as well as "hard entities" such as network devices or application servers.
Any resource that might change over the course of the project so that you can control when to 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.

Figure 2: The Private Workspace Pattern in Context

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, the hardware you need for developer testing need not be at the same price point as Production hardware. A desktop machine could host a number of developer databases, or developers could host the database on their machine.

Setup

Another common argument is that it's just too hard to set up multiple databases. Like any other aspects of your application, you should be able to create a database in a reproducible manner. If it is costly in terms of time and resources to create a new database at a certain version, you need to fix your database deployment process. Having these private workspaces give you many opportunities to debug the database deployment process through practices.

Ownership

I know a fair amount about database design, but I am by no means an expert, and I should let the experts have the last word for database changes. But I can do a fair amount to make the database developer's lives easier. For example, I can define test data sets that reproduce a problem in my private schema. If a new feature requires a minor table change, I can write the DDL to create new columns (or new tables). I certainly want the people with database expertise to review my work (that's how we can learn), but I don't need them to spend time on all of my dead-ends.

A key aspect of agile approaches is that there is a team with common of goals, but while a certain amount of division of labor is inevitable, there are may valid reasons for the team to cross boundaries.

Cautions

When your team has good Private workspace environments, you need to be sure that team members keep their workspaces in synch with the state of the codeline. The goal of Private Workspaces is to give team members small windows of time (and space) to work on tasks, not to isolate themselves for the long term.

Conclusion

Private Workspaces are a simple way to increase productivity. Setting up workspaces for your team may require a bit up-front work, but the increased rate of progress will more than compensate for the initial outlay of work. References & Further Reading

[Illusion of Control]
[SCM Patterns]1. Berczuk, S.P. and B. Appleton, Software Configuration Management Patterns : Effective Teamwork, Practical Integration. 2003, Boston, MA: Addison- Wesley.
[Flow] 1. Csikszentmihalyi, M., Flow : The Psychology of Optimal Experience. 1st ed. 1990, New York: Harper & Row. xii, 303 p.

Steve Berczuk is an Independent consultant who has been developing object-oriented software applications since 1989, often as part of geographically distributed teams. In addition to developing software he helps teams use Software Configuration Management effectively in their development process. Steve is co-author of the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration. He has an M.S. in Operations Research from Stanford University and an S.B. in Electrical Engineering from MIT. You can contact him at steve@berczuk.com.

Brad Appleton is an enterprise SCM/ALM solution architect for a Fortune 100 technology company. He is co-author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, the "Agile SCM" column in CMCrossroads.com's CM Journal, and a former section editor for The C++ Report. Since 1987, Brad has extensive experience using, developing, and supporting SCM environments for teams of all shapes and sizes. He holds an M.S. in Software Engineering and a B.S. in Computer Science and Mathematics. You can reach Brad by email at brad@bradapp.net

Robert Cowham is the founder of Vaccaperna Systems providing SCM consultancy and training to organisations. With 20 years of experience in software development, he has long had an interest in SCM, and has worked with clients around the world in this arena during the last 7 years. He is on the committee of the CM Specialist Group of the British Computer Society for whom he has organised several events, including their 2-day conference in 2003 (and their upcoming 2005 event). He has a BSc in Computer Science from Edinburgh University and is a Chartered Engineer (CEng MBCS CITP). You can contact him at rc@vaccaperna.co.uk

Set as favorite

Bookmark

Email this