1 ©equinox limited 2005 what the hell is configuration management anyway? martin white equinox...

1

©equinox limited 2005

What the hell is Configuration Management anyway?

Martin WhiteEquinox Software Architects

August 2005

2


About me

Six years IT industry experience, mainly in the UK

Focussed on designing, implementing, documenting and maintaining Configuration Management practices

Experience of ClearCase, SourceSafe, MKS Integrity, AccuRev

AIT – 500 staff, one product, divergent customer versions

i2 – 250 staff, multiple products all integrated together

Equinox – 40 staff, bespoke development and consultancy

3


Introduction to CM

This is about Software Configuration Management

SCM really only recently emerging as a widely recognised software engineering discipline

What do you think CM is?

4


Introduction to CM (cont.)

British Computer Society CMSG

Technical and organisational activities comprising configuration identification, configuration control, configuration status accounting and configuration

audit. This includes the processes of identifying and defining the Configuration Items, recording and reporting the status of Configuration Items and

requests for change, and verifying the completeness and correctness of Configuration Items.

5



Brad Appleton, Steve Berczuk, Ralph Cabrera and Robert Orenstein; Streamed Lines: Branching Patterns for Parallel Software Development; 5th Annual Conference on Pattern Languages of Program Design; Allerton Park, IL, September 1998

Software Configuration Management is the process of identifying, organizing, controlling, and tracking both the decomposition and recomposition of: software structure, functionality, evolution, and teamwork. In short, SCM is the "glue" between software artifacts, features, changes, and team members; it forms the

ties that bind them all together from concept to delivery and beyond.

6



What do I think?

SCM is a discipline that uses tools and processes to help changes to be made to software as efficiently as possible,

whilst retaining levels of control, reproducibility and traceability appropriate to the organisation in question.

Why define it this way? Emphasises the ultimate point of SCM

Balances pace of change with accountability

Acknowledges need for processes to be realistic and practical

7



Some common misconceptions SCM equals version control

Version control only applies to code

We’re too small to need CM

8


Tools

90% of CM is process NOT tools

BUT tools are necessary to enable processes to work well

CM tools normally cover one or more of the following Version control

Defect/change tracking

Build management

Workflow

9


The minimal approach to CM

Maintain a version history of files with important versions identified

Maintain a descriptive list of changes made/planned

10


The most common approach to CM?

Use a version control tool to maintain a version history of files with important versions identified

Use branching to manage basic parallel development scenarios (maybe)

Maintain a descriptive list of changes made/planned in either a homegrown database or a defect tracking tool

Use unspoken conventions to manage workflow

11


How can we do better?

Apply patterns

Use a framework (ITIL, CMM)

Employ a consultant to help…?!

12


How can this be improved (cont.)?

Consider what you want to get out of it (don’t do something because some CM expert says you should)

Automate, automate, automate

Consider the following slides for particular areas to focus on…

13


Coverage

Version everything you can

If you can’t version it, document it and version the document

Business benefits Improves reproducibility

Encourages consistency

CodeDocumentation

TestwareBuild scriptsEnv settingsDesign docs

14


Workspaces

Make it really easy to begin working on a project

Allow the user to only see the files they need

Business benefits Reduces set up time for

new staff

Improves reproducibility DeveloperTesterDocumenterManager

15


Builds

Local builds

Integration builds

Fully automated

Build reports

Business benefits Reduces defect rate

Improves responsiveness

Improves reproducibility

Greater dev team efficiency

Check-in

DEVMACHINE

BUILDMACHINE

16


Branching strategies

Let your project requirements determine your branching strategy rather than being confined by it

Don’t let branches diverge too far

Business benefits Technical constraints don’t

dictate development activity Can isolate risky or large

changes Can easily control contents

of releases

REL1REL2

REL1.1

REL1.2

REL1.1.1

17


Integrate to change management tool

18


Integrate to change management tool (cont.)

Can easily find the files involved in making any given change

Conversely, for any given file version can see why it was created

Business benefits Improves traceability Increases developer

productivity

A

B

C

D

FIL

E

VERSION

1 32 4

CH

AN

GE

1C

HA

NG

E3

CH

AN

GE

4C

HA

NG

E2

19


Raise abstraction level

In other words, start managing code in terms of changes, not files

Why? Consider this…

20


Raise abstraction level (cont.)

REL1REL2

REL1.1

REL1.2

REL2.1

REL3

Change on main line

Change on rel 1 maintenance line


Release and potential branch point

21



REL1REL2

REL1.1

REL1.2

REL2.1

REL3

Change on main line



Release and potential branch point

22



In other words, start thinking in terms of changes not files

Much easier to manage complex scenarios

Can avoid whole-branch merges

Business benefits Much greater control over content of releases

Greater reporting capabilities

23


‘Componentise’

If you have multiple teams sharing code or components you need a defined file sharing procedure

Some tools provide good component management support

But to demonstrate that it is possible in any tool…

24


‘Componentise’

Source files

Component

Workspace setup process

Builds

Definition manifest

Use manifest

Workspace

Supplier repository Hub repository Client repository

25


‘Componentise’

If you have multiple teams sharing code try to implement a good process for managing this

Some tools provide good component management support

But to demonstrate that it is possible in any tool…

Business benefits Encourages code re-use

Improves reproducibility and traceability

Contributes to automatic workspace setup

26


General business benefits

Ensure reproducibility and traceability

Improve customer support

Develop software efficiently

Some clients require conformance to certain standards

27


Impact of NOT doing CM well

Bugs that were fixed ‘re-appear’

Inability to find out who made a particular change

Inability to reproduce past releases reliably

No-one is really sure what has changed in the product since the last release

Processes prevent people from doing work they need to do

28


Further resources

BOOK: “Software Configuration Management Patterns”

Stephen Berczuk & Brad Appleton

ONLINE FORUM: CM Crossroadswww.cmcrossroads.com

WHITE PAPER: Version Control is not CM http://www.spectrumscm.com/WhitePapers/vcnotcm.pdf

ARTICLE: But I Only Changed One Line of Code! http://www.stsc.hill.af.mil/crosstalk/2003/01/leishman.html

29


Questions?

30


Contact

Martin White, Equinox Software Architects

[email protected]

04 494 3728

www.equinox.co.nz

31


1 ©equinox limited 2005 what the hell is configuration management anyway? martin white equinox...

Documents

configuration control

configuration identification

configuration audit

status of configuration

software structure

software artifacts

parallel software development

version control tool