Source Code Management

Whether described as a version or revision control system, Source Code Management (SCM), or some other name, the more common and more popular SCMs provide a host of features and capabilities to make certain aspects of the development process easier, faster, or at a minimum, more stable. These include the following:

• Allowing multiple developers to collaborate on the same parts of the same code base without having to worry (as much) about overwriting each other's work 
• Keeping track of all versions of a code base, and who made what changes to it at each point that a new version was committed
• Providing visibility into what changes were made as each new version was committed
• Maintaining different versions of the same code base for specific purposes, probably the most common variation of which is having versions for different environments that code changes are worked on and promoted through, which might include:
  • Local development environments
  • A shared development environment, where all developers' local code changes first mix together
  • A shared test server for QA and broader integration testing
  • A User Acceptance Testing server, using realistic, production-like data, which can be used to demonstrate functionality to whoever needs to give final approval for changes to be promoted to a live environment or build
  • A staging environment that has full access to a complete copy of production data, with an eye towards being able to perform load and other tests that require access to that dataset
  • The live environment/build code base

While there are at least a few major variations in how such systems function under the hood, from a developer's perspective, those functional differences may not really matter, so long as they function as expected and function well. Taken together, those basic capabilities, and the permutations of them with various manual efforts, allow the following:

• Developers to roll back to an earlier version of a complete code base, make changes to it, and re-commit those as a new version, which can be useful for:

  • Finding and removing or fixing changes that unexpectedly raised significant issues after being committed or even promoted
  • Creating new branches of the code to experiment with other approaches to committed functionality
• Multiple developers with different areas of expertise to work on parts of the same problem and/or code, allowing them to get that problem solved, or that code written much faster
• Developers with stronger architectural backgrounds or skill sets to define bare-bones code structures (classes and their members, perhaps), then commit them to be fully implemented by someone else
• System domain experts to easily review changes to the code base, identifying risks to functionality or performance before those get promoted to an unforgiving environment
• Configuration managers to access and deploy different versions of the code base to their various target environments

There are probably a lot of other, more specific applications that a good SCM system, especially if it's got good ties to the development and code promotion processes, can help manage.