Your SlideShare is downloading. ×
Configuration Management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Configuration Management

414
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
414
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
43
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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