CM: THE NEXT GENERATION: Configuration Management Planning

why the use of branching is overloaded.  When tools have insufficient means for managing the promotion levels, parallel changes, or any number of other requirements of SCM, the process turns towards the use of branching, merging and labeling to fill in.  The result is an unsightly maze of spaghetti branches.  Multiply this times thousands of files and you have a technology transfer nightmare ready to happen - along with a need for complex branching strategies

When using the right tools and processes, branching should primarily follow your product road map - one main branch per release.  When a file is first changed in that release, create that release branch for the file - a good tool will even automate this for you.  Resist creating branches for any other reason - which is not so easy if you have the wrong tools or processes.  Then your branching is well organized.  Your branch history is clear, as each file follows (possibly a subset of) the branch history for the product.  Automation becomes simpler because your tools and processes can anticipate the need for branching.  They can identify common ancestors for merging or the revisions to be used when a file branch doesn't exist for a particular release.

To some this sounds like an incredibly simplistic model.  And it is - that's why it's only possible if you have the right support mechanisms and algorithms to support it.  I've used this model for over a quarter of a century and would never consider abandoning it.  Perhaps there are some subtle variants I would consider, but having the tools manage the parallel development, build and baseline definitions, parallel checkout and promotion levels is just so much better than having to create and implement branching, labeling and merging strategies to do the same.

Build Automation and Tracking
"Build" is a term used for the process of taking source code and converting it into a set of deliverables (i.e. executables and other run-time files).  In today's development arena, builds are done by programmers, by system integrators, by verification and production teams. A record of what was built (and how), is known as a Build record, or often just a Build (i.e. the object rather than the process).

Obviously, automating builds can save a lot of people a lot of time.  But the real driver for Build automation is to improve and ensure quality of your deliverables.  Builds that are done manually are always subject to human error - and I've seen countless examples of hours, or even days, being spent unravelling such errors.  The time lost is one thing.  But if you cannot guarantee that what went into the Build is what you wanted to go into the Build, your customers will eventually be calling you to let you know.  Your CM Plan has to specify that builds will be automated.

Automating a build process requires the right tools.  The build process involves a few steps:

(1) Identifying what you want in the build
(2) Retrieving the source code that reflects what you want
(3) Running a build operation (series of complies, links, etc.)
(4) Packaging up the results into a deliverable format

Ideally, the identification step is done through some gating procedure which allows only approved changes through.  Sometimes the gating criteria might be "everything that the developer has said is ready".  Other times it might be "only those changes which fix critical release problems".  With some tools you may automate both of these types of selection processes (as well as others), while some require a manual selection process, typically because of a lack of