Informatics 211 Configuration Management Coordination André van

Скачать презентацию Informatics 211 Configuration Management Coordination André van

267ce114300c9376888b3cdb3b51b207.ppt

Количество слайдов: 105

Informatics 211: Configuration Management & Coordination André van der Hoek University of California, Irvine Donald Bren School of Information and Computer Sciences Department of Informatics andre@ics. uci. edu 19 March 2018 – 10: 58: 19 (c) 2007 University of California, Irvine – André van der Hoek 1

Direct Conflicts Pete’s workspace Ellen’s workspace CM repository changes Pete changes Ellen Conflicting changes to the same artifact 19 March 2018 – 10: 58: 20 (c) 2007 University of California, Irvine – André van der Hoek 3

Indirect Conflicts Pete’s workspace Ellen’s workspace CM repository changes Pete changes Ellen Conflicting changes to different artifacts 19 March 2018 – 10: 58: 20 (c) 2007 University of California, Irvine – André van der Hoek 4

Configuration Management n “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 19 March 2018 – 10: 58: 20 (c) 2007 University of California, Irvine – André van der Hoek 5

CM Spectrum of Functionality Components Structure Construction Controlling • Versions • Configurations • Baselines • Project contexts • System model • Interfaces • Consistency • Selection • Building • Snapshots • Regeneration • Optimization • Access control • Change requests • Bug tracking • Partitioning Accounting Auditing Process Team • Statistics • Status • Reports • History • Traceability • Logging • Lifecycle support • Task mgmt. • Communication • Documentation • Workspaces • Merging • Families Susan Dart, SCM-3, 1991 19 March 2018 – 10: 58: 20 (c) 2007 University of California, Irvine – André van der Hoek 6

Functionality Three Generations of CM Systems Continuus Da. SC Clear. Case Perforce Asgard NUCM CCC/Harvest TRUEchange Proteus ICE Serena Vesta Endevor NSE PVCS EPOS DSEE Source Integrity Adele VOODOO CVS RCS Odin Shape. Tools Sablime Jasmine Research Development SCCS Time 19 March 2018 – 10: 58: 21 (c) 2007 University of California, Irvine – André van der Hoek 7

First Generation n Focused on: – archiving individual elements – strictly avoiding conflicts n Characterized by: – simple, separate tools – development orientation n Canonical examples – SCCS – RCS – Make 19 March 2018 – 10: 58: 21 (c) 2007 University of California, Irvine – André van der Hoek 8

First Generation: Version Graphs 1. 0 1. 1 1. 2. 1. 0 2. 0 Author = “André v/d Hoek” Date = 01/12/2001 Time = 7: 52 am Comment = “Trying new stuff” Lock = “andre@ics. uci. edu” 1. 2. 1. 1 2. 1 19 March 2018 – 10: 58: 21 (c) 2007 University of California, Irvine – André van der Hoek 9

First Generation Components Structure Construction Controlling • Versions • Configurations • Baselines • Project contexts • System model • Interfaces • Consistency • Selection • Building • Snapshots • Regeneration • Optimization • Access control • Change requests • Bug tracking • Partitioning Accounting Auditing Process Team • Statistics • Status • Reports • History • Traceability • Logging • Lifecycle support • Task mgmt. • Communication • Documentation • Workspaces • Merging • Families 19 March 2018 – 10: 58: 21 (c) 2007 University of California, Irvine – André van der Hoek 10

Second Generation n Focused on: – archiving compound elements – different version models n Characterized by: – integrated versioning & build tools – development orientation n Canonical examples: – – 19 March 2018 – 10: 58: 22 CVS Subversion PVCS Source. Safe (c) 2007 University of California, Irvine – André van der Hoek 11

Four Canonical Version Models n State-based extensional – version tree n State-based intensional – conditional compilation n Change-based extensional – change packages n Change-based intensional – change sets 19 March 2018 – 10: 58: 22 (c) 2007 University of California, Irvine – André van der Hoek 12

Conditional Compilation … #ifdef UNIX #include #endif #ifdef GRAPHICS #include #ifdef SMARTGRAPHICS #include #endif … 19 March 2018 – 10: 58: 22 (c) 2007 University of California, Irvine – André van der Hoek 13

Change Packages 1. 0 1. 1 1. 0 2. 0 1. 1 1. 2. 1. 0 2. 1 1. 2 2. 0 1. 2. 1. 1 2. 2 1. 3 2. 0 2. 1 19 March 2018 – 10: 58: 22 (c) 2007 University of California, Irvine – André van der Hoek 2. 0. 1. 0 14

Change Sets SYSTEM SELECTION Bug fix #17 Feature addition #103 Bug fix #16 Baseline 19 March 2018 – 10: 58: 22 AVAILABLE CHANGE SETS Feature addition #104 Bug fix #21 Bug fix #8 Bug fix #6 Bug fix #16 (c) 2007 University of California, Irvine – André van der Hoek 15

Second Generation Components Structure Construction Controlling • Versions • Configurations • Baselines • Project contexts • System model • Interfaces • Consistency • Selection • Building • Snapshots • Regeneration • Optimization • Access control • Change requests • Bug tracking • Partitioning Accounting Auditing Process Team • Statistics • Status • Reports • History • Traceability • Logging • Lifecycle support • Task mgmt. • Communication • Documentation • Workspaces • Merging • Families 19 March 2018 – 10: 58: 22 (c) 2007 University of California, Irvine – André van der Hoek 16

Third Generation n Focused on: – providing process support – being all-encompassing n Characterized by: – large, complex tools – management orientation n Canonical examples: – Clear. Case together with Clear. Guide – CM/Synergy 19 March 2018 – 10: 58: 22 (c) 2007 University of California, Irvine – André van der Hoek 17

Third Generation Components Structure Construction Controlling • Versions • Configurations • Baselines • Project contexts • System model • Interfaces • Consistency • Selection • Building • Snapshots • Regeneration • Optimization • Access control • Change requests • Bug tracking • Partitioning Accounting Auditing Process Team • Statistics • Status • Reports • History • Traceability • Logging • Lifecycle support • Task mgmt. • Communication • Documentation • Workspaces • Merging • Families 19 March 2018 – 10: 58: 22 (c) 2007 University of California, Irvine – André van der Hoek 18

No… n CM core functionality is stable with well-understood choices n CM tool enhancement seems to be limited to feature creep, not fundamental new approaches n SCM workshop series has ended n Only a few pure CM papers are being published as of late 19 March 2018 – 10: 58: 23 (c) 2007 University of California, Irvine – André van der Hoek 20

Maybe… n 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 … n Mining software repositories – no better repository than the CM repository n Still some problems left – indirect conflicts – concern management n Coordination 19 March 2018 – 10: 58: 23 (c) 2007 University of California, Irvine – André van der Hoek 21

Product Line Architectures: The Problem n “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] n But how to manage this asset? 19 March 2018 – 10: 58: 23 (c) 2007 University of California, Irvine – André van der Hoek 22

Mining Software Repositories n Configuration management repositories are traditionally a “depot” – occasional roll-back – occasional search for relevant information n But what if we used the information captured by configuration management repositories to our advantage – understanding software developers – helping software developers 19 March 2018 – 10: 58: 38 (c) 2007 University of California, Irvine – André van der Hoek 51

Possible Data Sources Pete’s Workspace Ellen’s Workspace Palantír Client Visualization Extractor Internal State Visualization Palantír Server Capture Bootstrap Extractor Event Database Internal State Analyzer Workspace Wrapper The Eclipse Platform Analyzer CM System Workspace Wrapper CM Server The Eclipse Platform Event Listeners Workspace Event Listeners CM Plug-in 19 March 2018 – 10: 58: 38 Workspace Repository CM Plug-in (c) 2007 University of California, Irvine – André van der Hoek 52

Replaying History n Extends the usefulness of Workspace Activity Viewer from just understanding the present moment to also beginning to understand how projects evolve n In the following videos, history is partially simulated based on CM archive data 19 March 2018 – 10: 58: 49 (c) 2007 University of California, Irvine – André van der Hoek 62

Indirect Conflicts Pete’s workspace Ellen’s workspace CM repository changes Pete changes Ellen Conflicting changes to different artifacts 19 March 2018 – 10: 58: 50 (c) 2007 University of California, Irvine – André van der Hoek 64

Traditional CM Approaches Coordination mechanism Direct conflicts Indirect conflicts Pessimistic Locking before Avoided, at the Not addressed changes are made expense of project delays Optimistic Automated merging after changes have been made 19 March 2018 – 10: 58: 50 Resolved, except for overlapping changes (c) 2007 University of California, Irvine – André van der Hoek Not addressed 65

Key Observations n CM workspaces in reality provide two kinds of isolation – “good” isolation (insulation) v shields developers from parallel changes to artifacts – “bad” isolation (seclusion) v hides knowledge of what artifacts other developers are changing n Opportunities for breaking “bad” isolation are limited – based on repository information only – initiated by developer only – addressing direct conflicts only n In essence, a specific form of coordination is enforced and limited by the process underlying the CM system 19 March 2018 – 10: 58: 50 (c) 2007 University of California, Irvine – André van der Hoek 66

Undesirable Consequences (Field Studies) n The more parallel work takes place, the lower the quality of the code that is delivered n Developers recognize the significance of direct conflicts – direct conflicts are considered “a pain” – developers will race to be the first to commit their changes, just to avoid the task of merging – much informal communication takes place in order to attempt to avoid direct conflicts n Developers do not recognize the significance of indirect conflicts – considered to be a normal part of the work (e. g. , integration, resolving test case failures, dealing with bugs) 19 March 2018 – 10: 58: 51 (c) 2007 University of California, Irvine – André van der Hoek 67

Our Objective n Support more effective coordination of parallel work by allowing “good” isolation but breaking “bad” isolation n Enable early detection and resolution of direct and indirect conflicts – while these conflicts emerge n Mitigate the impact of direct and indirect conflicts – through provoked self-coordination of developers 19 March 2018 – 10: 58: 51 (c) 2007 University of California, Irvine – André van der Hoek 68

Three Laboratory Experiments n Text-based evaluation of the effectiveness of the user interface – Palantír versus no Palantír n Code-based evaluation of the effectiveness of providing awareness information on indirect conflicts – Palantír with direct and indirect conflicts versus Palantír with direct conflicts only 19 March 2018 – 10: 58: 53 (c) 2007 University of California, Irvine – André van der Hoek 73

Experiment Design n Confederate-based design – ensured consistency in number and nature of conflicts – introduced direct and indirect conflicts – controlled individual differences in project activities n Dependent variables – number of conflicts detected (and resolved) – time-to-completion of tasks – number of coordination attempts 19 March 2018 – 10: 58: 53 (c) 2007 University of California, Irvine – André van der Hoek 74

Result 1: Early Conflict Detection and Resolution n More direct conflicts were identified and resolved before check-in n More indirect conflicts were identified n More indirect conflicts were resolved 19 March 2018 – 10: 58: 53 (c) 2007 University of California, Irvine – André van der Hoek 75

Result 2: Indirect Conflict Notification n More indirect conflicts were detected and resolved when potential indirect conflicts were highlighted – the indirect conflicts we seeded were easy n Developers’ knowledge of the structure of the code is inadequate to just rely on direct conflict notification 19 March 2018 – 10: 58: 55 (c) 2007 University of California, Irvine – André van der Hoek 76

Result 3: Time-to-Completion n Direct conflicts – group using Palantír is faster – resolution time for conflict is less n Indirect conflicts – group using Palantír is a little slower – more conflicts are detected and resolved 19 March 2018 – 10: 58: 55 (c) 2007 University of California, Irvine – André van der Hoek 77

Result 4: Amount of Communication n The use of awareness leads to fewer coordination attempts and less time spent in those attempts – not statistically significant – but sufficiently indicative and sufficiently provocative to warrant additional study Text DC Cntrl Exp IC 19 March 2018 – 10: 58: 55 group Cntrl Exp detect SCM chat 39 39 78 71 17 12 0 2 95 85 5 38 7 30 4 11 0 9 11 50 (c) 2007 University of California, Irvine – André van der Hoek others total 78

Interpreting The Results n Direct and indirect conflicts are detected as they n n emerge Developers undertake action upon noticing a potential conflict Fewer conflicts grow “out of hand” The resulting code is of higher quality The penalty may be a small increase in time now – but the experiments do not account for the time later that developers must otherwise spend on resolving conflicts that are committed to the CM repository 19 March 2018 – 10: 58: 55 (c) 2007 University of California, Irvine – André van der Hoek 79

Limitations to Palantír n Disconnect between awareness and action n Potential for information overload n Effective, but not a rich work context – further examination is required n Opportunities for further improvement and extension are limited by the directory/file metaphor – does not map very well to our mental model of the code 19 March 2018 – 10: 58: 55 (c) 2007 University of California, Irvine – André van der Hoek 80

Lighthouse Approach n Leverage a secondary monitor to provide developers with a coordination platform that integrates awareness and action n Center the platform on the metaphor of emerging design n Contextualize the awareness information based on the changes currently being made 19 March 2018 – 10: 58: 55 (c) 2007 University of California, Irvine – André van der Hoek 81

Awareness Information: Basics Class n Emerging design is the Online. Store name: String address: URL place. Order(order: Order): void add. Item(item: Item): void get. Quantity(item: String): int scan(item: ID): boolean design as it resides in the code n Continuously kept up to date with every code change – UML-like diagrams n Keeps the developer abreast of how the code changes at the interface level 19 March 2018 – 10: 58: 56 (c) 2007 University of California, Irvine – André van der Hoek 83

Awareness Information: Basics Class n Emerging design is the design as it resides in the code n Continuously kept up to date with every code change Store (Store) Online. Store name: String address: Address address: URL place. Order(order: Order): void add. Item(item: Item): void get. Quantity(item: String): int (scan(item: ID): boolean) scan(item: ID): boolean 19 March 2018 – 10: 58: 56 – UML-like diagrams n Keeps the developer abreast of how the code changes at the interface level (c) 2007 University of California, Irvine – André van der Hoek 84

Which Changes by Whom and When? Class Store (Store) Online. Store name: String address: Address address: URL place. Order(order: Order): void add. Item(item: Item): void get. Quantity(item: String): int (scan(item: ID): boolean) scan(item: ID): boolean 19 March 2018 – 10: 58: 57 (c) 2007 University of California, Irvine – André van der Hoek 85

Progression of Changes Class Store (Store) Online. Store name: String address: Address address: URL place. Order(order: Order): void add. Item(item: Item): void get. Quantity(item: String): int (scan(item: ID): boolean) scan(item: ID): boolean 19 March 2018 – 10: 58: 57 (c) 2007 University of California, Irvine – André van der Hoek 86

Coordination Actions Class Store (Store) Online. Store name: String address: Address address: URL place. Order(order: Order): void add. Item(item: Item): void get. Quantity(item: String): int (scan(item: ID): boolean) scan(item: ID): boolean 19 March 2018 – 10: 58 (c) 2007 University of California, Irvine – André van der Hoek 87

Future Plans #2: Project Management Base abstraction upon which to show design deviations, test coverage, code volatility, aging, … – for the entire system 19 March 2018 – 10: 59: 14 (c) 2007 University of California, Irvine – André van der Hoek 98

Passive awareness of development activities and developers, manage information overload Instant messaging, monitoring changes to artifacts Communication archival along with artifacts Advanced conflict detection Collocation benefits to distributed development Fine grained versioning, conflict resolution Parallel development, roles and access rights Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Fu Basi nct c ion alit y R Pro igid ces s Inf o Dis rmati cov on ery Inf or Pro mati vis on ion Coordination Asynchronous communication Communication 19 March 2018 – 10: 59: 17 Access to common set of artifacts, isolated workspaces and version control Artifact Management (c) 2007 University of California, Irvine – André van der Hoek T ask allocation and assignment Task Management 99

Passive awareness of development activities and developers, manage information overload Instant messaging, monitoring changes to artifacts Communication archival along with artifacts Advanced conflict detection Collocation benefits to distributed development Fine grained versioning, conflict resolution Parallel development, roles and access rights Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Fu Basi nct c ion alit y R Pro igid ces s Inf o Dis rmati cov on ery Inf or Pro mati vis on ion Layers: Coordination Paradigms Asynchronous communication Communication 19 March 2018 – 10: 59: 18 Access to common set of artifacts, isolated workspaces and version control Artifact Management (c) 2007 University of California, Irvine – André van der Hoek T ask allocation and assignment Task Management 100

Passive awareness of development activities and developers, manage information overload Instant messaging, monitoring changes to artifacts Communication archival along with artifacts Advanced conflict detection Collocation benefits to distributed development Fine grained versioning, conflict resolution Parallel development, roles and access rights Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Fu Basi nct c ion alit y R Pro igid ces s Inf o Dis rmati cov on ery Inf or Pro mati vis on ion Strands: Technical Dimensions of Coordination Asynchronous communication Communication 19 March 2018 – 10: 59: 18 Access to common set of artifacts, isolated workspaces and version control Artifact Management (c) 2007 University of California, Irvine – André van der Hoek T ask allocation and assignment Task Management 101

Continuous coordination, collaborative architecture, seamless development environments, Passive awareness of development activities and developers, manage information overload Instant messaging, monitoring changes to artifacts Communication archival along with artifacts Advanced conflict detection Collocation benefits to distributed development Fine grained versioning, conflict resolution Parallel development, roles and access rights Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Fu Basi nct c ion alit y R Pro igid ces s Inf o Dis rmati cov on ery Inf or Pro mati vis on ion Pro Be voke ha vio d r A New Paradigm: Provoked Behavior Asynchronous communication Communication 19 March 2018 – 10: 59: 19 Access to common set of artifacts, isolated workspaces and version control Artifact Management (c) 2007 University of California, Irvine – André van der Hoek T ask allocation and assignment Task Management 102

Continuous coordination, collaborative architecture, seamless development environments, Passive awareness of development activities and developers, manage information overload Instant messaging, monitoring changes to artifacts Communication archival along with artifacts Advanced conflict detection Collocation benefits to distributed development Fine grained versioning, conflict resolution Parallel development, roles and access rights Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Fu Basi nct c ion alit y R Pro igid ces s Inf o Dis rmati cov on ery Inf or Pro mati vis on ion Pro Be voke ha vio d r Configuration Management Asynchronous communication Communication 19 March 2018 – 10: 59: 19 Access to common set of artifacts, isolated workspaces and version control Artifact Management (c) 2007 University of California, Irvine – André van der Hoek T ask allocation and assignment Task Management 103

Conclusion n CM is a long-standing field which has seen numerous contributions – some highly influential (sometimes delayed by as much as 20 years) – others indirectly shaping – others utterly useless n While the core ideas of CM have been well developed, there is still much room for improvement – particularly if one considers CM to be a coordination problem – particularly if one brings together CM with other disciplines n Software engineering can be cool 19 March 2018 – 10: 59: 21 (c) 2007 University of California, Irvine – André van der Hoek 104

Acknowledgments n David Redmiles n Anita Sarma n Chris Van der Westhuizen n Ban Al-Ani n Ping Chen n Erik Trainer n Isabella Almeida n Stephen Quirk n Marcelo Alvim n Roger Ripley . . and the rest of the Continuous Coordination research group at UC Irvine. 19 March 2018 – 10: 59: 21 (c) 2007 University of California, Irvine – André van der Hoek 105