Professional Documents
Culture Documents
management
What is CM?
Configuration management (CM) is the discipline of
controlling the evolution of complex systems; software
configuration management (SCM) is its specialization
for computer programs and associated documents.
IEEE standard 729-1983 definition
Identification: an identification scheme reflects the
structure of the product, identifies components and their
type, making them unique and accessible in some form
"This program worked yesterday. What happened?
"I cant reproduce the error in this configuration.
"I fixed this problem long ago. Why did it reappear?
"The online documentation doesnt match the
program.
"Do we have the latest version?"
CM in a hardware-development environment
A computer has a processor, a mainboard, some
memory, a hard drive, a monitor, and a keyboard.
Each of these hardware items has an interface
that connects it to other hardware items.
Your mouse has a plug, and your computer has a
port into which you plug your mouse, and makes
everything works.
If the plug on the mouse was not compatible with
the port on the computer, there would be no way
to connect the two pieces of hardware into a
working system.
Configurati
on
manageme
nt
Documenta
tion CM
Code CM
WHY CM?
Software configuration management must ensure
that:
software components can be identified;
software is built from a consistent set of components;
software components are available and accessible;
software components never get lost (e.g. after media failure
or operator error);
every change to the software is approved and documented;
changes do not get lost (e.g. through simultaneous updates);
it is always possible to go back to a previous version;
a history of changes is kept, so that is always possible to
discover who did what and when.
configuration
configuration
configuration
configuration
release.
identification;
item storage;
change control;
status accounting;
Software Configuration
Management Activities
(Software configuration management plan)
Types of CI
The type field of a CI identifier should identify the
processing the CI is intended for. There are three
main types of CI:
source CIs;
derived CIs;
tools to generate derived CIs from source CIs.
Configuration identification
Configuration identification conventions should state how
to:
name a CI;
decide who is the control authority of a CI;
describe the history of a CI.
Baselines
A baseline' is a CI that has been formally reviewed and
agreed upon (i.e. approved), and declared a basis for further
development.
Although any approved CI in a system can be referred to as
a baseline, the term is normally used for the complete
system.
Early baselines contain only documents specifying the
software to be built; later baselines contain the code as well.
The CIs in a baseline must be consistent with each other.
Examples of consistency are:
code CIs are compatible with the design document CIs;
design document CIs are compatible with the requirements document
CIs;
user manual CIs describe the operation of the code CIs.
Variants
The term variant' is often used to identify CIs
that, although offering almost identical
functionality, differ in aspects such as:
hardware environment;
communications protocol;
user language (e.g. English, French).
Software author
Software authors create low-level CIs, such as
documents and code.
Document writers are usually the control authority
for draft documents.
Programmers are normally the control authority
for code until unit testing is complete.
Software libraries
A software library is a controlled collection of configuration
items (e.g. source module, object module and document).
Low-level CIs are developed and stored in libraries (e.g.
source and object libraries), and then extracted to build
high-level CIs (e.g. executable images).
As a minimum, every project must use the following
software libraries to store CIs:
development (or dynamic) libraries
master (or controlled) libraries
archive (or static) libraries
Media control
All CIs should be stored on controlled media (e.g. tapes, disks).
Media should be labelled, both visibly (e.g. sticky label) and
electronically (e.g. tape header).
The label should have a standard format, and must contain the:
project name
configuration item identifier (name, type, version)
date of storage
content description
VERSION CONTROL
Version control
Management of multiple revisions of the same unit of
information.
Changes identified by incrementing an associated number
or letter code - revision number, or revision level.
Revision numbers (levels) are associated historically with
the person making the change
Repository
A server where the files are stored.
Check-Out
copies a working copy from the repository
(the opposite of an import).
Change
A specific modification to a document under version control.
The granularity of the modification considered a change
varies between version control systems.
Change List
Commit or Check-in
Update
copies the changes that were made to the repository into your working
directory.
(opposite of a commit).
Merge / Integration
brings together (merges) concurrent changes into a unified revision.
Revision or version
one version in a chain of changes.
Conflict
Occurs when two changes are made by different parties to the
same document or place within a document.
Resolve
The act of user intervention to address a conflict between
different changes to the same document.
Example
CM Clients
Trunk
CM Server
Version A
Branch
Machine A
Version A.1
Branch
Check Out
Check In
C
Machine B
B
Check Out
D
Merg
e
Check In
Version B
Branch
History
CM systems save the files history.
Old versions can be viewed, compared, and
downloaded.
New versions can be (irreversibly) replaced with
old versions and wiped off the map.
Central repositories
Files are saved in a central file server.
Developers can view the files in the repository,
through the use of filters.
Labels
Several files can be labeled together.
Allows :
Access to the label as a whole set of files.
Changes to the labeled files as a unit.
Check-in
Copies a file into the database.
The version you see is (usually) the latest version
that was checked in.
The old version is kept and can be accessed later.
Checkout
Copies the database file to your personal folder,
and raises a flag on the database copy.
Need to check out before checking in.
Scenario
Suppose we have two co-workers, Harry and Sally.
They each decide to edit the same repository file
at the same time. If Harry saves his changes to
the repository first, then it's possible that (a few
moments later) Sally could accidentally overwrite
them with her own new version of the file. While
Harry's version of the file won't be lost forever
(because the system remembers every change),
any changes Harry madewon'tbe present in
Sally's newer version of the file, because she
never saw Harry's changes to begin with. Harry's
work is still effectively lostor at least missing
from the latest version of the fileand probably
by accident.
Versioning Models
Lock-Modify-Unlock Solution:
Unnecessary serialization:
Different parts of a file dont necessarily overlap.
E.g.: Alice works on the beginning of a file, Bob wants to
edit the end of the same file.
The Copy-Modify-Merge
Solution
Aviva and Arik
both check out
file A.
Here, checkout
has no locking
effect its just a Read
local copy.
A
Repository
A
Read
The Copy-Modify-Merge
Solution
Both edit their local
files.
Repository
A
Aviva
Arik
The Copy-Modify-Merge
Solution
Aviva checks in
her file to the
repository first.
Repository
Aviva
Write
Aviva
Arik
The Copy-Modify-Merge
Solution
Now, Arik tries to
check-in his file.
He gets an upto-date check
error
Write
Arik
Repository
Aviva
Aviva
The Copy-Modify-Merge
Solution
Arik updates his local
copy to contain the
changes made by
Aviva. Changes are
added to the local file.
During this merge,
conflicts may occur.
Read
A
(=Aviva+Arik
)
Repository
Aviva
Aviva
The Copy-Modify-Merge
Solution
A new merged
file is created on
Ariks machine.
Repository
Aviva
Aviva
The Copy-Modify-Merge
Solution
Arik commits his
file to the
repository.
Repository
B
Write
Aviva
The Copy-Modify-Merge
Solution
Aviva updates her file
from the repository.
Repository
B
Read
Introduction
All software configuration management activities shall
be documented in the Software Configuration
Management Plan
Each SCMP section must document all software
configuration management activities, specifically the:
About SCMP
STYLE
The SCMP should be plain and concise.
The document should be clear, consistent and modifiable.
The author of the SCMP should assume familiarity with the
purpose of the software, and not repeat information that
is explained in other documents.
RESPONSIBILITY
The developer is responsible for the production of the
SCMP.
MEDIUM
It is usually assumed that the SCMP is a paper document.
There is no reason why the SCMP should not be
distributed electronically to participants with the
necessary equipment.
SCMP
content
Reference:
Guide to software configuration
management by ESA Board for
Software Standardisation and
Control (BSSC), ESA PSS-05-09
Issue 1 Revision 1, March 1995
Software Configuration
Management Overview by Walter
Tichy
http://svnbook.redbean.com/en/1.0/ch02s02.html
Thank
you