Effective Software Release Management

21,884 views

Published on

A strategy for effective software release management.

Published in: Technology, Business
2 Comments
23 Likes
Statistics
Notes
No Downloads
Views
Total views
21,884
On SlideShare
0
From Embeds
0
Number of Embeds
73
Actions
Shares
0
Downloads
0
Comments
2
Likes
23
Embeds 0
No embeds

No notes for slide

Effective Software Release Management

  1. 1. Effective Software Release Management Portfolio by Michael Degnan
  2. 2. Effective Software Release Management Outline <ul><li>Caveat for online viewing </li></ul><ul><li>Strategy </li></ul><ul><li>Branching Model </li></ul><ul><li>Benefits </li></ul>
  3. 3. Effective Software Release Management Caveat for Online Viewing <ul><li>Caveat: </li></ul><ul><li>This presentation is best delivered in person. For online viewing I have attached companion files designated as such to provide clarification on the previous slide. </li></ul>
  4. 4. SW Release Strategy Dev Build Test Deploy Objective: Establish a rigorous Dev - Build - Test - Deploy circuit
  5. 5. SW Release Strategy <ul><li>Companion to previous slide... </li></ul><ul><li>Establish a rigorous Dev - Build - Test - Deploy circuit as early as possible to trap defects in the early stages of the SDLC. </li></ul><ul><li>Solid development of people, process and tools is key to accomplishing this effort. </li></ul>
  6. 6. SW Release Strategy Layer 1 - The Basics Dev Build Test Common Build Environment Nightly Full Build Test Integration Archive Dashboard Re-Use
  7. 7. SW Release Strategy <ul><li>Companion to previous slide... </li></ul><ul><li>Strategy is read bottom up beginning with: </li></ul><ul><li>Common Dev, Build and Test environment to prevent </li></ul><ul><li>inconsistencies. </li></ul><ul><li>Nightly full build as a building block to continuous builds </li></ul><ul><li>Test integration with the build system to fully qualify the build </li></ul><ul><li>Build and test dashboard to provide quick status along with health of code </li></ul><ul><li>Build re-use to reduce duplicity and increase efficiency. Developers leverage pre-built, tested code. </li></ul><ul><li>Archive and reproduction processes based on solid SCM best practice </li></ul>
  8. 8. SW Release Strategy Layer 2 - Workflow and Process Dev Build Test Deploy Dev Build Test Deploy Continuous Dev/Build/Test/Deploy Proactive Culture / Tools
  9. 9. SW Release Strategy <ul><li>Companion to previous slide... </li></ul><ul><li>Once the basics are established, it is imperative to move to the next level and establish a continuous Dev, Build, Test, Deploy circuit to flesh out defects early and often. </li></ul><ul><li>Must have culture and tools to support a successful continuous build process. This includes: </li></ul><ul><ul><ul><li>Proactive notification through email or mobile device on all build and test failures </li></ul></ul></ul><ul><ul><ul><li>Checking to ensure continuous build passes prior to leaving for the day paving the way for a clean nightly build </li></ul></ul></ul>
  10. 10. SW Release Strategy Layer 2 - Workflow and Process Mainline <ul><li>Support Parallel Development </li></ul>integ_1.0 rel_1.0 <ul><li>Check-ins </li></ul><ul><ul><li>Branch </li></ul></ul><ul><ul><li>Day </li></ul></ul><ul><ul><li>Build </li></ul></ul><ul><li>Establish Quality Criteria </li></ul>Quality is Job 1 <ul><li>Enhance Dashboard </li></ul>
  11. 11. SW Release Strategy <ul><li>Companion to previous slide... </li></ul><ul><li>Establish quality criteria per branch: Private, Developer, Integration, Mainline, Release, Patch (Example of criteria discussed in branching section) </li></ul><ul><li>Enhance dashboard to assist in breakage debugging by posting checkins to various branches where builds take place. The dashboard can default to show checkins from the past 24 hours on the integration branch and/or mainline. The dashboard should be customizable to show checkins over any user-defined period of time over any branch. </li></ul>
  12. 12. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Deeper Tool Integration: </li></ul><ul><ul><li>SCM & Defect Tracking - Determine which defects are in which build </li></ul></ul><ul><ul><li>Build & Test Harnesses - Pick and choose which tests to run. </li></ul></ul><ul><ul><li>Test Case Management - Track tests against defects, store tests and results, test engine </li></ul></ul><ul><ul><li>Metrics Dashboard - Determine overall health of code </li></ul></ul>
  13. 13. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Companion to previous slide... </li></ul><ul><li>Tooling up and providing key integration is critical for an efficient SW Release system </li></ul><ul><li>SCM tool and defect tracking tool integration provides the ability to track which defects went into which build, how many defects a given build addresses and helps protect the integrity of the codebase by allowing only valid defects to be checked into the codeline. </li></ul><ul><li>Build and test integration allows for a variety of test types to run on a given build including unit, functional, integration, system, load, performance and stress. Smoke, sanity, regression tests often include a subset of the test types listed. </li></ul><ul><li>Beefing up the previously mentioned dashboard to provide a more accurate picture on the health of the code can be done with tool integration. The dashboard may integrate such tools as: </li></ul><ul><ul><ul><li>SCM tool to determine checkin traffic </li></ul></ul></ul><ul><ul><ul><li>Defect tracking tool to determine defect injection rate and many other key metrics </li></ul></ul></ul><ul><ul><ul><li>Code collaboration tool to determine % of code reviewed by peers </li></ul></ul></ul><ul><ul><ul><li>Code coverage tool to determine % of test coverage </li></ul></ul></ul><ul><ul><ul><li>LOC tool to determine lines of code and reference against defect injection rate </li></ul></ul></ul><ul><ul><ul><li>Security tool to determine % of potential security breaches in the code </li></ul></ul></ul><ul><ul><ul><li>Development methodology tool to determine earned value and other key metrics related to an engineer’s contribution </li></ul></ul></ul>
  14. 14. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Optimization - Build Acceleration: </li></ul><ul><ul><li>Build vs. Buy Solutions: </li></ul></ul><ul><ul><ul><li>Parallel, Distributed Architecture - Leverage smart build scripts and pre-built code. </li></ul></ul></ul><ul><ul><ul><li>Electric Cloud, CodeFast - Complete dependency management, auto-correcting and learning </li></ul></ul></ul>
  15. 15. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Companion to previous slide... </li></ul><ul><li>With a solid Dev, Build, Test, Deploy circuit and robust tool integration in </li></ul><ul><li>place, it is time to see how to optimize builds. Techniques to consider </li></ul><ul><li>include: </li></ul><ul><ul><li>Ensuring your build architecture supports parallelism to build different parts of the code base in parallel </li></ul></ul><ul><ul><li>Leveraging build-once-use-many opportunities for code that rarely changes and has been thoroughly tested. i.e. stable APIs, 3rd party code </li></ul></ul><ul><ul><li>Utilize certain SCM tool features to prevent rebuilding code that has not changed - I.e. ClearCase’s clearmake feature </li></ul></ul><ul><ul><li>Consider smart build accelerator solutions such as Electric Cloud and Codefast. These solutions have gained a solid footing with many high tech companies and have proven benefits for reducing build times. </li></ul></ul>
  16. 16. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Best Practices: </li></ul><ul><ul><li>Triggers </li></ul></ul><ul><ul><ul><li>Prevent direct check-ins to main to preserve integrity of release lines </li></ul></ul></ul><ul><ul><ul><li>Require valid change ID for check-ins for easy mapping of changes to problems, issues, functionality </li></ul></ul></ul><ul><ul><ul><li>Prevent accidental removal of elements/files </li></ul></ul></ul><ul><ul><ul><li>Require check in comments for adequate documentation </li></ul></ul></ul><ul><ul><ul><li>Notifying developers of changes to particular files </li></ul></ul></ul>Best Practices
  17. 17. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Companion to previous slide... </li></ul><ul><li>A “healthy” layer of best-practice policy management is key to aiding and producing a rich, efficient software development and release system. Many of the listed best practices are not meant to slow teams down but to aid in their day-to-day efforts by driving down defects, increasing quality and allowing teams to focus on what they do best rather than spending countless hours debugging and doing rework. </li></ul>
  18. 18. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Best Practices: </li></ul><ul><ul><li>Check-in Policies </li></ul></ul><ul><ul><ul><li>Conform to quality criteria for code line </li></ul></ul></ul><ul><ul><ul><li>Code reviewed / buddy check </li></ul></ul></ul><ul><ul><ul><li>Sync from target branch prior to merging </li></ul></ul></ul><ul><ul><ul><li>Code builds and passes tests </li></ul></ul></ul><ul><ul><ul><li>Code coverage target met </li></ul></ul></ul><ul><ul><ul><li>Valid and meaningful check in comments </li></ul></ul></ul>Best Practices
  19. 19. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Companion to previous slide... </li></ul><ul><li>A note on comments: Comments are important - </li></ul><ul><li>especially when you have: </li></ul><ul><ul><li>Changed component interfaces or architecture </li></ul></ul><ul><ul><li>Moved, renamed, or deleted files. </li></ul></ul><ul><ul><li>Prettied up files by changing things like white space and bracketing </li></ul></ul>
  20. 20. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Best Practices: </li></ul><ul><ul><li>Culture of Continuous Improvement </li></ul></ul><ul><ul><ul><li>People - Provide opportunities to learn/teach/learn </li></ul></ul></ul><ul><ul><ul><li>Process - Root Cause Analysis </li></ul></ul></ul><ul><ul><ul><ul><li>Corrective action at root cause to eliminate or minimize recurrence. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Preventive maintenance - Forecast probability of events and plan ahead. </li></ul></ul></ul></ul><ul><ul><ul><li>Tools - Constant evaluation and assessment. Can we do better? </li></ul></ul></ul><ul><ul><ul><li>Customer driven - Know their needs and be proactive. </li></ul></ul></ul>Best Practices
  21. 21. SW Release Strategy Layer 3 - Integration, Optimization & Best Practices <ul><li>Companion to previous slide... </li></ul><ul><li>A culture of continuous improvement with people, process and tools results in a SW development and release process that is ever-increasing in quality. Key to this journey is knowing your customer’s needs and the problems you are trying to solve for them. </li></ul><ul><li>i.e. Capability for a developer and tester to pick and choose a particular version of a release with its corresponding tool chain against a given codeline for building and testing purposes. </li></ul>
  22. 22. SW Release Management Branching Branching Model
  23. 23. SW Release Management Branching <ul><li>All previous criteria met. In addition passes functional tests </li></ul><ul><li>Checkin a result of a merge from lower-order branch </li></ul>Not able to guarantee stability and complete, functional code. Provide a means for complex or long lasting development to occur while not impeding progress for other developers dependent on that code. Also decouples project schedules. Development <ul><li>Sync from parent codeline </li></ul><ul><li>Code reviewed </li></ul><ul><li>Code builds and passes unit test </li></ul><ul><li>Code coverage target met </li></ul>Volatile and subject to significant changes. Interim changes could disrupt Dev branch and impact others. Private or sandbox single-user branch to insulate changes from Dev branches. Safe haven for checking in interim changes to prevent losing work. Lowest level on quality hierarchy. Private or Sandbox Quality Criteria Policy Change Purpose Branch Type
  24. 24. SW Release Management Branching <ul><li>Companion to previous slide... </li></ul><ul><li>The term “sync” refers to a merge event from the higher order branch to the current branch. In many branching discussions this is referred to as a rebase. </li></ul><ul><li>Branch types are defined in order of quality criteria. Lower-ordered branches have looser (soft) criteria. Higher-ordered branches have stricter (firm) criteria. i.e. A Private or Sandbox branch is a lower-order branch to a Development branch. </li></ul><ul><li>Previous criteria refers to the criteria listed in the lower-order branch types mentioned. </li></ul>
  25. 25. SW Release Management Branching <ul><li>All previous criteria met. </li></ul><ul><li>In addition passes system, stress and performance tests. </li></ul><ul><li>No direct check ins - Checkin a result of a merge from lower-order branch. </li></ul>Tightly regulated. Only approved checkins to stabilize codebase allowed. Typically serves as the latest, greatest, code. Mainline <ul><li>All previous criteria met. </li></ul><ul><li>In addition passes integration tests. </li></ul><ul><li>Checkin a result of a merge from lower-order branch. </li></ul>Cannot guarantee stability. Integration destabilization likely to occur. Serve as an integration point. Insulates the primary codelines (i.e. mainline) from destructive integration changes. Integration Quality Criteria Policy Change Purpose Branch Type
  26. 26. SW Release Management Branching <ul><li>Code reviewed </li></ul><ul><li>Code must build and pass unit test </li></ul><ul><li>Code coverage target met </li></ul><ul><li>Functional and system tests pass </li></ul>Must support single patch to prevent forcing customers to upgrade. Only approved and tested bug fixes may be checked into patch branches. Serves to address a single patch. May continue to live pending additional fixes to patch. Patch <ul><li>Code reviewed </li></ul><ul><li>Code must build and pass unit test </li></ul><ul><li>Code coverage target met </li></ul><ul><li>Functional and system tests pass </li></ul>New development conflicts with release stabilization. Only approved and tested stabilizing fixes or bug fixes may be checked into release branches. Serves as impending or released codeline. Basis for maintenance and patching code. Accumulates patches and can serve as maintenance branch. Release Quality Criteria Policy Change Purpose Branch Type
  27. 27. SW Release Management Branching <ul><li>Companion to previous slide... </li></ul><ul><li>Other branch types may include: </li></ul><ul><li>Additional branches to meet quality criteria - be careful to weigh the associated costs carefully </li></ul><ul><li>POC (proof of concept) branches </li></ul><ul><li>Distributed development synchronization / integration depending on SCM tool used </li></ul>
  28. 28. SW Release Management Branching Release Patch = Distinct Anchor Points Development Mainline Integration Private / Sandbox = Merge = Sync (rebase)
  29. 29. SW Release Management Branching <ul><li>Companion to previous slide... </li></ul><ul><li>The diagram on the previous slide illustrates the various branch </li></ul><ul><li>types in play. Key notes are: </li></ul><ul><li>Anchor points are: Labels, Changeset IDs, Date/Timestamps </li></ul><ul><li>Rule: Merge up, Copy down. Merging should be done in soft codelines - not firm. </li></ul><ul><li>Advantage of Merge up, Copy down rule: </li></ul><ul><ul><ul><li>The lower-order branch bears the brunt of the integration effort protecting the higher-order branch </li></ul></ul></ul><ul><ul><ul><li>Get a good preview of what mainline will look like and can subject it to same battery of tests </li></ul></ul></ul>
  30. 30. SW Release Management Benefits <ul><li>Time tested strategy with following benefits: </li></ul><ul><li>Speed to market </li></ul><ul><li>Increase quality with a decrease in the cost of quality (less re-work) </li></ul><ul><li>Reduction in operating costs </li></ul><ul><li>Scalable to meet expanding needs </li></ul><ul><li>Simple and smooth development process flow </li></ul><ul><li>Increase development’s time to focus on design </li></ul>

×