Source Control Management (SCM) is more than just a tool for developers to use for collaboration in development, tools such as Git, Mercurial and SVN, which we have already written about extensively. Beyond tools SCM is also a set of best practices that can include the concept of a change lifecycle and a change request system. Confusingly the abbreviation SCM doesn’t just stand for Source Control Management, but also for several other closely related terms, including Source Code Management (from the world of Git), Software Control Management and more commonly Software Configuration Management; these should not be confused. Another common misconception is that SCM is the same as Revision Control. Rather than explain the difference between all these terms (not the purpose of this article) we will define and elaborate what we mean by Source Control Management best practices and will use SCM in this sense of the meaning.
So what are SCM best practices and what effect do they have?
SCM is all about the core project files containing source code and how these shared files are managed, a vital system that enables developers to work together on the same development project whether they are in the same room or a continent away. If code gets messy then SCM allows you to revert to an earlier clean version, often the quickest solution to fixing the problem. However developers working together on a project using the same tools still need a common approach to tool use for best effect, – a set of tool use best practices.
Simple steps that can be taken to reduce development risk and improve efficiency
- Starting with the basics, choose a source control system.
- Keep your source code in source control (but not files generated / compiled from it).
- Ensure the working file is from the latest version of the source file.
- Only Check-out the file being worked upon.
- Check in immediately after alterations are completed.
- Review every change before committing, utilize the diff function!
- Commit often, – every commit provides a rollback position.
- Make extensive, – detailed notes in the check-in comments about why the changes were made.
- Developers must commit their own changes (only).
- Use the ignore button for files that should not be committed, consider adding pre-commit filters to prevent the wrong kinds of file (such as accidental check-in of personal user settings docs) from entering the source control
- Ensure external dependencies are added to the source control, a common problem where everything works great on the contributing developers system but not elsewhere because they forgot to add dependent files to the system.
You might think all these steps are pretty obvious, however it is surprising how often the basic steps are missed, leading to errors and committed files that have no business being in the repository. No matter the SCM system used, these basic steps prevent mistakes and makes life so much easier for development team members. Before starting a new project it is worth recapping these steps / rules with the team for the sake of work culture and team harmony (make them more Agile).
Of course when dealing with safety critical development, for example medical device development or on larger projects where complete transparency and traceability are required for hundreds or thousands of contributing developers, SCM alone is just insufficient. An upgrade / switch to ALM software is necessary automating many of the steps above.
codeBeamer ALM: Source Control Management
codeBeamer ALM software supports all the major DVCS so no matter the developers preference (integrating with Git, Mecurial and SVN) and since any number of repositories can be added to a project (within reason) codeBeamer ALM provides the freedom that most developers dream of. codeBeamer ALM provides complete Application Lifecycle Management and is designed for Scaling Agile and Extending Agile (DevOps) enabling automated testing, all within the Scaled Agile Framework, the SAFe way to Scale Agile.