Top 10 Best Practices in Configuration Management

the Main.  Otherwise, not.  Decisions have to be made as to when the Main switches from one release to another.  Directions need to be given for how to deal with changes which are for other releases not on the main trunk, hopefully without delaying a
developer's check-in operation (which would in turn either delay other development or incur unnecessary parallel development and the resulting merging and re-testing). 

A Main-branch-per-release strategy is simple.  You make the change in the branch that the request has targeted.  The way you do that is always the same, regardless of
release or timing.  Some shops (and tools) support making changes directly to the trunk, without any branching - these also support the concept of a change package.  In more advanced tools, changes to older releases can be automatically inherited (optionally) into newer streams (e.g. if the code has not changed between the older and new stream).
The process is simpler and supports stream-based branching strategies (more on that later).

6. Dumb Numbering

Source files have names individually chosen by each developer.  They don't even have to be unique (although you need a unique identifier for every source object).   Not so with problem numbers, requirements, activity codes, test cases, etc.   Naming these would be considered an onerous task.  In a relational world, this is not so much a problem.  But in an engineering database, everything needs a unique id so that it can be referenced (for traceability purposes) and identified for configuration identification purposes. 

Too many want to make the "unique identifier" a way to know the content: system+priority+3 digit number.  The problem happens when the priority changes or the system is split into two. 

All of your unique identifiers suddenly change!  Unique identifiers must be numbered using a dumb numbering system.  For the most part, this means a fixed prefix plus a number (e.g. a.1232 for an activity code).  Some might want to tack on a product prefix, only to find that the same requirement or test case is going to be used in the next product, invalidating the id. Unique ids need to be kept dumb. 

There is room for some prefacing when the preface cannot change.  This occurs when a "parent" record owns the record being identified.  For example, a change record might be numbered sequentially as a sub-record of the developer making the change.  History cannot be changed so this would be an appropriate prefix.  Perhaps documents could be sequentially numbered within their document category (tech note:  TN.33, project status PS.412, etc.) - in this case the document type record is the "owning parent". 

But apart from such ownership sub-record prefaces, putting data into a unique id is just asking for trouble.  In the old days this was a common practice because not everyone had access to the data records which described the object.  That's different today, or at least if
it's not, you have other problems that must be remedied first.

The Top Five

We're down to the final five.  These are not just important, but critical for moving your process forward.  Perhaps you're familiar with all of these already.  If you're not, get familiar with them so that you understand the impact clearly.

5. Continuous Integration with Automated Nightly Builds from the CM Repository

Your development team is continuously submitting changes to your repository.  You can put code reviews in place (highly recommended - in fact this would have made the top five if the topic were a bit broader), have "unit testing" (i.e. change testing) rules, and perhaps
a number of other software engineering guidelines.  But if you don't build the system regularly and test it, you're risking some major delays as unforeseen incompatibilities bring new "builds" to a halt.  If 1,000 software updates have been submitted, it may take a while to narrow down the issues to their caused, or even to isolate the