Presentation on theme: "Sablime Highly Integrated Change Management Alcatel-Lucent Services Business Group"— Presentation transcript:
Sablime Highly Integrated Change Management Alcatel-Lucent Services Business Group firstname.lastname@example.org
23 July 2008 2 Sablime ® – management, teamwork, and quality Alcatel-Lucents Sablime ® is a software configuration management system. Does issue management Centralizes, organizes, manages proposed changes for software products Defines a standard process for dealing with these proposed changes Does configuration management Archives, manages the different versions of files as the files change over time Selects appropriate combinations of versions for integration, testing, delivery Ensures that all changes to files are tracked (who, when, what, why) Manages the process of integrating the work of different developers Automates workflow as changes are considered, implemented, tested Responsibility is clearly defined by the current phase in the changes lifecycle Next responsible party is notified as each phase is completed
23 July 2008 3 Issue Management & Change/Configuration Management Tracking issues What issues have been raised? What was done about issue Z? What do we do when issues are raised? What needs attention now? Tracking changes What version is this? How does this version differ from version N? What changed this week? When did requirement X go away? Why did requirement X go away? These activities are distinct, but closely related.
23 July 2008 4 Issues Whatever crops up that may cause a change Feature requests Emerging requirements Change in customer or vendor schedule Defects Ripple effects from other changes Not every issue results in a change But using a common method for tracking & handling issues is a Good Thing
23 July 2008 5 Dealing with Issues Common pattern Identify Investigate, discuss, decide (or procrastinate …) Implement decision Verify implementation Archive (or try to remember) What constitutes doing this well? Timely response Appropriate decision Relevant stakeholders notified & consulted Learning from past experience
23 July 2008 6 Issue management tools – why people use them Opportunities & proposals for changes arise constantly Every proposed change looked good to somebody Proposals need to be handled methodically & consistently Natural tendency is for management to respond to the latest squeaky wheel Changes often have unintended side-effects Project needs to remember what changes were made, and why
23 July 2008 7 Configuration management tools – why people use them Files change throughout development Variants of the same file usually exist at the same time, in different places This multiplicity of versions presents constant opportunities for errors Developers need some protection from each others changes Complex changes must be coordinated across multiple files A partially-implemented change can render a product un-buildable Developers need some protection from their own changes Most changes initially contain errors Recovering from this is much easier if previous file versions are easily available Reproducing the version of a product set to a customer is project- critical Requires having the corresponding version of each file available Requires knowing which version that is!
23 July 2008 8 Where does CM fit in a software project? How is it regarded? Great enabler? Necessary evil? Meaningless overhead? Who are the users (and other stakeholders) of CM? Developers Managers Integrators Others … ? – Testers – QA – Tech Support – CM administrators – Document writers – Process engineers
23 July 2008 9 Getting the most from Software CM Stakeholders of CM have differing interests The diversity of roles leads to their placing differing demands on CM Natural tendency is for one or two stakeholders to become dominant Software development improves when interests are better balanced And this requires only a moderate amount of compromise Well-designed CM makes software development faster (as well as better) And it does not have to be expensive Or hard to administer Development efficiency is largely driven by four key stakeholders: Developers Integrators – Testers – Managers
23 July 2008 10 Stakeholder conflicts & compromises Scenario: Developer wants to make a change (s)he knows is correct Manager needs to know what changes are in the product Easy, bad solution: Developer sneaks in the change, buried with some other, documented change; no record that change was done (Why is this so bad?) Unrealistic solution: Impose maximal control and levels of review for all changes at all stages of development (What is the problem here?) Reasonable compromise: Give developers a way to jumpstart the change process, which can be turned off when tightest control is needed Change is properly identified, and manager has option to keep it from being integrated into the release
23 July 2008 11 Stakeholder conflicts & compromises (2) Scenario: Developer wants a stable environment, to avoid dealing with in-coming changes while implementing a feature or fix Integrator wants to avoid diagnosing why code worked in the developers environment, but failed in the project build environment Easy, bad solution: Developers each maintain their own version of the product, which they update only as necessary (Heavy burden on integrator) Unrealistic solution: Every fix or feature is developed to conclusion on its own branch. Latest versions from integration branch are merged and tested before changes are submitted to integration (Heavy burden on developer) Reasonable compromise: Shared branch for integration & development, with ability to cherry-pick changes for builds, based on readiness
23 July 2008 12 Developers Access files without tripping over each other Work confidently, knowing previous versions are available for fallback Work on the right version Integrators Get right versions to build Retrieve past configurations reliably Testers Test and promote features & fixes Work based on item readiness (including dependencies) Note exceptions, follow up with appropriate developers, log interactions Managers Control & characterize release contents Manage issues & status, not file changes per se Balancing Stakeholder Needs More about Developer CM Needs (p28) More about Integrator CM Needs (p30) More about Tester CM Needs (p31) More about Manager CM Needs (p32) Other Roles CM Needs (p34)
23 July 2008 13 Integrated CM Integrates change management with issue management Track issues in a project database as tangible objects (MRs) Issues follow a defined life cycle with states, roles, notifications Every file change is tied to some particular issue Product configuration is fully defined by issue content Integrates CM into the development process CM drives development, integration, testing, & management Directs the focus, manages the interactions, coordinates the work Several variants of this implemented at Lucent since 1980s Different technology bases (SCCS, ClearCase, CVS, Subversion …) Different levels of integration & complexity Different degrees of success
23 July 2008 14 Integrated CM (MR-based development) Developers MR describes what to do and groups logical changes Generic accumulates the changes for a release Physical dependencies are tracked automatically Integrators MR-based builds keep logical changes together MR states & dependencies determine availability for build Testers Passing/rejecting MR determines disposition of corresponding changes MR bundles change requirements (purpose, priority), with actual changes, role assignments, and notations Managers MR = unit of deliverable functionality = unit of resource allocation = unit of change control MR state transitions record & automate workflow Release is characterized by what MRs it contains (physical audit trail)
23 July 2008 15 Sablime ® Most successful Lucent implementation of integrated CM First Bell Labs in-house release in 1987 Sold commercially since 1990 New releases or updates about twice a year Features Enables most integration to be done unattended & without merging Provides fully implemented (and customizable) processes out-of-box Scales easily from small to large, geographically-distributed projects Supports multiple active release streams per product Manages dependencies automatically Product web site: http://www.bell-labs.com/project/sablimehttp://www.bell-labs.com/project/sablime
23 July 2008 16 Sablime in a nutshell Sablime manages the development process from the perspective of Modification Requests (MRs). Change management drives development, integration, testing, and management Directs the focus, manages the interactions, coordinates the work The MR lifecycle defines a workflow based on roles. Changes of state correspond to handoffs between roles, and are accompanied by email notifications. Roles and process are ready to use out of the box. Level of formality can be adjusted as needed, but the process defined by the tool is standard across all projects and sites. MRs manage access to project files, and capture the changes made to them. Every file change is tied to some particular MR Product configuration is fully defined by MR content* * Sablimes most distinctive feature; present since the first release.
23 July 2008 17 Sablime Release Highlights Support for binary files; depended-upon MRs can be included automatically. Eclipse interface Support for Linux. Unreserved checkouts and merging. Undo check-ins; tester assignments; pre- and post- triggers; configurable permissions. Web without setuid-root Unix/Linux releases Windows releases Sablime name trademarked. First commercial sales. Visual Studio interface Attachments User-defined fields Automated dependency tracking; MR annotations; in-process metrics. Product-level analysis phase; MR linkage across projects. User-based licensing X11 GUI interface Windows client Excel interface Custom web reports Get versions by specifying the changes (MRs) to include. Dependency checking. Track MR independently in multiple generics; role-based workflow; generic-level analysis phase; multiple test teams & test states per generic. CLI and forms- based interfaces. Process customizable by MR class. Web interface No-edit init script; customizable state names 198719901995200020052008 sfw1.1 u1 6.1 u3u2 5.26.0 u1u3u2u1u2u3 5.04.33.01.04.03.14.14.18.104.22.168.0 3.0.1 sfw1.0sfw1.2
23 July 2008 18 Integrated CM in Sablime ® Developers No confusion over which version to work on MR annotations & attachments capture observations & clarifications Integrators No confusion over which MRs are eligible for build Build different combinations of MRs without any changes to integration branch Testers No confusion over which changes/feature/fixes are ready for testing MR annotations manage follow-up communications with developers Managers No confusion over status of an MR (or overall project) On-demand status updates delivered to managers spreadsheet New or changed items are marked for easy identification
23 July 2008 19 Approve the MR Document Product Defect in an MR Screen the MR Design Receives MRG Fix Acceptable? Use MRG to Implement a Fix Nochange the MRG YES NO FIX NOT REQUIREDFIX REQUIRED ORIGINATOR MR ADMINISTRATOR GENERIC ADMINISTRATOR ASSIGNED TESTER ORIGINATOR Use MRG to Test the Fix TEST PASSED TEST FAILED ASSIGNEE Build Load with Fix PACKAGER APPROVER Outcome Acceptable? NO STUDY DEVELOPER Assign the MRG for Study Investigation Outcome Investigate MRG GENERIC ADMINISTRATOR Assign the MRG CLOSER Close the MR YES Activate the MRG Sablime change request process
23 July 2008 20 Developer implements to make file changes The Core MR Lifecycle accepted created Manager assigns MR to a developer Tester or developer or customer creates new MR MR Review Board accepts MR for a release Manager approves MRs changes for inclusion in official baseline Tester testpasses MR Developer submits MR Integrator includes MRs changes in project build assigned approved submitted Tester or integrator rejects MR Users and Roles test states
23 July 2008 28 Developer Creates, modifies source files and documents Puts items under source control May need to rename or rearrange files Wants to minimize overhead of dealing with CM system Often needs to make the same change in multiple places Dislikes doing this by hand Often sees problems in the code and wants to fix them right away Uses private workspaces for development & test Needs to build, use, and experiment with, private versions of the product Likes to have a stable environment in which to work Needs to stay current with the rest of the project Investigates issues Needs to capture & communicate observations & clarifications of issues (Continued Next Page)
23 July 2008 29 Developer (continued) May need to coordinate with other developers Dislikes being locked out by another users edits Dislikes having his/her changes accidentally overlaid by someone elses May or may not be comfortable with merging Sometimes interested in change history For rollback or reference May use an integrated development environment (IDE) Dislikes having to step out of the IDE to do a task Usually has several items in queue or in progress at any time Wants to be notified if these are rescheduled or change in priority Sometimes wants to associate a change with more than one issue Return to Presentation
23 July 2008 30 Integrator (Load Builder) Creates and maintains the build environment and build procedures Performs periodic and other builds Defines what to build May work from integration plan, or may build whatever is ready Prepares sources for building Diagnoses build problems Updates development baseline Determines issue content of loads Archives build information Performs integration testing Promotes issues (for system testing) or sends them back for further work Occasionally changes source files Interested in knowing what files / issues have changed since the previous load Return to Presentation
23 July 2008 31 Tester Designs & runs tests Tests application for usability, conformity to requirements, functionality, performance Raises issue when test fails Regression-tests the builds to detect errors introduced by changes Tests builds to verify that particular issues have been resolved Needs to know what changes a build contains (which issues to test) Verifies that changes for an issue meet (and do not exceed) their mandate Certifies the resolution or sends it back for further work May collaborate with developer in getting issues resolved Through direct contact Through annotating issues Return to Presentation
23 July 2008 32 Manager Plans & oversees releases Negotiates release content and date Makes commitments with customers, gets commitments from suppliers Allocates resources May need to move features into or out of a release, as priorities change or slippages occur Concerned about (and manages) dependencies between features Assesses readiness to ship, makes final go/no-go decision Writes release letter Needs to monitor what changes are put into builds Dislikes undocumented changes Tracks by features and issues, not by code changes (Continued Next Page)
23 July 2008 33 Manager (continued) Monitors status of issues Tracks release progress by overall status of issues Tracks critical issues individually May need to follow up when an issue fails to progress May track project action items as issues May track suppliers issues Under pressure to deliver functionality to customer quickly, with limited resources Return to Presentation
23 July 2008 34 Tech Support Records incidents (trouble tickets) Matches these to known problems & workarounds Looks up incidents By ticket number By customer info By problem description Updates knowledge base Raises, champions issues on behalf of end user Checks issue status on behalf of end user Would like automatic updates of issue status in incident system (Continued Next Page)
23 July 2008 35 CM Administrator Installs & upgrades CM system Creates & customizes product databases Does routine maintenance Defines & implements procedures for backup & recovery Audits & repairs product databases Creates & runs reports, on behalf of self or others Writes & installs custom policy scripts (triggers) Administers user access Adds, deletes user IDs Resets user passwords Sets user permissions Supports local users Answers routine questions Reports problems to CM vendor (Continued Next Page)
23 July 2008 36 MR Review Board Reviews incoming MRs Prioritizes, postpones, revisits MRs Assigns MRs for study Maps MRs to releases for implementation Notifies stakeholders about MR dispositions Normally consists of representatives from Product & project management Development Testing Tech support Return to Presentation
23 July 2008 37 Where does CM fit in a software project? Clean room paradigm Artifacts are developed and baselined CM controls are then imposed Subsequent changes are tightly controlled Cat herding paradigm Team has produced something of interest to users (& management) CM is introduced Team continues work, adjusting to (or subverting) the CM system Traffic control paradigm Artifacts are placed in CM system as soon as they are in (internal) use CM system coordinates changes, improving overall flow Prevention of coordination failures improves quality and schedule Surveillance paradigm Know what youve got (throughout development as well as afterwards) Keep knowledge in a central, public place (not in peoples mailboxes)
23 July 2008 38 Troublesome CM concerns Copy-and-change development (Too) many active release streams Dev. environments all different; shared environment not used Too many last-minute changes Blowing away an earlier fix Undocumented changes
23 July 2008 39 Sablime ® – some key competitors Issue management systems ClearQuest (IBM) Remedy IssueNet (Elsinore) Bugzilla (open source) Integrated issue / configuration management systems Razor (Visible) Synergy (Telelogic) Configuration management systems ClearCase (IBM) Perforce Visual SourceSafe (Microsoft) CVS (open source) Subversion (open source)
23 July 2008 40 Where Sablime ® is better than its competitors Defines & implements an effective, standard development process Issue management drives development, integration, testing, and management Directs the focus, manages the interactions, coordinates the work Easy to follow: users use it with minimal training Integrates configuration management with issue management Seamless integration – single product, single database Tracks issues in project database as tangible objects (MRs) Traceability – every file change is tied to a particular issue Product configuration is completely defined by issue content Provides fully implemented (& customizable) processes out-of-box Level of formality can be adjusted as needed, but the process defined by the tool is standard across all projects and sites.
23 July 2008 41 Where Sablime ® is better than its competitors (2) Enables most integration to be done unattended & without merging Inexpensive Does not require dedicated hardware Does not require a separate database product Licensing model does not load costs into the first year Easy to administer Low network bandwidth consumption enables geographically distributed teams to work without the need to replicate databases No root permissions required No special software needed for backup & recovery
23 July 2008 42 File Changes in Sablime ® Developer checks in the file Developer checks out a file in a generic Sablime ® locks the file in the generic and gives the developer the latest version, which includes all changes up to that point. Developer changes and tests the file Sablime ® computes change between new and previous versions, stores the change, and unlocks the file in this generic. File remains locked from further checkouts in this generic. Developer submits the MR generic has one working branch per file The new change will be included when the file is next checked out. Change is now eligible for inclusion in project builds
23 July 2008 43 Builds: Sablime ® vs. selection-based system file foo.c REL1.0REL2.0 release 1 (generic g1) release 2 (generic g2) release 3 (generic g3) file foo.c builders list of MRs or MR states constructs a version for nightly build builders view selects a version for nightly build (usually latest version on some branch)
Your consent to our cookies if you continue to use this website.