Software Configuration Management
History
What is SCM
Modules of SCM
Configuration Manager
History:
US dept. of defense maintain
and operates tons of verities of military equipment’s. Obviously it’s tedious
if you don’t have a system to track and maintain the items. So they approached Software Engineering Institute (CMU) to
develop a better process to track, maintain, status etc. of military
inventories. It’s SEI and other groups of industry experts developed CMMI/SCM.
Actually SCM is part of CMMI. CMMI
contains 22 process areas, all these process talks about how to improve SDLC
life cycle from requirement to deployment (complete SDLC). CMMI model can be
adopted to other non-software industry as well.
Here onwards I specifically talk about SCM
(for software / IT).
Basically what SEI and
others they did was, gathered all of existing knowledge/experience of software
development/any other industry. They gone through day to day activities of
configuration management, pointed out main tasks, etc. Out of this knowledge/experience
and forethoughts they developed a process called SCM.
Main idea behind the
Process is to reuse the existing knowledge
of a domain(software or any), refine, improve and follow it. (In other words, don’t re-invent
the wheel)
Processes are key for success
of any project because, every individual have different thoughts so it creates
confusion. “Process brings order out
chaos”.
What is SCM:
“The purpose of Configuration Management
(CM) is to establish and maintain the integrity of work products using configuration
identification, configuration control, configuration status accounting, and configuration
audits. “– CMMI. I know its bit
vague, since SCM can be adopted by other industry’s they defined it in generic
term.
Simplified,
the purpose of SCM is:
Identify all the documents (design,
test plan …), source code, software’s/hardware related to a project.
Control
accidental release of software into prod/QA, prioritize the bugs …
Status
approved changes, revision history, change logs, change request records …
Audit
basically to check, whether your project actually follows CM process according to
SCM standard.
SCM, is involved in entire
SDLC. At first people think it’s just a source code control/repository but it’s
beyond. It involves from requirement to deployment. Don’t believe me, here you
go:
a Document’s repository
(requirements, designs, project plans, test plan, release plan, deployment plan…)
b Source
control/repository
c Build management
(branching / merging / baseline / backup the source code)
d Release management
e Deployment management
Typical SCM, in a project
looks like this: A configuration manager he or she will be responsible for overall
CM related activities like to create a CM plan, build plan, release plan,
conduct CM audits and to spread the CM process knowledge across the team.
Agile development methodology has introduced the term called Continuous integration / Continuous deployment,
basically they are fine-tuned version\variation or lean version of SCM process.
Govt. projects like space,
army, medical… they fully adhere to SCM and they can’t do fast phased
development like typical IT projects, because of product criticality like life
and death. So there is no one fit size
for all, some will follow lean scm and few typical cmmi scm.
Modules of SCM:
Typical SCM modules occupy a
book, but I try to explain briefly main modules of SCM are:
Document repository: SCM manages all the project related documents for ex: project
plan, test plan … here process tracks versions/stages of docs like from draft
to approve what changed, doc version numbers etc. usually docs will be stored
separate doc repository for ex: share point and not in source control.
CM Plan: It’s a document
which describes over all CM activities, like who is the CM, where is source
code located and its path, docs repository path, audit plans, build/release
activities. CM plan might have reference to build/release plans. Basically if
any outsider looks into this doc he or she should able to figure out about project
CM activities.
Source code management: Source control like TFS, SVN, Git are used to store the source
code. It’s were all the project related code will exist. From here developers will
check in or out.
Build systems: It’s a system / box
where code will be pulled from source control and do build of a project every
night or as soon as user checks in source code.
Change control: typically consist
of product stake holders, PM, CM … to control the change request to project.
Release management: is process where
you define how to push source code\binaries, bundle and deploy to Prod or QA. It
also contains release notes, known bugs\issues.
Audits: checks whether, users are checking the code with proper comment\issue
number, code backups are taken, process mentioned in the doc and followed are
matching etc.
Configuration (Release) Manager:
He or She will be responsible
for overall CM related activities inside a project. Its full time or part time
job based on the project scale. I try to briefly point out the CM roles and
responsibility:
a)
After project
initiation CM activities will start
b)
Create CM plan, co coordinating
with PM, Tech lead, project stake holders
c)
Over all in charge or
admin of source control. CM decides who and what access will users will have. Only
few of team members can have admin access to source control
d)
Creates build plan \
system. Plan will have at what frequency build will should happen, a unique id
for the build, whether to push binaries to specific location or not and many
other things
e)
Release management,
package creation, release notes …
f)
Spreading the CM
process awareness among the team members. By presentation, demos …
Summary:
You like it or hate it, but
you can’t ignore SCM. Waterfall, Agile, Spiral … they all follow one way or
other a CM process.
