software configuration management n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Configuration Management PowerPoint Presentation
Download Presentation
Software Configuration Management

Loading in 2 Seconds...

play fullscreen
1 / 49

Software Configuration Management - PowerPoint PPT Presentation


  • 235 Views
  • Uploaded on

Software Configuration Management. Andr é van der Hoek Institute for Software Research University of California, Irvine andre@ics.uci.edu. Configuration Management.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Configuration Management' - Ava


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software configuration management

Software Configuration Management

André van der Hoek

Institute for Software Research

University of California, Irvine

andre@ics.uci.edu

©2001, University of California, Irvine

configuration management
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

cm spectrum of functionality
CM Spectrum of Functionality
  • Components
  • Versions
  • Configurations
  • Baselines
  • Project contexts
  • Structure
  • System model
  • Interfaces
  • Consistency
  • Selection
  • Construction
  • Building
  • Snapshots
  • Regeneration
  • Optimization
  • Controlling
  • Access control
  • Change requests
  • Bug tracking
  • Partitioning
  • Accounting
  • Statistics
  • Status
  • Reports
  • Auditing
  • History
  • Traceability
  • Logging
  • Process
  • Lifecycle support
  • Task mgmt.
  • Communication
  • Documentation
  • Team
  • Workspaces
  • Merging
  • Families

Susan Dart, SCM-3, 1991

three generations of cm systems
Three Generations of CM Systems

Continuus

DaSC

ClearCase

Perforce

NUCM

Asgard

CCC/Harvest

TRUEchange

Proteus

ICE

Serena

Vesta

Endevor

Functionality

NSE

PVCS

EPOS

DSEE

Source Integrity

Adele

VOODOO

CVS

RCS

Odin

ShapeTools

Sablime

Jasmine

Research

Development

SCCS

Time

first generation
First Generation
  • Focused on:
    • Archiving individual elements
    • Strictly avoiding conflicts
    • Optimizing builds
  • Characterized by:
    • Simple, separate tools
    • Development orientation
  • Canonical examples:
    • RCS
    • Make
archiving individual elements
Archiving Individual Elements

1.0

REVISION

1.1

1.2

2.0

NEW BASELINE

2.1

archiving individual elements1
Archiving Individual Elements

1.0

1.1

1.2

1.2.1.0

BRANCH LEADS TO VARIANTS

2.0

1.2.1.1

2.1

archiving individual elements2
Archiving Individual Elements

1.0

1.1

1.2

1.2.1.0

2.0

1.2.1.1

2.1

MERGE

archiving individual elements3
Archiving Individual Elements

1.0

1.1

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

1.2

1.2.1.0

2.0

1.2.1.1

ATTRIBUTES (TAGS)

2.1

avoiding conflicts
Avoiding Conflicts

1.0

1.1

Author = “André v/d Hoek”Date = 01/12/2001Time = 7:52amComment = “Trying new stuff”Lock = “andre@ics.uci.edu”

1.2

1.2.1.0

2.0

1.2.1.1

LOCK

2.1

optimizing the build process
Optimizing the Build Process

accesslist.o: accesslist.h accesslist.c

gcc –o accesslist.o accesslist.c

andre.o: andre.c

gcc –c andre.o andre.c

clientprotocol.o: clientprotocol.c clientprotocol.h

gcc –c clientprotocol.o clientprotocol.c

main.exe: andre.o accesslist.o clientprotocol.o

gcc andre.o accesslist.o

mv a.out main.exe

chmod a+x main.exe

optimizing the build process1
Optimizing the Build Process

-r--r--r-- 1 andre faculty 2651 Aug 4 1999 Makefile

drwxr-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

first generation1
First Generation
  • Components
  • Versions
  • Configurations
  • Baselines
  • Project contexts
  • Structure
  • System model
  • Interfaces
  • Consistency
  • Selection
  • Construction
  • Building
  • Snapshots
  • Regeneration
  • Optimization
  • Controlling
  • Access control
  • Change requests
  • Bug tracking
  • Partitioning
  • Accounting
  • Statistics
  • Status
  • Reports
  • Auditing
  • History
  • Traceability
  • Logging
  • Process
  • Lifecycle support
  • Task mgmt.
  • Communication
  • Documentation
  • Team
  • Workspaces
  • Merging
  • Families
second generation
Second Generation
  • Focused on:
    • Archiving compound elements
    • Different version models
  • Characterized by:
    • Integrated versioning & build tools
    • Development orientation
  • Canonical examples:
    • DSSE
    • Adele
archiving compound elements
Archiving Compound Elements

1.0

1.0

1.0

1.0

2.0

1.1

1.1

1.1

2.1

1.2

1.2.1.0

1.2

2.2

2.0

1.2.1.1

1.3

2.0.1.0

1.2

2.3

2.1

2.0

different version models
Different Version Models
  • State-based extensional
    • Version tree
  • State-based intensional
    • Conditional compilation
  • Change-based extensional
    • Change packages
  • Change-based intensional
    • Change sets
conditional compilation
Conditional Compilation

…#ifdef UNIX

#include <stdio.h>#endif#ifdef GRAPHICS #include <graphics.h> #ifdef SMARTGRAPHICS #include <smart.> #endif#endif

change packages
Change Packages

1.0

1.0

1.0

1.0

2.0

1.1

1.1

1.1

2.1

1.2

1.2.1.0

1.2

2.2

2.0

1.2.1.1

1.3

2.0.1.0

1.2

2.3

2.1

2.0

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

change sets
Change Sets

AVAILABLECHANGESETS

SYSTEMSELECTION

Bug fix #17

Feature addition#104

Bug fix #21

Feature addition#103

Bug fix #8

Bug fix #6

Bug fix #16

Baseline

Bug fix #16

second generation1
Second Generation
  • Components
  • Versions
  • Configurations
  • Baselines
  • Project contexts
  • Structure
  • System model
  • Interfaces
  • Consistency
  • Selection
  • Construction
  • Building
  • Snapshots
  • Regeneration
  • Optimization
  • Controlling
  • Access control
  • Change requests
  • Bug tracking
  • Partitioning
  • Accounting
  • Statistics
  • Status
  • Reports
  • Auditing
  • History
  • Traceability
  • Logging
  • Process
  • Lifecycle support
  • Task mgmt.
  • Communication
  • Documentation
  • Team
  • Workspaces
  • Merging
  • Families
third generation
Third Generation
  • Focused on:
    • Providing process support
    • Being all-encompassing
  • Characterized by:
    • Large, complex tools
    • Management orientation
  • Canonical examples:
    • ClearCase + ClearGuide
    • Continuus
third generation1
Third Generation
  • Components
  • Versions
  • Configurations
  • Baselines
  • Project contexts
  • Structure
  • System model
  • Interfaces
  • Consistency
  • Selection
  • Construction
  • Building
  • Snapshots
  • Regeneration
  • Optimization
  • Controlling
  • Access control
  • Change requests
  • Bug tracking
  • Partitioning
  • Accounting
  • Statistics
  • Status
  • Reports
  • Auditing
  • History
  • Traceability
  • Logging
  • Process
  • Lifecycle support
  • Task mgmt.
  • Communication
  • Documentation
  • Team
  • Workspaces
  • Merging
  • Families
today s rapidly changing landscape
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
long term vision
Long-Term Vision

Design

Implementation

System Testing

Deployment

Run-Time

Versioned Components (Architecture)

Components

Source Files

Features

Systems

Executables

long term vision1
Long-Term Vision

Design

Implementation

System Testing

Deployment

Run-Time

Versioned Components (Architecture)

Components

Source Files

Features

Systems

Executables

versioned components
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
long term vision2
Long-Term Vision

Design

Implementation

System Testing

Deployment

Run-Time

Versioned Components (Architecture)

Components

Source Files

Features

Systems

Executables

separation of repository from policy
Separation of Repository from Policy

CM policy Z

(WebDAV)

CM policy Y

(change set)

CM system =

CM repository +

CM policy

CM policy X

(checkout/checkin)

Generic and distributed

CM repository

Current monolithic

centralized CM systems

Examples

RCS = ,v files + checkout/checkin

TrueCHANGE = flat file + change set

peer to peer repositories policy
Peer-to-Peer Repositories Policy
  • Pattern
    • checkout/checkin
  • Manages compound artifacts
  • Each artifact can be stored in a different location
    • cross-repository membership
repository design
Repository Design

BOULDER

artifacts

trees

artifacts

trees

MILANO

artifacts

trees

ROTTERDAM

core policy design
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 $workspace

nc_initiatechange $wsartifact

nc_add //$itshost/theartifact

nc_commitchange $wsartifact

nc_close $wsartifact

nc_removeattribute $artifact “Lock”

}

movement upon checkout policy
Movement upon Checkout Policy
  • Pattern
    • peer-to-peer repositories
  • Artifacts move from physical repository to physical repository
    • move is triggered by checkout
repository design1
Repository Design

BOULDER

artifacts

trees

artifacts

trees

MILANO

artifacts

trees

ROTTERDAM

core policy design1
Core Policy Design

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 $workspace

nc_initiatechange $wsartifact

nc_move $artifact $host

nc_move $tree $host

}

long term vision3
Long-Term Vision

Design

Implementation

System Testing

Deployment

Run-Time

Versioned Components (Architecture)

Components

Source Files

Features

Systems

Executables

software deployment life cycle
Software Deployment Life Cycle

Release

Producer

Retire

Consumer

Install

Update

Reconfig

Adapt

Remove

slide44
SRM

Releasing a complete system of systems.

slide45
SRM

Retrieving a complete system of systems.

software dock

Release

Dock

Agent

Agent

Agent

Enterprise

Dock

Agent

Agent

Field

Dock

Agent

Software Dock

Wide-Area

Event Service

Field

Dock

Agent

Agent

Agent

Agent-based deployment.

software dock1
Software Dock

Enterprise, distributed control.

long term vision4
Long-Term Vision

Design

Implementation

System Testing

Deployment

Run-Time

Versioned Components (Architecture)

Components

Source Files

Features

Systems

Executables

conclusion
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