Chapter 25 – Configuration ManagementChapter 25 Configuratio

Chapter 25 – Configuration Management
Chapter 25 Configuration management
1
11/12/2014
Topics covered
Version management
System building
Change management
Release management
2
11/12/2014
Configuration management
Software systems are constantly changing during development
and use.
Configuration management (CM) is concerned with the policies,
processes and tools for managing changing software systems.
You need CM because it is easy to lose track of what changes
and component versions have been incorporated into each
system version.
CM is essential for team projects to control changes made by
different developers
3
11/12/2014
CM activities

Version management
Keeping track of the multiple versions of system components
and ensuring that changes made to components by different
developers do not interfere with each other.
System building
The process of assembling program components, data and
libraries, then compiling these to create an executable system.
Change management
Keeping track of requests for changes to the software from
customers and developers, working out the costs and impact of
changes, and deciding the changes should be implemented.
Release management
Preparing software for external release and keeping track of the
system versions that have been released for customer use.
4
11/12/2014
Configuration management activities
5
11/12/2014
Agile development and CM
Agile development, where components and systems are changed
several times per day, is impossible without using CM tools.
The definitive versions of components are held in a shared
project repository and developers copy these into their own
workspace.
They make changes to the code then use system building tools
to create a new system on their own computer for testing. Once
they are happy with the changes made, they return the modified

components to the project repository.
11/12/2014
6
Development phases
A development phase where the development team is
responsible for managing the software configuration and new
functionality is being added to the software.
A system testing phase where a version of the system is released
internally for testing.
No new system functionality is added. Changes made are bug
fixes, performance improvements and security vulnerability
repairs.
A release phase where the software is released to customers for
use.
New versions of the released system are developed to repair
bugs and vulnerabilities and to include new features.
11/12/2014
7
Multi-version systems
For large systems, there is never just one ‘working’ version of a
system.
There are always several versions of the system at different
stages of development.
There may be several teams involved in the development of
different system versions.
11/12/2014
8

Multi-version system development
9
11/12/2014
CM terminology TermExplanationBaselineA baseline is a
collection of component versions that make up a system.
Baselines are controlled, which means that the versions of the
components making up the system cannot be changed. This
means that it is always possible to recreate a baseline from its
constituent components. BranchingThe creation of a new
codeline from a version in an existing codeline. The new
codeline and the existing codeline may then develop
independently. Codeline A codeline is a set of versions of a
software component and other configuration items on which that
component depends. Configuration (version) controlThe process
of ensuring that versions of systems and components are
recorded and maintained so that changes are managed and all
versions of components are identified and stored for the lifetime
of the system. Configuration item or software configuration
item (SCI)Anything associated with a software project (design,
code, test data, document, etc.) that has been placed under
configuration control. There are often different versions of a
configuration item. Configuration items have a unique
name.MainlineA sequence of baselines representing different
versions of a system.
10
11/12/2014
CM terminology TermExplanationMergingThe creation of a new
version of a software component by merging separate versions

in different codelines. These codelines may have been created
by a previous branch of one of the codelines involved.ReleaseA
version of a system that has been released to customers (or
other users in an organization) for use.RepositoryA shared
database of versions of software components and meta-
information about changes to these components.System
buildingThe creation of an executable system version by
compiling and linking the appropriate versions of the
components and libraries making up the system. VersionAn
instance of a configuration item that differs, in some way, from
other instances of that item. Versions always have a unique
identifier.WorkspaceA private work area where software can be
modified without affecting other developers who may be using
or modifying that software.
11
11/12/2014
Version management
12
11/12/2014
Version management
Version management (VM) is the process of keeping track of
different versions of software components or configuration
items and the systems in which these components are used.
It also involves ensuring that changes made by different
developers to these versions do not interfere with each other.
Therefore version management can be thought of as the process
of managing codelines and baselines.
13

11/12/2014
Codelines and baselines
A codeline is a sequence of versions of source code with later
versions in the sequence derived from earlier versions.
Codelines normally apply to components of systems so that
there are different versions of each component.
A baseline is a definition of a specific system.
The baseline therefore specifies the component versions that are
included in the system plus a specification of the libraries used,
configuration files, etc.
14
11/12/2014
Baselines
Baselines may be specified using a configuration language,
which allows you to define what components are included in a
version of a particular system.
Baselines are important because you often have to recreate a
specific version of a complete system.
For example, a product line may be instantiated so that there are
individual system versions for different customers. You may
have to recreate the version delivered to a specific customer if,
for example, that customer reports bugs in their system that
have to be repaired.
15
11/12/2014
Codelines and baselines
16

11/12/2014
Version control systems
Version control (VC) systems identify, store and control access
to the different versions of components. There are two types of
modern version control system
Centralized systems, where there is a single master repository
that maintains all versions of the software components that are
being developed. Subversion is a widely used example of a
centralized VC system.
Distributed systems, where multiple versions of the component
repository exist at the same time. Git is a widely-used example
of a distributed VC system.
11/12/2014
17
Key features of version control systems
Version and release identification
Change history recording
Support for independent development
Project support
Storage management
11/12/2014
18
Public repository and private workspaces
To support independent development without interference,
version control systems use the concept of a project repository
and a private workspace.
The project repository maintains the ‘master’ version of all

components. It is used to create baselines for system building.
When modifying components, developers copy (check-out) these
from the repository into their workspace and work on these
copies.
When they have finished their changes, the changed components
are returned (checked-in) to the repository.
11/12/2014
19
Centralized version control
Developers check out components or directories of components
from the project repository into their private workspace and
work on these copies in their private workspace.
When their changes are complete, they check-in the components
back to the repository.
If several people are working on a component at the same time,
each check it out from the repository. If a component has been
checked out, the VC system warns other users wanting to check
out that component that it has been checked out by someone
else.
11/12/2014
20
Repository Check-in/Check-out
11/12/2014
21
Distributed version control
A ‘master’ repository is created on a server that maintains the

code produced by the development team.
Instead of checking out the files that they need, a developer
creates a clone of the project repository that is downloaded and
installed on their computer.
Developers work on the files required and maintain the new
versions on their private repository on their own computer.
When changes are done, they ‘commit’ these changes and
update their private server repository. They may then ‘push’
these changes to the project repository.
11/12/2014
22
Repository cloning
11/12/2014
23
Benefits of distributed version control
It provides a backup mechanism for the repository.
If the repository is corrupted, work can continue and the project
repository can be restored from local copies.
It allows for off-line working so that developers can commit
changes if they do not have a network connection.
Project support is the default way of working.
Developers can compile and test the entire system on their local
machines and test the changes that they have made.
11/12/2014
24

Open source development
Distributed version control is essential for open source
development.
Several people may be working simultaneously on the same
system without any central coordination.
As well as a private repository on their own computer,
developers also maintain a public server repository to which
they push new versions of components that they have changed.
It is then up to the open-source system ‘manager’ to decide
when to pull these changes into the definitive system.
11/12/2014
25
Open-source development
11/12/2014
26
Branching and merging
Rather than a linear sequence of versions that reflect changes to
the component over time, there may be several independent
sequences.
This is normal in system development, where different
developers work independentl y on different versions of the
source code and so change it in different ways.
At some stage, it may be necessary to merge codeline branches
to create a new version of a component that includes all changes
that have been made.
If the changes made involve different parts of the code, the
component versions may be merged automatically by combining
the deltas that apply to the code.

27
11/12/2014
Branching and merging
11/12/2014
28
Storage management
When version control systems were first developed, storage
management was one of their most important functions.
Disk space was expensive and it was important to minimize the
disk space used by the different copies of components.
Instead of keeping a complete copy of each version, the system
stores a list of differences (deltas) between one version and
another.
By applying these to a master version (usually the most recent
version), a target version can be recreated.
11/12/2014
29
Storage management using deltas
30
11/12/2014
Storage management in Git
As disk storage is now relatively cheap, Git uses an alternative,
faster approach.

Git does not use deltas but applies a standard compression
algorithm to stored files and their associated meta-information.
It does not store duplicate copies of files. Retrieving a file
simply involves decompressing it, with no need to apply a chain
of operations.
Git also uses the notion of packfiles where several smaller files
are combined into an indexed single file.
11/12/2014
31
System building
32
11/12/2014
System building
System building is the process of creating a complete,
executable system by compiling and linking the system
components, external libraries, configuration files, etc.
System building tools and version management tools must
communicate as the build process involves checking out
component versions from the repository managed by the version
management system.
The configuration description used to identify a baseline is also
used by the system building tool.
33
11/12/2014
Build platforms
The development system, which includes development tools
such as compilers, source code editors, etc.

Developers check out code from the version management system
into a private workspace before making changes to the system.
The build server, which is used to build definitive, executable
versions of the system.
Developers check-in code to the version management system
before it is built. The system build may rely on external
libraries that are not included in the version management
system.
The target environment, which is the platform on which the
system executes.
34
11/12/2014
System building
35
11/12/2014
Build system functionality
Build script generation
Version management system integration
Minimal re-compilation
Executable system creation
Test automation
Reporting
Documentation generation
36
11/12/2014

System platforms
The development system, which includes development tools
such as compilers, source code editors, etc.
The build server, which is used to build definitive, executable
versions of the system. This server maintains the definitive
versions of a system.
The target environment, which is the platform on which the
system executes.
For real-time and embedded systems, the target environment is
often smaller and simpler than the development environment
(e.g. a cell phone)
11/12/2014
37
Development, build, and target platforms
38
11/12/2014
Agile building
Check out the mainline system from the version management
system into the developer’s private workspace.
Build the system and run automated tests to ensure that the built
system passes all tests. If not, the build is broken and you
should inform whoever checked in the last baseline system.
They are responsible for repairing the problem.
Make the changes to the system components.
Build the system in the private workspace and rerun system
tests. If the tests fail, continue editing.
39

11/12/2014
Agile building
Once the system has passed its tests, check it into the build
system but do not commit it as a new system baseline.
Build the system on the build server and run the tests. You need
to do this in case others have modified components since you
checked out the system. If this is the case, check out the
components that have failed and edit these so that tests pass on
your private workspace.
If the system passes its tests on the build system, then commit
the changes you have made as a new baseline in the system
mainline.
40
11/12/2014
Continuous integration
41
11/12/2014
Pros and cons of continuous integration
Pros
The advantage of continuous integration is that it allows
problems caused by the interactions between different
developers to be discovered and repaired as soon as possible.
The most recent system in the mainline is the definitive working
system.
Cons
If the system is very large, it may take a long time to build and

test, especially if integration with other application systems is
involved.
If the development platform is different from the target
platform, it may not be possible to run system tests in the
developer’s private workspace.
11/12/2014
42
Daily building
The development organization sets a delivery time (say 2 p.m.)
for system components.
If developers have new versions of the components that they are
writing, they must deliver them by that time.
A new version of the system is built from these components by
compiling and linking them to form a complete system.
This system is then delivered to the testing team, which carries
out a set of predefined system tests
Faults that are discovered during system testing are documented
and returned to the system developers. They repair these faults
in a subsequent version of the component.
43
11/12/2014
Minimizing recompilation
Tools to support system building are usually designed to
minimize the amount of compilation that is required.
They do this by checking if a compiled version of a component
is available. If so, there is no need to recompile that component.
A unique signature identifies each source and object code
version and is changed when the source code is edited.
By comparing the signatures on the source and object code files,
it is possible to decide if the source code was used to generate

the object code component.
44
11/12/2014
File identification
Modification timestamps
The signature on the source code file is the time and date when
that file was modified. If the source code file of a component
has been modified after the related object code file, then the
system assumes that recompilation to create a new object code
file is necessary.
Source code checksums
The signature on the source code file is a checksum calculated
from data in the file. A checksum function calculates a unique
number using the source text as input. If you change the source
code (even by 1 character), this will generate a different
checksum. You can therefore be confident that source code files
with different checksums are actually different.
45
11/12/2014
Timestamps vs checksums
Timestamps
Because source and object files are linked by name rather than
an explicit source file signature, it is not usually possible to
build different versions of a source code component into the
same directory at the same time, as these would generate object
files with the same name.
Checksums
When you recompile a component, it does not overwrite the

object code, as would normally be the case when the timestamp
is used. Rather, it generates a new object code file and tags it
with the source code signature. Parallel compilation is possible
and different versions of a component may be compiled at the
same time.
46
11/12/2014
Linking source and object code
11/12/2014
47
Change management
48
11/12/2014
Change management
Organizational needs and requirements change during the
lifetime of a system, bugs have to be repaired and systems have
to adapt to changes in their environment.
Change management is intended to ensure that system evolution
is a managed process and that priority is given to the most
urgent and cost-effective changes.
The change management process is concerned with analyzing
the costs and benefits of proposed changes, approving those
changes that are worthwhile and tracking which components in
the system have been changed.

49
11/12/2014
The change management process
50
11/12/2014
A partially completed change request form (a)
51
Change Request Form
Project: SICSA/AppProcessing Number: 23/02
Change requester: I. Sommerville Date: 20/07/12
Requested change: The status of applicants (rejected, accepted,
etc.) should be shown visually in the displayed list of
applicants.
Change analyzer: R. Looek Analysis date: 25/07/12
Components affected: ApplicantListDisplay, StatusUpdater
Associated components: StudentDatabase
11/12/2014

A partially completed change request form (b)
52
Change Request Form
Change assessment: Relatively simple to implement by
changing the display color according to status. A table must be
added to relate status to colors. No changes to associated
components are required.
Change priority: Medium
Change implementation:
Estimated effort: 2 hours
Date to SGA app. team: 28/07/12 CCB decision date:
30/07/12
Decision: Accept change. Change to be implemented in Release
1.2
Change implementor: Date of change:
Date submitted to QA: QA decision:
Date submitted to CM:
Comments:
11/12/2014
Factors in change analysis
The consequences of not making the change
The benefits of the change
The number of users affected by the change
The costs of making the change
The product release cycle

53
11/12/2014
Derivation history
54
// SICSA project (XEP 6087)
//
// APP-SYSTEM/AUTH/RBAC/USER_ROLE
//
// Object: currentRole
// Author: R. Looek
// Creation date: 13/11/2012
//
// © St Andrews University 2012
//
// Modification history
// Version Modifier Date Change Reason
// 1.0 J. Jones 11/11/2009 Add header Submitted to
CM
// 1.1 R. Looek 13/11/2012 New field Change req.
R07/02
11/12/2014
Change management and agile methods
In some agile methods, customers are directly involved in
change management.
The propose a change to the requirements and work with the
team to assess its impact and decide whether the change should
take priority over the features planned for the next increment of
the system.
Changes to improve the software improvement are decided by

the programmers working on the system.
Refactoring, where the software is continually improved, is not
seen as an overhead but as a necessary part of the development
process.
55
11/12/2014
Release management
56
11/12/2014
Release management
A system release is a version of a software system that is
distributed to customers.
For mass market software, it is usually possible to identify two
types of release: major releases which deliver significant new
functionality, and minor releases, which repair bugs and fix
customer problems that have been reported.
For custom software or software product lines, releases of the
system may have to be produced for each customer and
individual customers may be running several different releases
of the system at the same time.
57
11/12/2014
Release components
As well as the the executable code of the system, a release may
also include:
configuration files defining how the release should be
configured for particular installations;

data files, such as files of error messages, that are needed for
successful system operation;
an installation program that is used to help install the system on
target hardware;
electronic and paper documentation describing the system;
packaging and associated publicity that have been designed for
that release.
58
11/12/2014
Factors influencing system release planning
FactorDescriptionCompetitionFor mass-market software, a new
system release may be necessary because a competing product
has introduced new features and market share may be lost if
these are not provided to existing customers.Marketing
requirementsThe marketing department of an organization may
have made a commitment for releases to be available at a
particular date.Platform changesYou may have to create a new
release of a software application when a new version of the
operating system platform is released.Technical quality of the
systemIf serious system faults are reported which affect the way
in which many customers use the system, it may be necessary to
issue a fault repair release. Minor system faults may be repaired
by issuing patches (usually distributed over the Internet) that
can be applied to the current release of the system.
59
11/12/2014
Release creation
The executable code of the programs and all associated data
files must be identified in the version control system.

Configuration descriptions may have to be written for different
hardware and operating systems.
Update instructions may have to be written for customers who
need to configure their own systems.
Scripts for the installation program may have to be written.
Web pages have to be created describing the release, with links
to system documentation.
When all information is available, an executable master image
of the software must be prepared and handed over for
distribution to customers or sales outlets.
11/12/2014
60
Release tracking
In the event of a problem, it may be necessary to reproduce
exactly the software that has been delivered to a particular
customer.
When a system release is produced, it must be documented to
ensure that it can be re-created exactly in the future.
This is particularly important for customized, long-lifetime
embedded systems, such as those that control complex
machines.
Customers may use a single release of these systems for many
years and may require specific changes to a particular software
system long after its original release date.
61
11/12/2014
Release reproduction
To document a release, you have to record the specific versions

of the source code components that were used to create the
executable code.
You must keep copies of the source code files, corresponding
executables and all data and configuration files.
You should also record the versions of the operating system,
libraries, compilers and other tools used to build the software.
62
11/12/2014
Release planning
As well as the technical work involved in creating a release
distribution, advertising and publicity material have to be
prepared and marketing strategies put in place to convince
customers to buy the new release of the system.
Release timing
If releases are too frequent or require hardware upgrades,
customers may not move to the new release, especially if they
have to pay for it.
If system releases are too infrequent, market share may be lost
as customers move to alternative systems.
63
11/12/2014
Software as a service
Delivering software as a service (SaaS) reduces the problems of
release management.
It simplifies both release management and system installation
for customers.
The software developer is responsible for replacing the existing
release of a system with a new release and this is made
available to all customers at the same time.

11/12/2014
64
Key points
Configuration management is the management of an evolving
software system. When maintaining a system, a CM team is put
in place to ensure that changes are incorporated into the system
in a controlled way and that records are maintained with details
of the changes that have been implemented.
The main configuration management processes are concerned
with version management, system building, change
management, and release management.
Version management involves keeping track of the different
versions of software components as changes are made to them.
65
11/12/2014
Key points
System building is the process of assembling system
components into an executable program to run on a target
computer system.
Software should be frequently rebuilt and tested immediately
after a new version has been built. This makes it easier to detect
bugs and problems that have been introduced since the last
build.
Change management involves assessing proposals for changes
from system customers and other stakeholders and deciding i f it
is cost-effective to implement these in a new version of a
system.
System releases include executable code, data files,

configuration files and documentation. Release management
involves making decisions on system release dates, preparing all
information for distribution and documenting each system
release.
66
11/12/2014
Component
versions
Release
management
Change
proposals
System
releases
Change
management
System
versions
Version
management
System
building

V1.0 V1.1 V1.2
Development
versions
V1.3 V1.4 V1.5
R1.0 R1.1
Releases
V2.1 V2.2 V2.3 V2.4
Pre-release
versions
Version 1
Version 2
Version 3
1
2
3
A
L1 L2
A1.1

Ex1 Ex2
A1.2 A1.3
Codeline (A)
B B1.1 B1.2 B1.3
Codeline (B)
C C1.1 C1.2 C1.3
Codeline (C)
Libraries and external components
Baseline - V1
A B1.2 C1.1
L1 L2 Ex1
Baseline - V2
A1.3 B1.2 C1.2
L1 L2 Ex2
Mainline
Version management system
Alice Bob

Workspace (Alice) Workspace (Bob)
check_incheck_out
A1.0
A1.1 B1.1
B1.0 C1.0
C1.1 X1.1
X1.0 Y1.0
Y1.1 Q1.0
P1.0
C1.2
Z1.0
R1.0
A1.0
A1.1 B1.1
B1.0 C1.0
C1.1
X1.0
X1.1 Y1.1

Y1.0 C1.0
C1.1
check_incheck_out
Master repository
Alice
Bob
A1.0 B1.0 C1.0 X1.0 Y1.0
Q1.0 P1.0Z1.0 R1.0
Alice’s repository
A1.0 B1.0 C1.0 X1.0 Y1.0
Q1.0 P1.0Z1.0 R1.0
Bob’s repository
A1.0 B1.0 C1.0 X1.0 Y1.0
Q1.0 P1.0Z1.0 R1.0
A1.1 B1.1 C1.1
C1.1 X1.1 Y1.1
clone

clone
Alice Bob
Definitive project
repository
Charlie
Alice’s public
repository
Alice’s private
repository
Bob’s’s public
repository
Bob’s private
repository
Charlie’s private
repository
1
22
33
4

V1.0 V1.1 V1.2
V2.2 V2.3
V2.0
V2.1.1 V2.1.2
V2.1 V2.4
Codeline 1
Codeline 2
<branch>
<branch>
<merge>
Codeline 2.1
Version
1.0
Version
1.1
Version
1.2
Version
1.3

D1 D2 D3
Creation date
Version sequence
Most recent
V1.3 source
code
Storage structure
Automated
build system
Source
code files
Data files
Libraries
Configuration
files
Executable
tests
Executable
target system
Test resultsCompilers
and tools

Development system
Development
tools
Private workspace
Build server
Version
management
system
co
Version management and build server
Target system
Executable system
Target platform
Check-out
(co)
Check-in
Check-out
mainline
Build and

test system
Build and
test system
Make
changes
Check-in to
build server
Build and
test system
Commit
changes to VM
Version
management
system
Version
management
system
Build server
Private
workspace
Tests fail
Tests OK
OK

Tests fail
Comp.java
(V1.0)
16583102142014
Timestamp
Comp.java
(V1.1)
Comp.class
17030502142014 16584302142014
Timestamp Timestamp
Compile
Comp.java
(V1.0)
Comp.class
24374509887231 24374509887231
Checksum Checksum
Comp.java
(V1.1)
Comp.class
37650812555734 37650812555734
Checksum Checksum

Compile
Compile
Time-based identification Checksum-based identification
Change
requests
Submit
CR
Check CR
Close CR
Implementation
analysis
Cost/impact
analysisAssess CRs
Select CRs Modify
software
Test software
Close CR
Close CRs
ValidInvalid

Pass
Fail
Customer
Customer support
Development
Product development/CCB
Register CR
Locate a Current Event (no more than 6-9 months old) that
represents a Public Administration problem/issue that can be
analyzed using the theories/content from Ashworth-
NOVEMBER/Re: Bona fide bureaucratic behavior and
DECEMBER/ Re: "Walking with kings"
The Chapter/Article readings will also provide you with a good
deal of information should you choose to use it.
Your analysis should be 6-8 paragraphs in length and include
the following elements (not necessarily separated into distinct
sections):
1. A summary of what you think are the most pertinent facts,
and what is really at issue?
2. An appraisal of the situation, e.g., what’s really going on in
the case, and what concepts or theories seem to apply in helping
diagnose what’s wrong, what needs to be fixed, and how you
would go about it. When citing theories or concepts, please also
reference the relevant theorists. You may cite them from either
text (e.g., “Ashworth p.__”) if located there, but if from another
source then provide the full reference in the bibliography.
3. Choose and defend a preferred strategy for addressing the
problems in the case, and explain how any undesirable effects
would be addressed.

4. A bibliography of sources that were applied in the case
analysis.

Chapter 25 – Configuration ManagementChapter 25 Configuratio

Recommended

More Related Content

Similar to Chapter 25 – Configuration ManagementChapter 25 Configuratio (20)

More from EstelaJeffery653 (20)

Recently uploaded (20)

Chapter 25 – Configuration ManagementChapter 25 Configuratio