High-level Best Practice Six(6) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first five areas and there practices are already discussed.

Process

- Track change packages. Even though each file in a codeline has its revision
history, each revision in its history is only useful in the context of a set of related files. Change packages, not individual file changes, are the visible manifestation of software development. Some SCM systems track change packages for you; if yours doesn’t, write an interface that does.
- In order to make propagating logical changes from one codeline branch to another easy, tracking change packages has a benefit. However, it’s not enough to simply propagate change packages across branches; you must keep track of which change packages have been propagated, which propagations are pending, and which codeline branches are likely donors or recipients of propagations.
- SCM process should be able to distinguish between "What to do" and "What was done".
- Every process, policy, document, product, component, codeline, branch, and task in your SCM system should have an owner. Owners give life to these entities by representing them; an entity with an owner can grow and mature.
- The policies and procedures you implement should be described in living documents; that is, your process documentation should be as readily available and as subject to update as your managed source code.

High-level Best Practice Two(2) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first area and its practices are already discussed.

The Codeline
It is a set of source programs or files required to develop a software. Codelines are branched, and the branches evolve into variant codelines embodying different releases.
The best practices are :
- Give each codeline a policy : It is the essential user’s manual for codeline SCM. The policy of the development codeline should state that it is not for release or the policy of the release codeline should state that it is not for testing or bug fixing. It specifies the check-ins for the codeline.
- Give each codeline an owner : After the policy is defined for a codeline, there would be situations where the policy is inapplicable or ambiguous. When the developers face these ambiguities, they will turn to the person who is in charge of the codeline. There has to be a owner of the codeline because if there would be no owner, the developer will create their own workarounds without documenting them.
- Have a mainline : A mainline is the branch of a codeline that evolves forever. A mainline provides an ultimate destination for almost all changes – both maintenance fixes and new features – and represents the primary, linear evolution of a software product.