650 likes | 718 Views
Explore the evolution of Configuration Management (CM) systems and tools, from Traditional CM Techniques to Three Generations of CM Systems. Learn about the functionalities, characteristics, and examples of each generation.
E N D
Informatics 211:Configuration Management & Coordination André van der Hoek Department of Informatics Donald Bren School of Information and Computer SciencesUniversity of California, Irvineandre@ics.uci.edu
A Typical Development Scenario Pete’s workspace Ellen’s workspace A B C D E C CMrepository
Direct Conflicts Pete’s workspace Ellen’s workspace A B C D E C CMrepository Conflicting changes to the same artifact
Traditional CM Techniques Both with the side effect of keeping a history of changes.
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 • 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 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 • Focused on: • archiving individual elements • strictly avoiding conflicts • Characterized by: • simple, separate tools • development orientation • Canonical examples • SCCS • RCS • Make
First Generation: Version Graphs 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
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 • Focused on: • archiving compound elements • different version models • Characterized by: • integrated versioning & build tools • development orientation • Canonical examples: • CVS • Subversion • PVCS • SourceSafe
Four Canonical Version Models • State-based extensional • version tree • State-based intensional • conditional compilation • Change-based extensional • change packages • Change-based intensional • change sets
Conditional Compilation …#ifdef UNIX #include <stdio.h>#endif#ifdef GRAPHICS #include <graphics.h> #ifdef SMARTGRAPHICS #include <smart.> #endif#endif…
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
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 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 • Focused on: • providing process support • being all-encompassing • Characterized by: • large, complex tools • management orientation • Canonical examples: • ClearCase together with ClearGuide • Cm/Synergy
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
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
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
Producer Consumer Software Deployment: the Problem
Producer Consumer Software Deployment: the Problem
Producer Consumer Software Deployment: the Problem
Producer Consumer Software Deployment: the Problem
Software Deployment Life Cycle Release Producer Retire Consumer Install Update Reconfig Adapt Remove
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?
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