Configuration & change

management

Karel Kravik

Configuration management is ...

� ... the process of identifying and defining the

Configuration Items in a system, recording

and reporting the status of Configuration Items

and Requests For Change, and verifying the

completeness and correctness of Configuration

Items.Items.

� Abstract term, most people get it wrong

� When software is in use, “configuration” refers to

set of parameters and their values

� When software is in development, “configuration”

refers to some known state of source code

What is Configuration Item?

� Configuration Item can be:

� Document

� Specification

� Requirement

� Database table

Website content� Website content

� But in everyday life, configuration items are

source code files and instead of CM we talk

about “version control”

Diff & merge

� Diff – refers to differences between two files

� Merge – the operation of taking differences

between two files and applying to the third

� Configuration management is vastly easier task

if we can define diff & merge algorithms for

configuration itemsconfiguration items

� Consider text files vs Word documents

� Why are wikis popular?

Diff & merge

A1+A2

� Low level tools

� diff

� diff3

A

A1 A2

Basic versioning

VCS tools

� CVS (concurrent versions system) – old, but

still widely used

� Subversion – “compelling replacement for CVS”,

newer, popular, but generally not what people

would like it to be

There are plenty of commercial tools: � There are plenty of commercial tools:

� Perforce

� IBM ClearCase

� BitKeeper (distributed VCS)

� MS Team Foundation

� We take CVS as an example

Version control (centralized)

Working directory 1

Working directory 1

Repository

Main concepts

� Repository

� Working directory

� Revision/revision history

� Change/changeset

� VCS client/server� VCS client/server

Repository - files

A B C D

A C

Repository files & history

A CA B C

A B C DA B C D

A B C D

Basic version control operations

� Checkout – creates new working directory

� Commit – pushes local changes to central repo

� Update – pulls changes committed by others

from repo

� Merge – parallel changes are incorporated� Merge – parallel changes are incorporated

� Conflict - same file is changed within certain

context

� Add – add file to source tree

Usual work process

� Checkout

� Edit code

� Compile, deploy, test

� Commit

� Resolve conflicts if needed

� Update

� Pull other people’s changes to my working directory

� Resolve conflicts if needed

� Edit code

� Commit

� ....

Conflicting changes

diff3 can integrate changes from two modified versions into a common preceding version. This enables users to merge the sets of changes represented by the two newer files. This can be enabled using a command like this: diff3 mine older yours.

diff3 can integrate changes from two modified versions into a common preceding version. This enables users to merge the sets of changes represented by the two newer files. This can be finished using a command like this: diff3 mine older yours.

diff3 can incorporate changes from two modified versions into a common preceding version. This enables users to merge the sets of changes represented by the two newer files. This can be accomplished using a command like this: diff3 mine older yours.

Conflict markers

diff3 can incorporate changes from two modified

versions into a common preceding version. This

enables users to merge the sets of changes

represented by the two newer files.

>>>>>>>>>>>>>>>>

This can be accomplished using a command like This can be accomplished using a command like

this: diff3 mine older yours.

================

This can be finished using a command like this:

diff3 mine older yours.

<<<<<<<<<<<<<<<<

Tagging & branching

Advanced concepts - tag

� Tag marks certain revision(s) of file(s)

A CA CA B C

A B C DA B C D

A B C D

Uses for tag

� Denoting some known state:

� ReleaseX – so you can reproduce released version

� BeforeRefactorX – if you need to undo, you know

the “good” state

� BranchpointX – where some branch started

� You can tag:� You can tag:

� Whole repository

� Any subdirectory

� One file

� To keep it manageable, tag whole repository

AA B

Advanced concepts - branch

A CAA B

A CA B C

A B C DA B C D

A B C D

AA B C D

A’ B’ C’ D’

Uses for branch

� Support branch – you need to fix bugs in

released version and develop new functionality

� Experimental branch - test some earth-shaking

change

� Staging branch – code propagates from less

stable branch to more stable branchstable branch to more stable branch

Limitations for branching

� There is one substantial limitation – the

complexity of merge operation

� If there are conflicts, merge must be done manually

� Resolving conflicts is error-prone

� You have to track what you merge, where you

merge, when you mergemerge, when you merge

� Conclusions:

� You must have a good reason to create a branch

� Don’t avoid them at any cost

Branching models & code propagation

� Different models:

� No branching, code freeze

� Branch-off on release

� Continuous forward integration

� For more see:

� "Streamed Lines: Branching Patterns for Parallel

Software Development" by Brad Appleton, Stephen

Berczuk, Ralph Cabrera, and Robert Orenstein

Code freeze model

Release

Stabilizing SupportDevelopment Development

Branch-off on release model

Stabilizing Support

Resync

Release

Development Development Development

Stabilizing

Continuous integration model

Development

Stabilizing

Support

Continuous resync

Release

Development

Stabilizing

Stabilizing

Development

Development

More on tools: CVS vs SVN

� SVN advantages:� Atomic commits (cross-repository revision nr)

� Versioned directories, renames & meta-data

� Cheap tagging & branching - O(1) complexity

� It’s in active development

� SVN disadvantages :� SVN disadvantages :� Somewhat slower update & commit

� Everything is a directory - you’re exposed to repo structure

� You can commit against a tag, because, surprise, it’s a directory

� I still recommend it☺

Linus Torvalds on CVS & SVN

� For the first 10 years of kernel maintenance, we literally used

tarballs and patches, which is a much superior source control

management system than CVS is, but I did end up using CVS

for 7 years at a commercial company and I hate it with a

passion.

� Because my hatred of CVS has meant that I see Subversion as

being the most pointless project ever started. The slogan of being the most pointless project ever started. The slogan of

Subversion for a while was ‘CVS done right’, or something like

that, and if you start with that kind of slogan, there's nowhere

you can go. There is no way to do CVS right.

� http://www.youtube.com/watch?v=4XpnKHJAok8

Distributed version control

� Every working directory is self-contained

repository, meaning:

� You don’t need network for work

� You can create your own structure

� Changes can propagate between any two

repositoriesrepositories

� You don’t need branches, you just clone whole repo

� It’s powerful and makes possible things

centralized VCS’s never will, but...

� ... you have to know what you’re doing☺

� Successfully used in big open source projects

1

1.1 1.2

Code propagation in distributed VCS

1.1.1 1.1.2

1.1.2.1

1.2.1

Distributed VCS tools

� Freeware:

� Git – used for Linux kernel development

� Mercurial

� Darcs

� Monotone

Commercial:� Commercial:

� Bitkeeper

Modules

Modularizing code base

� When code base grows:

� There is huge amount of code and different

people/teams are responsible for different parts

� VCS operations slow down

� Solution:

Code base is splitted to modules that interact � Code base is splitted to modules that interact

through defined interface

� One team is responsible for one module, the other

for the second module

Problem & solutions

� You need to start keep track which versions of

the modules that are known to work together

� Possible tools to help:

� Maven, Ivy

� But they are not complete solutions:

� No history

� No staging

� Solutions:

� Lots of manual work

� Share source, not binaries

Variability

Variability levels

� Code level (branches)

� Build time

� Deployment (configuration)

� Runtime

Code level variations

� When to use:

� When you need to support older versions

� Different hardware, operating systems, ...

� Different flavors (basic, advanced, enterprise)

� You should keep in mind:

� Transparency is low

� The branches should still have something in

common (ie you merge some bugfixes to more than

one branch), otherwise they’re already separate

projects

Build time variations

� When to use:

� Different languages (if you don’t have to support

runtime language change)

� Different application servers, platforms, ...

� Problems:

Transparency is better, “branches” are code level � Transparency is better, “branches” are code level

and usually side by side

� Clutter in code (maybe somebody remembers the

#IFDEF’s in C code)

Deployment & runtime variations

� Everything else?

� Data sources

� Languages

� External interfaces

� Why do things on lower level?

� Security reasons

� Psychological reasons

Change management

Change management definition

� Identifying & isolating changes

� Keeping track of changes

� Analyzing impact & approving changes

� Applying & propagating changes

� Change management has the same limitation � Change management has the same limitation

like ordinary version control – diff&merge

� Usually meant by CM:

� Changes in requirements, analysis, design

� Changes in configuration, hardware

� Must be dealt using organizational procedures

Code change management

� Changelogic example:

� Every change is done in separate branch

� Branches have identifiable base versions and merge

point

� Every change is reviewed and analyzed based on

changed files listchanged files list

� Every change implements identified task/bug

Environments

� Development environment

� Developers machines

� Shared development environments

� Test environment

� Must be separate from development

� Should be as close to possible to production

� Sync production to test regularly

� Test production updates

� Production environment

� 1 for custom applications

� N for packaged software products

Changes to environments

� What is environment? Something that you can’t

keep under version control:

� Database (structure&data)

� Content

� Environment specific configuration (connections,

libraries)libraries)

Database change management example

� A list of “features” is stored in every used

database instance

� When database is changed, incremental scripts

are added to code and registered as new

features

For example “Alter table USER add column � For example “Alter table USER add column

LASTLOGIN date”

� When new code is deployed, it compares the list

of features it contains and the ones contained

in database and updates if needed

Thank you!