Configuration Management
Download as PPT, PDF•1 like•442 views
The document discusses the history and evolution of software configuration management (CM) systems. It describes three generations of CM systems that focused on archiving individual elements, compound elements, and providing extensive process support. Current and future CM systems are envisioned to support component-based development, distributed teams, and continuous integration across the entire software lifecycle from design to deployment.
![Software Configuration Management Andr é van der Hoek Institute for Software Research University of California, Irvine [email_address]](https://image.slidesharecdn.com/confmanagement-1230606021667740-2/85/Configuration-Management-1-320.jpg)
![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” }](https://image.slidesharecdn.com/confmanagement-1230606021667740-2/85/Configuration-Management-34-320.jpg)
![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 }](https://image.slidesharecdn.com/confmanagement-1230606021667740-2/85/Configuration-Management-37-320.jpg)
Configuration Management
- 1. Software Configuration Management Andr é van der Hoek Institute for Software Research University of California, Irvine [email_address]
- 2. 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
- 3. CM Spectrum of Functionality Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Susan Dart, SCM-3, 1991 Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Structure System model Interfaces Consistency Selection
- 4. Three Generations of CM Systems CCC/Harvest Functionality Proteus Jasmine EPOS VOODOO ShapeTools Asgard NUCM DaSC Vesta Adele ICE Odin Time Source Integrity Continuus CVS PVCS DSEE SCCS NSE ClearCase TRUEchange Serena Endevor Perforce RCS Sablime Research Development
- 5. First Generation Focused on: Archiving individual elements Strictly avoiding conflicts Optimizing builds Characterized by: Simple, separate tools Development orientation Canonical examples: RCS Make
- 6. Archiving Individual Elements 1.0 1.1 2.0 1.2 2.1 REVISION NEW BASELINE
- 7. Archiving Individual Elements 1.0 1.1 2.0 1.2 2.1 BRANCH LEADS TO VARIANTS 1.2.1.0 1.2.1.1
- 8. Archiving Individual Elements 1.0 1.1 2.0 1.2 2.1 MERGE 1.2.1.0 1.2.1.1
- 9. 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/2001 Time = 7:52am Comment = “Trying new stuff” ATTRIBUTES (TAGS)
- 10. 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/2001 Time = 7:52am Comment = “Trying new stuff” Lock = “[email protected]” LOCK
- 11. 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
- 12. 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
- 13. First Generation Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Structure System model Interfaces Consistency Selection
- 14. Second Generation Focused on: Archiving compound elements Different version models Characterized by: Integrated versioning & build tools Development orientation Canonical examples: DSSE Adele
- 15. 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
- 16. Different Version Models State-based extensional Version tree State-based intensional Conditional compilation Change-based extensional Change packages Change-based intensional Change sets
- 17. Conditional Compilation … #ifdef UNIX #include <stdio.h> #endif #ifdef GRAPHICS #include <graphics.h> #ifdef SMARTGRAPHICS #include <smart.> #endif #endif
- 18. 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: BASELINE 1.1: BUG FIX for reporting error #16 1.2: FEATURE ADDITION for graphical user interface
- 19. Change Sets Baseline Bug fix #16 Feature addition #103 Bug fix #17 Feature addition #104 Bug fix #8 Bug fix #16 Bug fix #6 Bug fix #21 AVAILABLE CHANGE SETS SYSTEM SELECTION
- 20. Second Generation Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Structure System model Interfaces Consistency Selection
- 21. Third Generation Focused on: Providing process support Being all-encompassing Characterized by: Large, complex tools Management orientation Canonical examples: ClearCase + ClearGuide Continuus
- 22. Third Generation Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Structure System model Interfaces Consistency Selection
- 24. 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
- 25. Long-Term Vision Implementation Deployment System Testing Run-Time Design Components Source Files Features Systems Executables Versioned Components (Architecture)
- 26. Long-Term Vision Implementation Deployment System Testing Run-Time Design Components Source Files Features Systems Executables Versioned Components (Architecture)
- 27. 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
- 28. M é nage
- 29. M é nage
- 30. Long-Term Vision Implementation Deployment System Testing Run-Time Design Components Source Files Features Systems Executables Versioned Components (Architecture)
- 31. Separation of Repository from Policy CM policy Z (WebDAV) CM policy Y (change set) Current monolithic centralized CM systems Generic and distributed CM repository CM policy X (checkout/checkin) CM system = CM repository + CM policy Examples RCS = ,v files + checkout/checkin TrueCHANGE = flat file + change set
- 32. Peer-to-Peer Repositories Policy Pattern checkout/checkin Manages compound artifacts Each artifact can be stored in a different location cross-repository membership
- 33. Repository Design artifacts trees artifacts trees artifacts trees BOULDER MILANO ROTTERDAM
- 34. 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” }
- 35. Movement upon Checkout Policy Pattern peer-to-peer repositories Artifacts move from physical repository to physical repository move is triggered by checkout
- 36. Repository Design artifacts trees artifacts trees artifacts trees BOULDER MILANO ROTTERDAM
- 37. 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 }
- 38. Long-Term Vision Implementation Deployment System Testing Run-Time Design Components Source Files Features Systems Executables Versioned Components (Architecture)
- 39. Software Deployment: the Problem Producer Consumer
- 40. Software Deployment: the Problem Producer Consumer
- 41. Software Deployment: the Problem Producer Consumer
- 42. Software Deployment: the Problem Producer Consumer
- 43. Software Deployment Life Cycle Release Retire Reconfig Adapt Remove Update Install Producer Consumer
- 44. SRM Releasing a complete system of systems.
- 45. SRM Retrieving a complete system of systems.
- 46. Software Dock Agent Agent Agent Field Dock Wide-Area Event Service Agent-based deployment. Agent Agent Agent Release Dock Agent Agent Enterprise Dock Agent Field Dock
- 47. Software Dock Enterprise, distributed control.
- 48. Long-Term Vision Implementation Deployment System Testing Run-Time Design Components Source Files Features Systems Executables Versioned Components (Architecture)
- 49. 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