Getting Started with Agile SCM

[article]
Summary:
A prerequisite to any of the Agile SCM practices, such as integration build, private build, unit tests, and the like, is being able to set up a developer’s private workspace with the right code and tools so that you can code, build and test. In this article, we discuss the important, and often overlooked process of creating a development workspace, which is to say, getting started.

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 will be able to 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.  

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. 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, 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.

Pages

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Oct 15
Nov 09