Transcript What the hell is Configuration Management anyway? Martin

What the hell is Configuration Management
anyway?
Martin White
Equinox Software Architects
August 2005
1
©equinox limited 2005
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
2
©equinox limited 2005
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?
3
©equinox limited 2005
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.
4
©equinox limited 2005
Introduction to CM (cont.)

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.
5
©equinox limited 2005
Introduction to CM (cont.)
 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
6
©equinox limited 2005
Introduction to CM (cont.)
 Some common misconceptions
 SCM equals version control
 Version control only applies to code
 We’re too small to need CM
7
©equinox limited 2005
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
8
©equinox limited 2005
The minimal approach to CM
 Maintain a version history of files with important versions
identified
 Maintain a descriptive list of changes made/planned
9
©equinox limited 2005
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
10
©equinox limited 2005
How can we do better?
 Apply patterns
 Use a framework (ITIL, CMM)
 Employ a consultant to help…?!
11
©equinox limited 2005
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…
12
©equinox limited 2005
Coverage
 Version everything you can
 If you can’t version it,
document it and version the
document
 Business benefits
 Improves reproducibility
 Encourages consistency
Design docs
Env settings
Build scripts
Testware
Documentation
Code
13
©equinox limited 2005
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
Documenter
Developer
Manager
Tester
14
©equinox limited 2005
Builds
 Local builds
 Integration builds
 Fully automated
DEV
MACHINE
 Build reports
Check-in
 Business benefits
 Reduces defect rate
 Improves responsiveness
 Improves reproducibility
 Greater dev team efficiency
BUILD
MACHINE
15
©equinox limited 2005
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
16
©equinox limited 2005
Integrate to change management tool
17
©equinox limited 2005
Integrate to change management tool (cont.)
 Business benefits
1
2
3
4
A
B
FILE
CHANGE1
CHANGE2
CHANGE4
CHANGE3
 Can easily find the files
involved in making any
given change
 Conversely, for any given
file version can see why it
was created
VERSION
C
D
 Improves traceability
 Increases developer
productivity
18
©equinox limited 2005
Raise abstraction level
 In other words, start managing code in terms of changes,
not files
 Why? Consider this…
19
©equinox limited 2005
Raise abstraction level (cont.)
Change on main line
Change on rel 1 maintenance line
Change on rel 2 maintenance line
Release and potential branch point
20
©equinox limited 2005
Raise abstraction level (cont.)
Change on main line
Change on rel 1 maintenance line
Change on rel 2 maintenance line
Release and potential branch point
21
©equinox limited 2005
Raise abstraction level (cont.)
 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
22
©equinox limited 2005
‘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…
23
©equinox limited 2005
‘Componentise’
Supplier repository
Hub repository
Component
Client repository
Use manifest
Definition manifest
Builds
Source files
Workspace
setup process
Workspace
24
©equinox limited 2005
‘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
25
©equinox limited 2005
General business benefits
 Ensure reproducibility and traceability
 Improve customer support
 Develop software efficiently
 Some clients require conformance to certain standards
26
©equinox limited 2005
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
27
©equinox limited 2005
Further resources
 BOOK: “Software Configuration Management Patterns”
Stephen Berczuk & Brad Appleton
 ONLINE FORUM: CM Crossroads
www.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
28
©equinox limited 2005
Questions?
29
©equinox limited 2005
Contact
 Martin White, Equinox Software Architects
 [email protected]
 04 494 3728
 www.equinox.co.nz
30
©equinox limited 2005
31
©equinox limited 2005