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!