Let us go through some goals of SCM in general, which when achieved are transformed into benefits for your Organization.
Sandboxing with private build before check-in:
Rapid application development and frequent changes to source code demands frequent check-ins, it is important that the developer has some confidence that the code will successfully build and pass unit testing before he integrates it into the main code line. By utilizing private check-ins at an isolated area off the main line (e.g., a private branch) and building the code in the private sandbox before checking it into the main code line, the developer can test and debug the code locally, and only after passing the build and unit tests can the code be integrated into the main code line. The benefit of this SCM goal is that it decreases likelihood of a failed integration build.
In today’s software organizations, that are adapting to Agile methodologies, application features are usually broken up into the smallest size tasks possible so that each task can be tracked, integrated, and debugged. One of the goals of SCM is to enable an organization to perform task-oriented development that includes providing visibility into changes made for each task, supporting the ability to work by task instead of by individual file, to merge changes from one configuration to another, and to revert changes for a task if needed. Biggest benefit of task oriented development is maximum utilization of resources.
Ability to revert to last good working version when integration testing fails:
Even though a private build prior to integrating changes reduces the chance of a broken build, there are still cases when an integration build will fail. For example, if two developers commit changes at about the same time, it is possible that each one did not test his individual changes with those of the other.
In the event of a build failure, it is a goal of SCM i to be able to revert to the last good build so that other developers have a clean configuration of code to use for their own work. Reverting to the last good configuration allows one engineer to fix the broken build while the rest of the team can continue working on their tasks and verifying the work with their own private builds.
Having all development work from the main line often causes chaos. This can be mitigated by use of a development hierarchy. A development hierarchy is simply a hierarchical representation of the dependencies between groups that includes process steps such as integration, quality assurance, and code reviews.
A separate code configuration is used for each stage in the hierarchy. It is a natural extension of private branching. As a change is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Continuous multi-stage integration can be employed to automatically build and test changes as they are pushed to each stage.
Goal of SCM is to support the simple creation of a hierarchy, give visibility into the changes at each stage, and enable straightforward merging between stages. Utilizing a staging hierarchy along with private versioning gives the added benefit of more code stability at each step up the hierarchy.
Ability to revert and retarget changes:
Generally software requirements are driven by the business and can be changed throughout the SDLC. For this reason, it is the goal of SCM system to be able to identify the changes made for a particular feature and remove the changes from one iteration and retarget them to the next.
Agile development methods focus on a simple design for the features being developed during the current iteration and not on designing an architecture that will meet the needs of all features for the lifespan of the product.
For this reason, code must periodically be refactored to make it easier to understand and reusable for other features. Thus a goal of SCM to support refactoring of code and still be able to trace through the history of changes.
Geographically distributed development:
With technology it is possible today to utilize specialized talents that are even geographically distributed. Due to this distributed nature of software development organizations, it is not always possible to assemble cross-functional teams without involving team members at more than one location. For these scenarios, it is important that the SCM provides a central repository so that members of distributed teams can work together.
Continuous integration rather than large-scale integration phases at end of project:
One major goal of SCM is to enable continuous integration of changes. Each developer should submit changes as soon as a task is complete. Continuous integration build servers can be used to poll the code repository periodically and, if any changes exist, build the new configuration. Equally important to this concept is the immediate reporting of build status. If a build breaks or any of the unit tests fail, the developer who recently committed the changes must fix the code right away.
What benefits of Software Configuration Management you have experienced for your organization?