Informatics 211: Configuration Management

1
Informatics 211Configuration Management
Coordination

• André van der Hoek
• Department of Informatics
• Donald Bren School of Information and Computer
  SciencesUniversity of California,
  Irvineandre_at_ics.uci.edu

2
A Typical Development Scenario
Petes workspace
Ellens workspace
C
B
A
E
C
D
CMrepository
3
Direct Conflicts
Petes workspace
Ellens workspace
B
A
E
D
C
C
CMrepository
Conflicting changes to the same artifact
4
Traditional CM Techniques
Coordination mechanism Directconflicts
Pessimistic (classical versioning) Locking before changes are made Avoided, at the expense of project delays
Optimistic (advanced versioning) Automated merging after changes have been made Resolved, except for overlapping changes
5
Traditional CM Techniques
Coordination mechanism Directconflicts
Pessimistic (classical versioning) Locking before changes are made Avoided, at the expense of project delays
Optimistic (advanced versioning) Automated merging after changes have been made Resolved, except for overlapping changes
Both with the side effect of keeping a history of
changes.
6
Configuration Management

• Configuration management (CM) is a discipline
  whose goal is to control changes to large
  software through the functions of component
  identification, change tracking, version
  selection and baselining, software manufacture,
  and managing simultaneous updates (team work).

Walter Tichy, SCM-1, 1988
7
CM Spectrum of Functionality

• Construction
• Building
• Snapshots
• Regeneration
• Optimization

• Components
• Versions
• Configurations
• Baselines
• Project contexts

• Controlling
• Access control
• Change requests
• Bug tracking
• Partitioning

• Structure
• System model
• Interfaces
• Consistency
• Selection

• Auditing
• History
• Traceability
• Logging

• Accounting
• Statistics
• Status
• Reports

• Process
• Lifecycle support
• Task mgmt.
• Communication
• Documentation

• Team
• Workspaces
• Merging
• Families

Susan Dart, SCM-3, 1991
8
Three Generations of CM Systems
Continuus
DaSC
ClearCase
Perforce
NUCM
Asgard
CCC/Harvest
TRUEchange
Proteus
ICE
Serena
Vesta
Endevor
Functionality
PVCS
NSE
EPOS
Source Integrity
DSEE
Adele
VOODOO
CVS
Odin
RCS
ShapeTools
Jasmine
Sablime
Research
Development
SCCS
Time
9
First Generation

• Focused on
• archiving individual elements
• strictly avoiding conflicts
• Characterized by
• simple, separate tools
• development orientation
• Canonical examples
• SCCS
• RCS
• Make

10
First Generation Version Graphs
1.0
1.1
Author André v/d HoekDate 01/12/2001Time
752amComment Trying new stuffLock
andre_at_ics.uci.edu
1.2
1.2.1.0
2.0
1.2.1.1
lock
2.1
11
First Generation

• Construction
• Building
• Snapshots
• Regeneration
• Optimization

• Components
• Versions
• Configurations
• Baselines
• Project contexts

• Controlling
• Access control
• Change requests
• Bug tracking
• Partitioning

• Structure
• System model
• Interfaces
• Consistency
• Selection

• Auditing
• History
• Traceability
• Logging

• Accounting
• Statistics
• Status
• Reports

• Process
• Lifecycle support
• Task mgmt.
• Communication
• Documentation

• Team
• Workspaces
• Merging
• Families

12
Second Generation

• Focused on
• archiving compound elements
• different version models
• Characterized by
• integrated versioning build tools
• development orientation
• Canonical examples
• CVS
• Subversion
• PVCS
• SourceSafe

13
Four Canonical Version Models

• State-based extensional
• version tree
• State-based intensional
• conditional compilation
• Change-based extensional
• change packages
• Change-based intensional
• change sets

14
Conditional Compilation

• ifdef UNIX
• include ltstdio.hgtendififdef
  GRAPHICS include ltgraphics.hgt ifdef
  SMARTGRAPHICS include ltsmart.gt endifendif

15
Change Packages
1.0
1.0
1.0
1.0
2.0
1.1
1.1
1.1
1.2
1.2.1.0
2.1
1.2
2.2
2.0
1.2.1.1
1.3
2.0.1.0
1.2
2.3
2.1
2.0
16
Change Sets
AVAILABLECHANGESETS
SYSTEMSELECTION
Bug fix 17
Feature addition104
Bug fix 21
Feature addition103
Bug fix 8
Bug fix 6
Bug fix 16
Baseline
Bug fix 16
17
Second Generation

• Construction
• Building
• Snapshots
• Regeneration
• Optimization

• Components
• Versions
• Configurations
• Baselines
• Project contexts

• Controlling
• Access control
• Change requests
• Bug tracking
• Partitioning

• Structure
• System model
• Interfaces
• Consistency
• Selection

• Auditing
• History
• Traceability
• Logging

• Accounting
• Statistics
• Status
• Reports

• Process
• Lifecycle support
• Task mgmt.
• Communication
• Documentation

• Team
• Workspaces
• Merging
• Families

18
Third Generation

• Focused on
• providing process support
• being all-encompassing
• Characterized by
• large, complex tools
• management orientation
• Canonical examples
• ClearCase together with ClearGuide
• Cm/Synergy

19
Third Generation

• Construction
• Building
• Snapshots
• Regeneration
• Optimization

• Components
• Versions
• Configurations
• Baselines
• Project contexts

• Controlling
• Access control
• Change requests
• Bug tracking
• Partitioning

• Structure
• System model
• Interfaces
• Consistency
• Selection

• Auditing
• History
• Traceability
• Logging

• Accounting
• Statistics
• Status
• Reports

• Process
• Lifecycle support
• Task mgmt.
• Communication
• Documentation

• Team
• Workspaces
• Merging
• Families

20
A Fourth Generation
?
21
No

• CM core functionality is stable with
  well-understood choices
• CM tool enhancement seems to be limited to
  feature creep, not fundamental new approaches
• SCM workshop series has ended
• Only a few pure CM papers are being published to
  date

22
Maybe

• CM functionality is now appearing in domains
  other than source code management
• web content management
• product data management
• web services and components
• software deployment
• product line architectures
• Mining software repositories
• no better repository than the CM repository
• Still some problems left
• indirect conflicts
• concern management
• Coordination

23
Software Deployment the Problem
24
Software Deployment the Problem
25
Software Deployment the Problem
26
Software Deployment the Problem
27
Software Deployment Life Cycle
Release
Producer
Retire
Consumer
Install
Reconfig
Adapt
Remove
Update
28
SourceForge
29
RPM
30
Product Line Architectures The Problem

• A software product line (SPL) is a strategic
  software-based asset that explicitly recognizes,
  optimizes, and manages variability towards
  current and future feature changes. van der
  Hoek
• But how to manage this asset?

31
Classic Versioning for Product Lines
32
Advanced Versioning for Product Lines
33
Advanced Versioning for Product Lines
34
Advanced Versioning for Product Lines
35
Advanced Versioning for Product Lines
36
Advanced Versioning for Product Lines
37
Advanced Versioning for Product Lines
38
Advanced Versioning for Product Lines
39
Advanced Versioning for Product Lines
40
Mining Software Repositories

• Configuration management repositories are
  traditionally a depot
• occasional roll-back
• occasional search for relevant information
• But what if we used the information captured by
  configuration management repositories to our
  advantage
• understanding software developers
• helping software developers

41
Activity Viewer
42
Highlighting
43
Distance is Age
44
Rotation Allows Different Viewpoints
45
Larger Projects Time Ordered
46
Larger Projects Most Activity Ordered
47
Larger Projects Developer View
48
Same Project Ordered by Time
49
Committed versus Not Committed
50
(Animated)
51
Applied to GAIM, jEdit, and Argo/UML

• Simulated the archives
• demonstrated scalability
• demonstrated usefulness
• filters are a must
• Interesting patterns
• core developers
• core developer overtaken by others
• lots of people on a project, but most are working
  on pictures, not code
• highly active artifacts
• Much more analysis to be done
• Planned viewing on HIPerWall

52
Indirect Conflicts
Coordination mechanism Directconflicts Indirect conflicts
Pessimistic (classical versioning) Locking before changes are made Avoided, at the expense of project delays Not addressed
Optimistic (advanced versioning) Automated merging after changes have been made Resolved, except for overlapping changes Not addressed
53
Direct Conflicts
Petes workspace
Ellens workspace
B
A
E
D
C
C
CMrepository
Conflicting changes to the same artifact
54
Indirect Conflicts
Petes workspace
Ellens workspace
C
B
A
E
C
D
CMrepository
Conflicting changes to different artifacts
55
Palantír
56
Lighthouse
57
World View
58
World View
59
World Wall?
60
Coordination
Passive awareness of
Information
Provision
development activities
Collocation benefits to
Advanced conflict
distributed development
and developers, manage
detection
information overload
Information
Organizational memor
y
,
Instant messaging,
Discovery
Fine grained versioning,
knowledge acquisition and
monitoring changes
conflict resolution
dissemination, social navigation
to artifacts
Rigid
Process
Parallel development,
Communication archival
Prescribed and defined
roles and access rights
along with artifacts
coordination support
Basic
Functionality
Access to common set of artifacts,
Asynchronous communication
T
ask allocation and assignment
isolated workspaces and version control
Communication
Artifact Management
Task Management
61
Layers Coordination Paradigms
Passive awareness of
Information
Provision
development activities
Collocation benefits to
Advanced conflict
distributed development
and developers, manage
detection
information overload
Information
Organizational memor
y
,
Instant messaging,
Discovery
Fine grained versioning,
knowledge acquisition and
monitoring changes
conflict resolution
dissemination, social navigation
to artifacts
Rigid
Process
Parallel development,
Communication archival
Prescribed and defined
roles and access rights
along with artifacts
coordination support
Basic
Functionality
Access to common set of artifacts,
Asynchronous communication
T
ask allocation and assignment
isolated workspaces and version control
Communication
Artifact Management
Task Management
62
Strands Technical Dimensions of Coordination
Passive awareness of
Information
Provision
development activities
Collocation benefits to
Advanced conflict
distributed development
and developers, manage
detection
information overload
Information
Organizational memor
y
,
Instant messaging,
Discovery
Fine grained versioning,
knowledge acquisition and
monitoring changes
conflict resolution
dissemination, social navigation
to artifacts
Rigid
Process
Parallel development,
Communication archival
Prescribed and defined
roles and access rights
along with artifacts
coordination support
Basic
Functionality
Access to common set of artifacts,
Asynchronous communication
T
ask allocation and assignment
isolated workspaces and version control
Communication
Artifact Management
Task Management
63
A New Paradigm Provoked Behavior
Provoked
Continuous coordination,
Behavior
collaborative architecture,
seamless development environments,
Passive awareness of
Information
Provision
development activities
Collocation benefits to
Advanced conflict
distributed development
and developers, manage
detection
information overload
Information
Organizational memor
y
,
Instant messaging,
Discovery
Fine grained versioning,
knowledge acquisition and
monitoring changes
conflict resolution
dissemination, social navigation
to artifacts
Rigid
Process
Parallel development,
Communication archival
Prescribed and defined
roles and access rights
along with artifacts
coordination support
Basic
Functionality
Access to common set of artifacts,
Asynchronous communication
T
ask allocation and assignment
isolated workspaces and version control
Communication
Artifact Management
Task Management
64
Configuration Management
Provoked
Continuous coordination,
Behavior
collaborative architecture,
seamless development environments,
Passive awareness of
Information
Provision
development activities
Collocation benefits to
Advanced conflict
distributed development
and developers, manage
detection
information overload
Information
Organizational memor
y
,
Instant messaging,
Discovery
Fine grained versioning,
knowledge acquisition and
monitoring changes
conflict resolution
dissemination, social navigation
to artifacts
Rigid
Process
Parallel development,
Communication archival
Prescribed and defined
roles and access rights
along with artifacts
coordination support
Basic
Functionality
Access to common set of artifacts,
Asynchronous communication
T
ask allocation and assignment
isolated workspaces and version control
Communication
Artifact Management
Task Management
65
Conclusion

• CM is a long-standing field which has seen
  numerous contributions
• some highly influential (sometimes delayed by as
  much as 20 years)
• others indirectly shaping
• others utterly useless
• While the core ideas of CM have been well
  developer, there is still much room for
  improvement
• particularly if one considers CM to be a
  coordination problem
• particularly if one brings together CM with other
  disciplines
• Software engineering can be cool ?