html5-img
1 / 49

Software Configuration Management

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

Ava
Download Presentation

Software Configuration Management

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  4. 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

  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 REVISION 1.1 1.2 2.0 NEW BASELINE 2.1

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

  8. Archiving Individual Elements 1.0 1.1 1.2 1.2.1.0 2.0 1.2.1.1 2.1 MERGE

  9. 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

  10. 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

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

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

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

  19. 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

  20. 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

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

  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 Design Implementation System Testing Deployment Run-Time Versioned Components (Architecture) Components Source Files Features Systems Executables

  26. Long-Term Vision Design Implementation System Testing Deployment Run-Time Versioned Components (Architecture) Components Source Files Features Systems Executables

  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 Design Implementation System Testing Deployment Run-Time Versioned Components (Architecture) Components Source Files Features Systems Executables

  31. 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

  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 BOULDER artifacts trees artifacts trees MILANO artifacts trees 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 BOULDER artifacts trees artifacts trees MILANO artifacts trees 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 Design Implementation System Testing Deployment Run-Time Versioned Components (Architecture) Components Source Files Features Systems Executables

  39. Producer Consumer Software Deployment: the Problem

  40. Producer Consumer Software Deployment: the Problem

  41. Producer Consumer Software Deployment: the Problem

  42. Producer Consumer Software Deployment: the Problem

  43. Software Deployment Life Cycle Release Producer Retire Consumer Install Update Reconfig Adapt Remove

  44. SRM Releasing a complete system of systems.

  45. SRM Retrieving a complete system of systems.

  46. 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.

  47. Software Dock Enterprise, distributed control.

  48. Long-Term Vision Design Implementation System Testing Deployment Run-Time Versioned Components (Architecture) Components Source Files Features Systems Executables

  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

More Related