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.

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 = “andre@ics.uci.edu” 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

23. Fourth Generation ?

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