An overview about Continuous Delivery. What is it? Why should you care about it? See how your team can implement Continuous Delivery in order to deliver business value in a sustainable yet efficient way.

1. Continuous Delivery
an overview
@joebew42

2. Delivery
We want to bring value
to our customers

3. How we deliver value?
Putting working software
in production

4. How we put “working” software in production

5. How we put “working” software in production
● E.g. Package and deploy in production through a manual procedure
○ What are possible risks here
■ Increased risk of release
■ Long time releases
■ Poor documentation
■ Human error
■ Stress
■ Not automatic / Not repeatable
■ Black friday, for real!
■ Cowboy style

6. Let’s go with Automation

7. Let’s go with Automation
● How?
○ E.g. lay down a script that does the manual work for you
● What we earn?
○ Auto documentation
○ Repeatable
○ Everything is in one authoritative place
○ Fast and easy deployments
● What are the risks?
○ Long time releases (we take weeks or months for production deployment)
○ Someone has to manual trigger it
○ Lose visibility into what we released in production
■ E.g. versions and history

8. Let’s go Continuous

9. Let’s go Continuous
● How?
○ Triggers script on every code changes
● What we earn?
○ Shared code base
○ Release more frequently
○ Automatic deployment
○ Visibility on what is released
● What are the risks?
○ Introduce bugs in production is easier
○ Less confidence about what works and what does not

10. Let’s go with Integration

11. Let’s go with Integration
● How?
○ Test the behaviour of the software in a production-like environment
● What we earn?
○ Catch bugs before you get into production
○ More confidence about what works and what does not
● What are the risks?
○ Feedback loops can take a long time

12. Let’s go with Integration (part II)

13. Let’s go with Integration (part II)
● How?
○ Write tests that can be easily launched on the local machine
● What we earn?
○ Catch bugs before you get into production
○ More confidence about what works and what does not
○ Instant feedback upon code changes
○ Local code changes do not affect shared code base
○ Each release is production-ready
● What is still missing here?
○ A better release management
■ e.g. we don’t want to release on Friday afternoon
■ e.g. feature is ready but the monitoring is not
■ e.g. we want to collect metrics before get into production
■ other ...

14. Let’s go with Delivery
● How?
○ Understand how to deliver business value in a sustainable yet efficient way
● What we earn?
○ Visualize and observe the entire process of delivery
○ Whole team is involved
○ Separate the build from the deployment process
● Can we go better?
○ The process change over time in order to meet the new team needs
○ Gather feedbacks and ask why & how the process should be improved:
■ e.g. Retrospectives and showcases
■ e.g. The 5 Whys technique can be helpful to find the root cause of a problem
■ e.g. Maybe someone external have to get into the team
○ Rotate the people
○ Each team has its own process of Continuous Delivery

15. Some hints for your team
● The delivery process is one of your responsibilities
● The process you use to deliver value is a model that changes over time in
order to adapt to requirements changes
○ Inspect and adapt
○ Gather feedback
○ Invite the right people
○ Fail fast, fail often … Safely
● Try to learn more about your business
● Try to be autonomous

16. Some numbers
From “The Phoenix Project”
COMPANY DEPLOY
FREQUENCY
DEPLOY
LEAD TIME
RELIABILITY CUSTOMER
FEEDBACK
AMAZON 23.000/day minutes high high
GOOGLE 5.500/day minutes high high
NETFLIX 500/day minutes high high
FACEBOOK 1/day hours high high
TWITTER 3/week hours high high
TYPICAL
ENTERPRISE
once every
9 months
months or more low/medium low/medium

17. Going further ...
By book: Continuous Delivery
Jez Humble and David Farley
By web: https://continuousdelivery.com/
Is maintained by Jez Humble. This website is a good place to keep you up to
date about CD topics.
By book: The Phoenix Project
Gene Kim, Kevin Behr and George Spafford
Is a novel about IT, DevOps and helping your business win