Introduction to Continuous Delivery
André Meurer
@themeurer
Head of Software Engineering @ Olympic
How long would it take to get a
one line code change
into production using the current process?
Idea
Funding
Analysis
Test
Deploy
Water-scrum-fall
The last mile
The “tail period” or “last mile”
• Time from code freeze to release
– Beta & regression testing
– Code integration & integ...
Continuous Delivery is about
reducing risk of releases
and making deployments boring
Reduce risk of releases
Fast, automated feedback on the production
readiness of your application every time there is a
change
Constant flow of
sma...
Key Principles
• Constant flow of small incremental changes into prod
• Software always production ready
• Automate almost...
Build the right thing
• Every business idea is just a hypotesis
• Most features are rarely or never used
• Don’t ask custo...
Failure will happen
Faster feedback
Delivery Pipeline
Testing & promoting
Continuous integration
• Early integration
• Everyone’s changes integrated frequently in the same place
• Build & test at ...
The software testing pyramid
GUI
Acceptance
tests
Unit & component
tests
More business-facing
Less stable
More realistic
L...
The software testing cupcake anti-pattern
Trunk based development
• Check-in or merge into trunk at least once per day
• Feature branches should be short lived
• Br...
Inside out development
• Build from the bottom
– DB – Business Logic – UI
• Feature not accessible until full development ...
Feature toggles/switches
• Deploy incomplete features switched off
– Be aware of feature switch madness
– Switches need to...
Feature switches
Dev
Smaller
Many
Short
Operations Business
Larger
Few
Long
Granularity
Numbers
Lifetime
Branch by abstraction
• Parallel routes
• Make architectural changes
– Interface to create abstraction
– Abstraction layer...
Roll Forward
• Rollback strategy is complex & risky
• Easier to fix something and get it through the pipeline
Canary Releases
• Release features to smaller groups/clusters
• Test/verify stability/performance/etc.
• Roll out to more/...
Blue Green deployments
• Two instances of the production environment
– Current PROD (blue)
– Upgrade environment (green)
•...
Quality
• QA inspects quality
• Everyone is responsible for quality
• QA represents the user
IT ops team close to dev team
• Sit together: Dev, QA, and Ops
• Have sysadmin as part of the development team
• Deploy to...
Delivery Pipeline Tools
• Orchestration/CI
– Team City
– Jenkins
– Bamboo
• Delivery Manager
– LiveRebel
– OctopusDeploy
•...
Where do I start?
• Why do you want to do it?
• It will take time, start now
• CI is first step
• Get the architecture rig...
It’s a journey
• Fundamental change to the way most organisations ship
software
• Releases tied to business needs, not IT ...
Resources
• Jez Humble: Continuous Delivery
• Patrick Kua: Implementing Continuous Delivery
• Facebook: Moving fast at sca...
Introduction to continuous delivery
Upcoming SlideShare
Loading in …5
×

Introduction to continuous delivery

649 views

Published on

Published in: Software, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
649
On SlideShare
0
From Embeds
0
Number of Embeds
122
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Reliability & Stability
    Shorter mean time to recovery
    If you have a small set of changes in your release, the set of possible causes is also small
    Enables you to figure out what the problem is & resolve it very quickly
    If something is really hard (i.e., releasing software), do it again and again until it becomes second nature. Don’t live with the pain: do it over and over until you are very good at it
  • The faster you get feedback, the faster you can fix the problem – the cost of fixing the mistake is minimal
  • Trade off
    Not everything can be a unit test
    But try to minimise the number of tests towards the top of the pyramid, focusing on as many tests as possible towards the bottom of the pyramid
  • Introduction to continuous delivery

    1. 1. Introduction to Continuous Delivery André Meurer @themeurer Head of Software Engineering @ Olympic
    2. 2. How long would it take to get a one line code change into production using the current process?
    3. 3. Idea Funding Analysis Test Deploy Water-scrum-fall
    4. 4. The last mile
    5. 5. The “tail period” or “last mile” • Time from code freeze to release – Beta & regression testing – Code integration & integration testing – Documentation – Bug fixing – Deployments
    6. 6. Continuous Delivery is about reducing risk of releases and making deployments boring
    7. 7. Reduce risk of releases
    8. 8. Fast, automated feedback on the production readiness of your application every time there is a change Constant flow of small increments into production Software always production ready
    9. 9. Key Principles • Constant flow of small incremental changes into prod • Software always production ready • Automate almost everything • Build, deploy, test, release, repeat • Use humans for high value stuff • Manual testing, approvals • Keep everything in source control • If it hurts, do it more often, and bring the pain forward • Done means released in production • Continuous improvement – don’t try to do it all at once
    10. 10. Build the right thing • Every business idea is just a hypotesis • Most features are rarely or never used • Don’t ask customers what they want: try it out • Release a minimum viable product • Can respond quickly to market demands • Hypotesis – MVP – Analyse – Repeat
    11. 11. Failure will happen
    12. 12. Faster feedback Delivery Pipeline
    13. 13. Testing & promoting
    14. 14. Continuous integration • Early integration • Everyone’s changes integrated frequently in the same place • Build & test at every check-in • Rapid feedback • It’s a practice, not a tool
    15. 15. The software testing pyramid GUI Acceptance tests Unit & component tests More business-facing Less stable More realistic Lower cost Easier maintenance More stable Faster feedback Exploratory/ manual
    16. 16. The software testing cupcake anti-pattern
    17. 17. Trunk based development • Check-in or merge into trunk at least once per day • Feature branches should be short lived • Branches discourage refactoring – People don’t know what code other team members are touching, so they are hesitant to refactor for risk of impact • Branches delay integration and hide risk • Merging wastes time and is tedious
    18. 18. Inside out development • Build from the bottom – DB – Business Logic – UI • Feature not accessible until full development is complete • Small slices/stories to enable fast feedback
    19. 19. Feature toggles/switches • Deploy incomplete features switched off – Be aware of feature switch madness – Switches need to be deleted as the feature is in production • Control who can see the new feature – Test it with a small group of users – Ensure it handles the load – Gradually increase group of users if appropriate • Separate deployments from releases
    20. 20. Feature switches Dev Smaller Many Short Operations Business Larger Few Long Granularity Numbers Lifetime
    21. 21. Branch by abstraction • Parallel routes • Make architectural changes – Interface to create abstraction – Abstraction layers with two working implementations – Swap bit by bit of the code to the new architecture until complete – Old implementation can be removed once no longer used • DB changes – No breaking schema changes until code is ready to deal with new schema
    22. 22. Roll Forward • Rollback strategy is complex & risky • Easier to fix something and get it through the pipeline
    23. 23. Canary Releases • Release features to smaller groups/clusters • Test/verify stability/performance/etc. • Roll out to more/rest of users
    24. 24. Blue Green deployments • Two instances of the production environment – Current PROD (blue) – Upgrade environment (green) • Start routing small groups/clusters of people to Green environment • Swap them
    25. 25. Quality • QA inspects quality • Everyone is responsible for quality • QA represents the user
    26. 26. IT ops team close to dev team • Sit together: Dev, QA, and Ops • Have sysadmin as part of the development team • Deploy to all environments the same way we deploy to production
    27. 27. Delivery Pipeline Tools • Orchestration/CI – Team City – Jenkins – Bamboo • Delivery Manager – LiveRebel – OctopusDeploy • Infrastructure Automation – Chef – Puppet – Bcfg2 – CFEngine
    28. 28. Where do I start? • Why do you want to do it? • It will take time, start now • CI is first step • Get the architecture right • Culture of continuous improvement • It will need investment
    29. 29. It’s a journey • Fundamental change to the way most organisations ship software • Releases tied to business needs, not IT constraints • Minimise lead time from idea to live (concept to cash) • IT no longer the bottleneck • Buy-in from client is critical
    30. 30. Resources • Jez Humble: Continuous Delivery • Patrick Kua: Implementing Continuous Delivery • Facebook: Moving fast at scale • John Allspaw: 10 deploys per day, dev and ops cooperation at Flickr • David Cramer: Practicing Continuous Delivery • Sam Newman: The path to continuous delivery • Rolf Russell: Introduction to Continuous Delivery

    ×