2. 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
3. CD:THE BUSINESSVISION
• 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
4. 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
5. 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 CycleTimes
• Ask: “What’s the ROI?” and Show: “Here’s the ROI!” by use of metrics
Tuesday, 2 July 13
6. 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
7. CONTINUOUS DELIVERY
• Business Agility:Ability to change rapidly, react to market trends, explore more business ideas and
revenue streams
• Lower Risk: Fail Fast,TryThings Out, Embrace Change, Predictable Releases, Small Batches of Work
• Reduced Cost: Less Rework, Less Waste, ReducedTest and Release Efforts
• Improved Visibility: Live Dashboards, IT ProgressVisibility, Real Metrics, Feedback
• Improved Collaboration: Business and IT, Intra-IT teams: Dev,Test, Ops
Tuesday, 2 July 13
8. 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
9. 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
10. LET’STALK 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
11. CONTINUOUS DELIVERY
Taking Agile from Business IdeaThrough to Users in Production
Customer
Delivery team
Constant flow of new features into production
Tuesday, 2 July 13
12. CD: LITMUSTEST
• 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
13. PRACTICES SUPPORTING CD[2]
• Incremental Development: Business Feature Breakdown, Design Slicing, FeatureToggles, Branch By
Abstraction
• Configuration Management:Asset Repositories, Configuration Catalogue
• Continuous Integration: Commit Often, Feedback, Stop the Line, Dashboards
• Testing: BDD,TDD,AutomatedTests,Test Pyramid, Stub Systems, Ease of Obtaining/CreatingTest Data
• Deployment Pipeline:Automated Deployment, Single PathTo Production,Value-Stream Map
• Build and Deployment Scripting: Dependency Management, Scripted Deployment, Common Language,
Externalised Configuration, Unified Deployment, Fail Fast
Tuesday, 2 July 13
14. 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-FunctionalTeams, Root-Cause
Analysis
Tuesday, 2 July 13
15. 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
16. 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
17. 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
18. 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
19. 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