I’ve written an article previously alluding to me being published on SD Times magazine, in it I’ve provided an extensive list of Software Configuration Management Best Practices as well as Pitfalls.

I believe that list is quite valuable and can be used as a guide for any new Build and Release Engineer. Here it is in its entirety (I contributed about 70% to the list):

SCM Best Practices

• View change management as an integrated approach to managing any change from any credible internal or external source.
• Carefully consider what your longterm SCCM strategy will be. Are you a standalone SCM shop, do you want to implement a standardized SCCM solution, or would a heterogeneous SCM solution be the best course?
• Implement a consistent SCM process across all teams. This enables unified reporting, metrics capture, subsequent decision support and asset reuse.
• Integrate processes, supporting tools and automation to drive the change management process. All project work—asset, change and project and portfolio management processes—must be managed in an integrated fashion. This includes work that was part of the original plan, and work that is the result of replanning due to change.
• Manage so that your development teams are always responsive to change. Policies and practices should reflect this.
• First optimize your processes, then choose the tool/vendor that best fits your processes. Automating suboptimal processes and institutionalizing poor practices is costly and counterproductive.
• Make sure your tools are flexible enough to model your processes. An enterprise should not be forced to modify the way it does business to fit its tools.
• Configure your workflow to how you need to work, not how some tool wants you to work.
• Make sure your tools can be modified to adapt to your changing processes. Tools must not inhibit the evolution of enterprise processes.
• Don’t forget about disaster recovery. SCM/CM is mission-critical, and an abrupt halt will be damaging to the entire enterprise. Understand how your system works and have a DR plan in place that you actually test.
• Get service-level agreements. Whether it’s an agreement within the IT group regarding server management of the build farm servers, or with the QA group for release management, having such agreements helps to enforce processes and precisely define roles.
• Track change packages. Even though each file in a codeline has its revision history, each revision in its history is useful only in the context of a set of related files. Some questions about source file changes can’t be answered unless you track change packages—sets of files related by a logical change. 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.
• Embrace branching, especially if the tool you are using is strong in supporting them. Snapshots, private workspaces and version-specific branches all allow your team to work in parallel and be fast and innovative.  But branch only when necessary: The codeline should be branched when its
  users need different check-in policies.
• Use a common base folder structure for all projects. Just so staff can easily find files, and engineers moving from one project to another know where to look for files without training and hunting.
• To support distributed development teams, manage content in a central repository, keeping remote teams up to date in near real time via remote caching agents that serve the local team. This avoids the server replication and artificial conflicts among end users caused by time latencies inherent in older, replication-based solutions.
• To support agile development teams, embrace continuous integration. This build model is a must for any agile SCM team as the benefit of automation will greatly enhance the team’s overall productivity output.  Build often is the motto.
• To support agile development teams, commit to accurate iteration planning. Plan only a limited number of projects that the team can realistically finish in an iteration.
• To support agile development teams, maintain an iteration schedule, the shorter the better (about two weeks to a month is a good range).
• To support agile development teams, conduct daily stand-up meetings. These are meant to resolve obstacles any of the team members may be experiencing quickly and efficiently.