When deploying new software configuration management (SCM) tools, implementers sometimes focus on perfecting fine-grained activities, while unwittingly carrying forward poor, large-scale practices from their previous jobs or previous tools. The result is a well-executed blunder. This paper promotes some high-level best practices that reflect the authors’ experiences in deploying SCM.
High-level Best Practices
in Software Configuration
Management
Laura WingerdVice President of Product TechnologyPerforce Software Inc.Christopher SeiwaldPresident & CTOPerforce Software Inc.
Eighth International Workshop onSoftware Configuration ManagementBrussels, July 1998AbstractWhen deploying new software configuration management (SCM) tools, implementers sometimes focus on perfecting fine-grained activities, while unwittingly carrying forward poor, large-scale practices from their previous jobs or previous tools. The result is a well-executed blunder. This paper promotes some high-level best practices that reflect the authors' experiences in deploying SCM.
Introduction"A tool is only as good as you use it," the saying goes. As providers of software configuration management tools and consultants to software companies, we are often asked for sound advice on SCM best practices - that is, how to deploy SCM software to the maximum advantage. In answering these requests we have a bounty of direct and indirect SCM experience from which to draw. The direct experience comes from having been developers and codeline managers ourselves; the indirect experience comes from customer reports of successes and failures with our product (Perforce) and other SCM tools.
The table below lists six general areas of SCM deployment, and some coarse-grained best practices within each of those areas. The following chapters explain each item.
Workspaces . Don't share workspaces.Where developers build, test, and debug. . Don't work outside of managed workspaces.. Don't use jello views.. Stay in sync with the codeline.. Check in often.
Codelines . Give each codeline a policy.The canonical sets of source files. . Give each codeline an owner. 1. Have a mainline.
Branches . Branch only when necessary.Variants of the codeline. . Don't copy when you mean to branch.. Branch on incompatible policy.. Branch late.. Branch, instead of freeze.
Change Propagation . Make original changes in the branch that has evolved the least Getting changes from one codeline to another. since branching.. Propagate early and often.. Get the right person to do the merge.
Builds . Source + tools = product.Turning source files into products. . Check in all original source.. Segregate built objects from original source.. Use common build tools.. Build often.. Keep build logs and build output.
Process . Track change packages.The rules for all of the above. . Track change package propagations.. Distinguish change requests from change packages.. Give everything an owner.. Use living documents.The Workspace changes are caused by external events The workspace is where engineers edit beyond your control. A typical example of a source files, build the software components jello view is a workspace built upon a tree of they're working on, and test and debug what symbolic links to files in another workspace they've built. Most SCM systems have some - when the underlying files are updated, your notion of a workspace; sometimes they are workspace files change. Jello views are a called "sandboxes", as in Source Integrity, source of chaos in software development. or "views", as in ClearCase and Perforce. Debug symbols in executables don't match Changes to managed SCM repository files the source files, mysterious recompilations begin as changes to files in a workspace. occur in supposedly trivial rebuilds, and The best practices for workspaces include: debugging cycles never converge - these are just some of the problems. Keep your Don't share workspaces workspaces firm and stable by setting them A workspace should have a single purpose, up so that users have control over when such as an edit/build/test area for a single their files change.developer, or a build/test/release area for a product release. Sharing workspaces Stay in sync with the codelineconfuses people, just as sharing a desk As a developer, the quality of your work does. Furthermore, sharing workspaces depends on how well it meshes with other compromises the SCM systems ability to peoples' work. In other words, as changes track activity by user or task. Workspaces are checked into the codeline, you should and the disk space they occupy are cheap; update your workspace and integrate those don't waste time trying to conserve them. changes with yours. Don't work outside of managed As an SCM engineer, it behooves you to works... [download for more]
