1 / 65

Informatics 211: Configuration Management & Coordination

Informatics 211: Configuration Management & Coordination. André van der Hoek Department of Informatics Donald Bren School of Information and Computer Sciences University of California, Irvine andre@ics.uci.edu. A Typical Development Scenario. Pete’s workspace. Ellen’s workspace. A. B. C.

tayte
Download Presentation

Informatics 211: Configuration Management & Coordination

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

  2. A Typical Development Scenario Pete’s workspace Ellen’s workspace A B C D E C CMrepository

  3. Direct Conflicts Pete’s workspace Ellen’s workspace A B C D E C CMrepository Conflicting changes to the same artifact

  4. Traditional CM Techniques

  5. Traditional CM Techniques Both with the side effect of keeping a history of changes.

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

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

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

  9. First Generation • Focused on: • archiving individual elements • strictly avoiding conflicts • Characterized by: • simple, separate tools • development orientation • Canonical examples • SCCS • RCS • Make

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

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

  12. Second Generation • Focused on: • archiving compound elements • different version models • Characterized by: • integrated versioning & build tools • development orientation • Canonical examples: • CVS • Subversion • PVCS • SourceSafe

  13. Four Canonical Version Models • State-based extensional • version tree • State-based intensional • conditional compilation • Change-based extensional • change packages • Change-based intensional • change sets

  14. Conditional Compilation …#ifdef UNIX #include <stdio.h>#endif#ifdef GRAPHICS #include <graphics.h> #ifdef SMARTGRAPHICS #include <smart.> #endif#endif…

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

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

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

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

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

  20. A Fourth Generation ?

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

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

  23. Producer Consumer Software Deployment: the Problem

  24. Producer Consumer Software Deployment: the Problem

  25. Producer Consumer Software Deployment: the Problem

  26. Producer Consumer Software Deployment: the Problem

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

  28. SourceForge

  29. RPM

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

  31. Classic Versioning for Product Lines

  32. Advanced Versioning for Product Lines

  33. Advanced Versioning for Product Lines

  34. Advanced Versioning for Product Lines

  35. Advanced Versioning for Product Lines

  36. Advanced Versioning for Product Lines

  37. Advanced Versioning for Product Lines

  38. Advanced Versioning for Product Lines

  39. Advanced Versioning for Product Lines

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

  41. Activity Viewer

  42. Highlighting

  43. Distance is Age

  44. Rotation Allows Different Viewpoints

  45. Larger Projects: Time Ordered

  46. Larger Projects: Most Activity Ordered

  47. Larger Projects: Developer View

  48. Same Project Ordered by Time

  49. Committed versus Not Committed

  50. (Animated)

More Related