Upload
jessica-lawrence
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
1
©equinox limited 2005
What the hell is Configuration Management anyway?
Martin WhiteEquinox Software Architects
August 2005
2
©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
3
©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?
4
©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.
5
©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.
6
©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
7
©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
8
©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
9
©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
10
©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
11
©equinox limited 2005
How can we do better?
Apply patterns
Use a framework (ITIL, CMM)
Employ a consultant to help…?!
12
©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…
13
©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
CodeDocumentation
TestwareBuild scriptsEnv settingsDesign docs
14
©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 DeveloperTesterDocumenterManager
15
©equinox limited 2005
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
©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
REL1REL2
REL1.1
REL1.2
REL1.1.1
18
©equinox limited 2005
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
©equinox limited 2005
Raise abstraction level
In other words, start managing code in terms of changes, not files
Why? Consider this…
20
©equinox limited 2005
Raise abstraction level (cont.)
REL1REL2
REL1.1
REL1.2
REL2.1
REL3
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.)
REL1REL2
REL1.1
REL1.2
REL2.1
REL3
Change on main line
Change on rel 1 maintenance line
Change on rel 2 maintenance line
Release and potential branch point
22
©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
23
©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…
24
©equinox limited 2005
‘Componentise’
Source files
Component
Workspace setup process
Builds
Definition manifest
Use manifest
Workspace
Supplier repository Hub repository Client repository
25
©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
26
©equinox limited 2005
General business benefits
Ensure reproducibility and traceability
Improve customer support
Develop software efficiently
Some clients require conformance to certain standards
27
©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
28
©equinox limited 2005
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
30
©equinox limited 2005
Contact
Martin White, Equinox Software Architects
04 494 3728
www.equinox.co.nz