Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Continuous Delivery Introduction Deck

Continuous Delivery Introduction Deck

A deck I used for introducing CD to clients, business stakeholders - not too technical.

Clarence Bakirtzidis

July 02, 2013
Tweet

More Decks by Clarence Bakirtzidis

Other Decks in Programming

Transcript

  1. CD: IN A NUTSHELL • “Continuous Delivery is a software

    development discipline where you build software in such a way that the software can be released to production at any time.” [1] • “With Continuous Delivery (CD), teams continuously deliver new versions of software to production by decreasing the cycle time between an idea and usable software through the automation of the entire delivery system: build, deployment, test, and release.” [2] • CD takes Agile and Continuous Integration further to enable frequent, automated, repeatable, low-risk delivery into Production (“the last mile”). Tuesday, 2 July 13
  2. CD: THE BUSINESS VISION • What if you could have

    a business idea and put it into production in a week? In a day? • What if you had a button you could press, at any time, which released all your software into production? What if you trusted what it did, knew the impact of clicking it? • What if business stakeholders controlled that button and had the information they need to know when to press it? Credits: These questions were taken from ThoughtWorks CD marketing decks. Tuesday, 2 July 13
  3. PIPE DREAM OR REALITY? Let’s talk about baby steps first...

    Image credit: https://twitter.com/clarenceb_oz/status/146807284637507584/photo/1 More examples for Australian IT companies practicing CD: http://www.cio.com.au/article/414420/continuous_delivery_next_step_agile_management/ Tuesday, 2 July 13
  4. CD: IT’S NOT ALL OR NOTHING Traditional Delivery Continuous Delivery

    +3 months +6 months +18 months The Business: “We’re happy to stop here” or “We ran out of funding...” • Start Small - Quick Wins • Aim for Incremental Improvement to Reduce Cycle Times • Ask: “What’s the ROI?” and Show: “Here’s the ROI!” by use of metrics Tuesday, 2 July 13
  5. TRADITIONAL DELIVERY • Long Cycle Times: Missed Business Opportunities, Little

    Feedback, High-Risk • Siloed Teams: Business & IT (Dev, Test, Ops), Duplication of Effort • Phased Delivery Approach: Waterfall, Lots of Planning, Big Upfront Design, Intolerant to Change • Manual Work: Lots of Rework, Reliance of Key Individuals, Error-Prone • Late Integration: Isolated/Misguided Development Efforts, Poor Communication • Infrequent Releases: Large Batch Size, Costly and Stressful Releases Tuesday, 2 July 13
  6. CONTINUOUS DELIVERY • Business Agility: Ability to change rapidly, react

    to market trends, explore more business ideas and revenue streams • Lower Risk: Fail Fast, Try Things Out, Embrace Change, Predictable Releases, Small Batches of Work • Reduced Cost: Less Rework, Less Waste, Reduced Test and Release Efforts • Improved Visibility: Live Dashboards, IT Progress Visibility, Real Metrics, Feedback • Improved Collaboration: Business and IT, Intra-IT teams: Dev, Test, Ops Tuesday, 2 July 13
  7. AGILE 101 But we are already doing Agile... Iteration 0

    1 2 3 4 Analysis + Design Development Testing + Showcase Integration + QA Release and operation Customer Centralized QA IT Operations "Agile" team The "last mile" Tuesday, 2 July 13
  8. CD: BUILDING UPON AGILE AND CI Realise the promise of

    Agile and Continuous Integration [3] Image Source: Adaptive Leadership - Accelerating Enterprise Agility by Jim Highsmith Tuesday, 2 July 13
  9. LET’S TALK ABOUT QUALITY “Cease dependence on mass inspection to

    achieve quality. Improve the process and build quality into the product in the first place” W. Edwards Deming Further Discussion: http://www.strategicinventorymanagement.com/1/post/2010/06/demings-point-3-cease-dependence-on-mass-inspection.html Tuesday, 2 July 13
  10. CONTINUOUS DELIVERY Taking Agile from Business Idea Through to Users

    in Production Customer Delivery team Constant flow of new features into production Tuesday, 2 July 13
  11. CD: LITMUS TEST • Can the business slice features into

    small, valuable, independent units? (MVP, YAGNI, INVEST) • How long would it take to deploy a change involving a single line of code? • Level and Quality of Automated Testing done in Development • Collaboration (Silos: Business, IT, Between Different Initiatives) • Continuous Integration (Bring the Pain Forward, Late Integration is Risky) • Configuration Management (Identify all the Bill of Materials for a Release) Tuesday, 2 July 13
  12. PRACTICES SUPPORTING CD[2] • Incremental Development: Business Feature Breakdown, Design

    Slicing, Feature Toggles, Branch By Abstraction • Configuration Management: Asset Repositories, Configuration Catalogue • Continuous Integration: Commit Often, Feedback, Stop the Line, Dashboards • Testing: BDD, TDD, Automated Tests, Test Pyramid, Stub Systems, Ease of Obtaining/Creating Test Data • Deployment Pipeline: Automated Deployment, Single Path To Production, Value-Stream Map • Build and Deployment Scripting: Dependency Management, Scripted Deployment, Common Language, Externalised Configuration, Unified Deployment, Fail Fast Tuesday, 2 July 13
  13. MORE PRACTICES SUPPORTING CD [2] • Deploying and Releasing Applications:

    Build Once - Deploy Many, Dark Launching, Self-Service Deployment, Blue-Green Deployments, Canary Release, A/B Testing • Infrastructure and Environments: Automated Provisioning, Immune System, Lockdown Environments, Production-Like Environments, Transient Environments • Data: Dev Sandboxes, Test Data, Decouple Database, Scripted DB Changes • Collaboration: Delivery Retrospectives, Cross-Functional Teams, Root-Cause Analysis Tuesday, 2 July 13
  14. PRACTICES HINDERING CD • Releasing less often under the false

    impression that this reduces risk • Business not willing to release features incrementally (“But I need it all in!”) • Lack of production-like environments for developers and early integration testing • Relying on manual processes for build, package, release ands deploy • Siloed teams and lack of cross-functional collaboration • No automated testing and testing not done during development Tuesday, 2 July 13
  15. MORE PRACTICES HINDERING CD • Lack of caring about the

    big picture (“It’s not my job or responsibility”, “Testing is the QA department’s job!”) • “Snowflake” servers, works of art - manual tweaks and unable to reproduce from scratch • Wanting to implement CD but not willing to be agile or improve technical practices • Overly restrictive governance (gates, manual approval, etc) Tuesday, 2 July 13
  16. IMPLEMENTING CD • Deployment Pipeline (Single Path to Production, Automated

    Process) • Overcome perceived obstacles - 5 Whys • People are the key - communication, collaboration, create win-win situations • Take baby steps but measure progress • Continuous Improvement • Openness, Sharing, Inclusiveness, Integrity Tuesday, 2 July 13
  17. FURTHER READING • Continuous Delivery (Book), Jez Humble and David

    Farley: http://continuousdelivery.com/ • Continuous delivery — the next step in agile management (CIO Magazine Article) http://www.cio.com.au/article/414420/continuous_delivery_next_step_agile_management/ • Deming's Point # 3: Cease Dependence on Mass Inspection http://www.strategicinventorymanagement.com/1/post/2010/06/demings-point-3-cease-dependence-on-mass-inspection.html Tuesday, 2 July 13
  18. CREDITS / REFERENCES • [1] Continuous Delivery - Martin Fowler

    http://martinfowler.com/bliki/ContinuousDelivery.html • [2] DZone Refcardz: Continuous Delivery http://refcardz.dzone.com/refcardz/continuous-delivery-patterns • [3] Adaptive Leadership - Accelerating Enterprise Agility by Jim Highsmith • Various ThoughtWorks Continuous Delivery Slide Decks (Credits: Jez Humble, Tom Sulston and others) Tuesday, 2 July 13