SCM Best Practices: Determining Which Practices Are Best for You

  • Branch only when necessary
  • Don't copy when you mean to branch
  • Branch on incompatible policy
  • Branch late
  • Branch, instead of freeze
  • Change propagation (getting changes from one codeline to another)
  • Make original changes in the branch that has evolved the least since branching
  • Propagate early and often
  • Get the right person to do the merge
  • Builds (turning source files into products)
  • Source + tools = product
  • Check in all original source
  • Segregate built objects from original source
  • Use common build tools
  • Build often
  • Keep build logs and build output
  • Process (the rules for all of the above)
  • Track change packages
  • Track change package propagations
  • Distinguish change requests from change packages
  • Give everything an owner
  • Use living documents

According to Anne Mette Jonassen Hass [2]:

  • Establish Baselines
  • Identify Configuration Items
  • Establish a CM System
  • Create or Release Baselines
  • Track and Control Changes
  • Track Changes
  • Control Changes
  • Establish Integrity
  • Establish CM Records
  • Perform CM Audits

Cisco [3], the hardware manufacturer recommends the following:

  • Create standards
  • Software version control and management
  • IP addressing standards and management
  • Naming conventions and DNS/DHCP assignments
  • Standard configuration and descriptors
  • Configuration upgrade procedures
  • Solution templates
  • Maintain documentation
  • Current device link and end-user inventory
  • Configuration version control system
  • TACACS configuration log
  • Network topology documentation
  • Validate and audit standards
  • Configuration integrity checks
  • Device, protocol, and media audits
  • Standards and documentation review

Stephen Berczuk and Brad Appleton [4] assert, " Although there are many "best practices" for SCM, to use them effectively, you must understand how they relate to other practices you use and the environment in which you use them."

There are several "best practices" listed by Brad Appleton on his website [5]:

  • SCM Patterns
  • Agile SCM
  • Branching Best Practices
  • Build Reproduction Best Practices
  • Workspace (development "sandbox") Best Practices
  • ClearCase Practices
  • Although not always listed as best practices, the application or implementation the following critical success factors for SCM could certainly help to ensure project success:
  • Senior management support
  • SCM planning
  • Change control and escalation procedures
  • Simple practices and tools
  • Private workspaces
  • Codeline policies
  • Communications
  • Prudent branching and frequent merges
  • Intelligent builds

Senior management support: That is, nothing succeeds without their support! Senior management provides the resources, serves as liaison between executive management and staff, and must be in the communication loop.

SCM planning: Should there be a SCM Plan or just SCM planning? SCM planning is performed first at the project level, and then it's communicated throughout the project. If a SCM plan is used, it must be meaningful, must be revised after each phase, and should be in sync with organizational planning.

Change control and escalation procedures: Must be well documented, enforced by the Project Manager and supported by all levels of management; cannot hinder the project team; must be effective; must be efficient; and must be consistent and repeatable.

Simple practices and tools: Practices should cause good things to happen and should be communicated and understood. Tools should be easy to use and pragmatic, and should enhance communication and reduce rework.

Private workspaces: These are developer areas that must contain:

  • Source code being edited
  • Locally-built components
  • Objects that cannot or will not be built
  • Built objects for all the code in the system
  • Configuration and data needed to run and test the system
  • Build scripts
  • Information identifying versions of all components in the system
  • Codeline policies: Brief "rules of the road" that include:
  • The kind of work summarized by the codeline, such as development, maintenance, or a specific release, or function
  • How and when elements should be checked in, checked out, branched, and merged
  • Access restrictions for certain individuals
  • Import/export relationships are (is) the:
  • o Names of

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.