49
©2001, University of California, Irvine Institute for Software Research Software Configuration Management André van der Hoek Institute for Software Research University of California, Irvine [email protected]

Configuration Management

Embed Size (px)

Citation preview

Page 1: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Configuration Management

André van der HoekInstitute for Software ResearchUniversity of California, Irvine

[email protected]

Page 2: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

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

Page 3: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Construction•Building•Snapshots•Regeneration•Optimization

Construction•Building•Snapshots•Regeneration•Optimization

Auditing•History•Traceability•Logging

Auditing•History•Traceability•Logging

Components•Versions•Configurations•Baselines•Project contexts

Components•Versions•Configurations•Baselines•Project contexts

CM Spectrum of Functionality

Susan Dart, SCM-3, 1991

Accounting•Statistics•Status•Reports

Accounting•Statistics•Status•Reports

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

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

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

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

Team•Workspaces•Merging•Families

Team•Workspaces•Merging•Families

Structure•System model•Interfaces•Consistency•Selection

Structure•System model•Interfaces•Consistency•Selection

Page 4: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

CCC/Harvest

Three Generations of CM Systems

Fun

ctio

nalit

y Proteus

Jasmine

EPOS

VOODOO

ShapeTools

Asgard NUCMDaSC

Vesta

Adele

ICE

Odin

Time

Source Integrity

Continuus

CVS

PVCSDSEE

SCCS

NSE

ClearCase

TRUEchangeSerena

Endevor

Perforce

RCSSablime Research

Development

Page 5: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

First Generation

Focused on: Archiving individual elements Strictly avoiding conflicts Optimizing builds

Characterized by: Simple, separate tools Development orientation

Canonical examples: RCS Make

Page 6: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Archiving Individual Elements

1.0

1.1

2.0

1.2

2.1

REVISION

NEW BASELINE

Page 7: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Archiving Individual Elements

1.0

1.1

2.0

1.2

2.1

BRANCH LEADS TO VARIANTS1.2.1.0

1.2.1.1

Page 8: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Archiving Individual Elements

1.0

1.1

2.0

1.2

2.1 MERGE

1.2.1.0

1.2.1.1

Page 9: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Archiving Individual Elements

1.0

1.1

2.0

1.2

2.1

1.2.1.0

1.2.1.1

Author = “André v/d Hoek”Date = 01/12/2001Time = 7:52amComment = “Trying new stuff”

ATTRIBUTES (TAGS)

Page 10: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Avoiding Conflicts

1.0

1.1

2.0

1.2

2.1

1.2.1.0

1.2.1.1

Author = “André v/d Hoek”Date = 01/12/2001Time = 7:52amComment = “Trying new stuff”Lock = “[email protected]

LOCK

Page 11: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Optimizing the Build Process

accesslist.o: accesslist.h accesslist.cgcc –o accesslist.o accesslist.c

andre.o: andre.cgcc –c andre.o andre.c

clientprotocol.o: clientprotocol.c clientprotocol.hgcc –c clientprotocol.o clientprotocol.c

main.exe: andre.o accesslist.o clientprotocol.ogcc andre.o accesslist.omv a.out main.exechmod a+x main.exe

Page 12: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Optimizing the Build Process

-r--r--r-- 1 andre faculty 2651 Aug 4 1999 Makefiledrwxr-xr-x 2 andre faculty 4096 Aug 4 1999 RCS/-r--r--r-- 1 andre faculty 5688 Aug 4 1999 accesslist.c-r--r--r-- 1 andre faculty 1608 Aug 5 1999 accesslist.h-rw-r--r-- 1 andre faculty 22840 Aug 4 1999 accesslist.o-rw-r--r-- 1 andre faculty 10061 Aug 4 1999 andre.c-rw-r--r-- 1 andre faculty 21944 Aug 4 1999 andre.o-rw-r--r-- 1 andre faculty 14224 Aug 5 1999 clientprotocol.c-rw-r--r-- 1 andre faculty 3491 Aug 6 1999 clientprotocol.h-rw-r--r-- 1 andre faculty 48272 Aug 4 1999 clientprotocol.o

Page 13: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Construction•Building•Snapshots•Regeneration•Optimization

Construction•Building•Snapshots•Regeneration•Optimization

Auditing•History•Traceability•Logging

Auditing•History•Traceability•Logging

Components•Versions•Configurations•Baselines•Project contexts

Components•Versions•Configurations•Baselines•Project contexts

First Generation

Accounting•Statistics•Status•Reports

Accounting•Statistics•Status•Reports

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

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

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

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

Team•Workspaces•Merging•Families

Team•Workspaces•Merging•Families

Structure•System model•Interfaces•Consistency•Selection

Structure•System model•Interfaces•Consistency•Selection

Page 14: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Second Generation

Focused on: Archiving compound elements Different version models

Characterized by: Integrated versioning & build tools Development orientation

Canonical examples: DSSE Adele

Page 15: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Archiving Compound Elements

1.0

1.1

2.0

1.2

2.1

1.2.1.0

1.2.1.1

1.0

2.0

2.2

2.1

2.3

1.0

1.1

1.3

1.2

2.0

2.0.1.0

1.0

1.1

1.2

Page 16: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Different Version Models

State-based extensional Version tree

State-based intensional Conditional compilation

Change-based extensional Change packages

Change-based intensional Change sets

Page 17: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Conditional Compilation

…#ifdef UNIX

#include <stdio.h>#endif#ifdef GRAPHICS

#include <graphics.h>#ifdef SMARTGRAPHICS

#include <smart.>#endif

#endif

Page 18: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Change Packages

1.0

1.1

2.0

1.2

2.1

1.2.1.0

1.2.1.1

1.0

2.0

2.2

2.1

2.3

1.0

1.1

1.3

1.2

2.0

2.0.1.0

1.0

1.1

1.2

1.0: BASELINE1.1: BUG FIX for reporting error #161.2: FEATURE ADDITION for graphical user interface

Page 19: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Change Sets

Baseline

Bug fix #16

Feature addition#103

Bug fix #17Feature addition

#104

Bug fix #8

Bug fix #16

Bug fix #6

Bug fix #21

AVAILABLECHANGE

SETSSYSTEM

SELECTION

Page 20: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Construction•Building•Snapshots•Regeneration•Optimization

Construction•Building•Snapshots•Regeneration•Optimization

Auditing•History•Traceability•Logging

Auditing•History•Traceability•Logging

Components•Versions•Configurations•Baselines•Project contexts

Components•Versions•Configurations•Baselines•Project contexts

Second Generation

Accounting•Statistics•Status•Reports

Accounting•Statistics•Status•Reports

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

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

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

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

Team•Workspaces•Merging•Families

Team•Workspaces•Merging•Families

Structure•System model•Interfaces•Consistency•Selection

Structure•System model•Interfaces•Consistency•Selection

Page 21: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Third Generation

Focused on: Providing process support Being all-encompassing

Characterized by: Large, complex tools Management orientation

Canonical examples: ClearCase + ClearGuide Continuus

Page 22: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Construction•Building•Snapshots•Regeneration•Optimization

Construction•Building•Snapshots•Regeneration•Optimization

Auditing•History•Traceability•Logging

Auditing•History•Traceability•Logging

Components•Versions•Configurations•Baselines•Project contexts

Components•Versions•Configurations•Baselines•Project contexts

Third Generation

Accounting•Statistics•Status•Reports

Accounting•Statistics•Status•Reports

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

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

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

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

Team•Workspaces•Merging•Families

Team•Workspaces•Merging•Families

Structure•System model•Interfaces•Consistency•Selection

Structure•System model•Interfaces•Consistency•Selection

Page 23: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Fourth Generation

?

Page 24: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Today’s Rapidly Changing Landscape

Construction by component assembly Integrators and suppliers Multiple organizations and locations Decentralized control Customized products

tailored to the individual customer Continuous change management

management after development

Page 25: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Long-Term Vision

ImplementationImplementation DeploymentDeploymentSystem TestingSystem Testing Run-TimeRun-TimeDesignDesign

ComponentsComponents Source FilesSource Files FeaturesFeatures SystemsSystems ExecutablesExecutables

Versioned Components (Architecture)

Page 26: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Long-Term Vision

ImplementationImplementation DeploymentDeploymentSystem TestingSystem Testing Run-TimeRun-TimeDesignDesign

ComponentsComponents Source FilesSource Files FeaturesFeatures SystemsSystems ExecutablesExecutables

Versioned Components (Architecture)

Page 27: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Versioned Components

Required modeling capabilities Evolution

Multiple revisions, temporary branches, baselines Variability

Property-based alternatives, interface compatibility

Optionality Property-based inclusion

Results in modeling a product family/product line

Page 28: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Ménage

Page 29: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Ménage

Page 30: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Long-Term Vision

ImplementationImplementation DeploymentDeploymentSystem TestingSystem Testing Run-TimeRun-TimeDesignDesign

ComponentsComponents Source FilesSource Files FeaturesFeatures SystemsSystems ExecutablesExecutables

Versioned Components (Architecture)

Page 31: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

CM policy Z(WebDAV)CM policy Z(WebDAV)CM policy Y

(change set)CM policy Y(change set)

Separation of Repository from Policy

Current monolithic centralized CM systems

Current monolithic centralized CM systems

Generic and distributed CM repository

CM policy X(checkout/checkin)CM policy X(checkout/checkin)

CM system = CM repository + CM policy

ExamplesRCS = ,v files + checkout/checkinTrueCHANGE = flat file + change set

Page 32: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Peer-to-Peer Repositories Policy

Pattern checkout/checkin

Manages compound artifacts Each artifact can be stored in a different

location cross-repository membership

Page 33: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Repository Design

artifacts trees

artifacts trees

artifacts trees

BOULDER

MILANO

ROTTERDAM

Page 34: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Core Policy Design

proc createfederation { myhost collection itshost theartifact } {set user $env(USER)set workspace “/tmp/workws”set filename [file tail $collection]set artifact “//myhost/Artifacts/$collection”set wsartifact “$workspace/$filename”

lock $artifact $user

nc_open $artifact $workspacenc_initiatechange $wsartifactnc_add //$itshost/theartifactnc_commitchange $wsartifactnc_close $wsartifactnc_removeattribute $artifact “Lock”

}

Page 35: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Movement upon Checkout Policy

Pattern peer-to-peer repositories

Artifacts move from physical repository to physical repository move is triggered by checkout

Page 36: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Repository Design

artifacts trees

artifacts trees

artifacts trees

BOULDER

MILANO

ROTTERDAM

Page 37: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

proc movingcheckout { workspace content version } {set user $env(USER)set host $env(REPOSITORYHOME)set artifact “//$host/Artifacts/$content”set tree “//$host/Trees/$content”set filename [file tail $content]set wsartifact “$workspace/$filename”set storageversion [lindex [nc_selectversions $artifact “PolicyVersion” $version] 0]set artifact “$artifact:$storageversion”set locked [nc_testandsetattribute $artifact “Lock” $user]

lock $artifact $user

nc_open $artifact $workspacenc_initiatechange $wsartifactnc_move $artifact $hostnc_move $tree $host

}

Core Policy Design

Page 38: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Long-Term Vision

ImplementationImplementation DeploymentDeploymentSystem TestingSystem Testing Run-TimeRun-TimeDesignDesign

ComponentsComponents Source FilesSource Files FeaturesFeatures SystemsSystems ExecutablesExecutables

Versioned Components (Architecture)

Page 39: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Deployment: the Problem

Producer Consumer

Page 40: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Deployment: the Problem

Producer Consumer

Page 41: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Deployment: the Problem

Producer Consumer

Page 42: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Deployment: the Problem

Producer Consumer

Page 43: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Deployment Life Cycle

Release

Retire

Reconfig Adapt RemoveUpdate

Install

Producer

Consumer

Page 44: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

SRM

Releasing a complete system of systems.

Page 45: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

SRM

Retrieving a complete system of systems.

Page 46: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Dock

Agent

Agent

Agent

Release Dock

Agent

Agent

EnterpriseDock

Agent

Agent Agent

FieldDock

Agent FieldDock

Wide-AreaEvent Service

Agent-based deployment.

Page 47: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Software Dock

Enterprise, distributed control.

Page 48: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Long-Term Vision

ImplementationImplementation DeploymentDeploymentSystem TestingSystem Testing Run-TimeRun-TimeDesignDesign

ComponentsComponents Source FilesSource Files FeaturesFeatures SystemsSystems ExecutablesExecutables

Versioned Components (Architecture)

Page 49: Configuration Management

©2001, University of California, IrvineInstitute for Software Research

Conclusion

CM as a discipline is changing Broader scope Wide-ranging responsibility Intermingling with other disciplines

CM tools will be vastly different Component-based Design, development, deployment, and run-

time Not just implementation

Much research remains to be done