SCM

Most of the people have confused about Software Configuration Management (SCM), because may be they are not aware of SCM systems and processes or not known its significance and importance.

The below is the perfect explanation about SCM for all the IT people to get clear vision and clarity about the SCM systems and processes.

Did you know that CM systems back in the day were basically people? This is where the term “check-in” & “check-out” comes from- it refers to the days when there where actual software librarians would record peoples changes and check them in and out like books on disk or punch cards. It’s mind boggling to think of software this way.

If I was to ask software developers today what “software configuration management” was, they would probably say “SCM? Like Subversion?” Incorrect! SCM is not the same as a version control system. Yes, your version control system is an SCM tool (confusing?) but SCM is a broader discipline and technique that encompasses the management of change in software.

The introduction to the IEEE “Standard for Software Configuration begins with:

SCM constitutes good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by:

Providing a structure for identifying and controlling documentation, code, interfaces, and databases to support all life cycle phases

Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy

Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc.

Let’s be clear- all of the things on this list do not fit under the heading of your version control system.

Many of them will require practices and policies to maximize your development efforts and methodologies. With version control, release engineers will still have to perform some of these SCM related functions:

Merge early and often

Enforce a workflow for development teams to follow

Record and have full visibility into all of the changes that were made

Write build and compiler scripts

Automate builds, deploys and tests

Understand the dependencies between projects and code

Maintain the development environment for a team

Be responsible for the final product going out the door

That’s just the tip of the iceberg. A talented release engineer or SCM expert can do all of those things independently, but his or her job would be a lot easier with SCM tools that can automate and facilitate the necessary practices and processes. (This includes version control, compilers, debuggers, editors, continuous integration machines, automated deploy, and the ITS system.)

At its core, SCM answers the question “Somebody did something, how can one reproduce it?”

In addition it’s about understanding and establishing relationships among items that are likely to change. It’s a tricky job, not one that’s easily understood. We have to understand the relationships between versioned artifacts, like code, hardware, documents, design models and even directory structures. In addition we have to do all of the necessary things to make those versions valuable to our organization. We have to design process, workflow, and automation, build automation, reports and security.

With all of this, don’t tell me that SCM is the same as version control. Trust me on this one!