Continuous Delivery for people
who do not write code
Matthew Skelton, Head of Consulting, Conflux
confluxdigital.net / @ConfluxHQ
Leeds, 24 Sept 2018
2
Continuously Delivering CD since 2012
Matthew Skelton, Conflux
@matthewpskelton
matthewskelton.net
Leeds, UK
3
2012 2014 2015 2016
Continuous Delivery Learning Zones
4
learn.londoncd.org.uk learn.pipelineconf.info
Over 150 talks on
Continuous
Delivery from
practitioners
around the world
What is Continuous Delivery?
5
6
7
Continuous Delivery
“Reliable Software Releases
Through Build, Test, and
Deployment Automation”
A specific set of practices and disciplines,
tried and tested in many different sectors
& contexts worldwide since 2010.
Continuous Delivery for all
Applies to all kinds
of software:
● Mobile
● Embedded
● Web
● ... From Continuous Delivery with Windows & .NET, O’Reilly, 2016, cdwithwindows.net
Why Continuous Delivery?
10
11
speed
safety
We need Speed and Safety
Modern software systems are too complicated
for manual inspection and assessment
We need automated checks for almost every
aspect of the software system
Use pervasive tooling to detect problems early
13
High risk
Low risk
Small changes are less risky
Large batches of changes are almost guaranteed
to have errors or problems
Small batches are easier to reason about, easier
to diagnose, easier to change
14
Agile → Continuous Delivery
15
Jez Humble, continuousdelivery.com
Agile → Continuous Delivery
Automated testing of all aspects of a feature or
story as soon as it has been written:
● Behaviour
● Operational
● Security
● ...
The ability to release
a feature or story as
soon as it is ready.
16
CD practices for all areas
17
CD practices for all areas
Business/Workstream applications & services
Core supporting products
Auxiliary tooling: build & deployment, monitoring
Infrastructure (Kubernetes, environments, etc.)
18
cdchecklist.info
19
CD Key Principles
Rapid feedback on every change
Code is always releasable: no big manual testing
Deployment Pipeline is the only “route to live”
Decoupled, independently releasable units
Cross-functional team empowered to deploy live
20
Real example - 2013
Use visibility to increase trust → speed & safety
21
Short, wide pipelines
❌
✅
Shortest
(responsible)
path to live
Long wait for
complicated
testing
https://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/ 22
Testing in Continuous Delivery
95% of testing is automated
Operational features tested automatically
Most testers sit within Service/Product teams
Some testers act as SMEs for test approach
Exploratory Testing - specific, manual discipline
23
Deployment in CD
Deployment steps fully automated
Deploy during the day - with people around
Tracked using an orchestration tool (pipeline)
Rollbacks (if possible) or rapid roll-forward
24
Metrics and logging in CD
Service/Product teams see live metrics and logs
“Feel the hum” of running systems
Metrics and logging for:
Services/Products
Build / Deployment / Test infrastructure
25
What does
Continuous Delivery
feel like?
26
27
High-fidelity information
High-fidelity information
Near real-time feedback on changes
Instant visibility of the flow of change
Rapid drill-down for diagnostics
Rapid requirements trace-back for changes
28
29
No waiting for a release train
No waiting for a release train
Independent routes to Production
Each worksteam moves at its own speed
Interdependencies handled by disciplined
engineering practices (including versioning,
backwards-compatibility, testing techniques)
30
31
Heavy lifting done by tooling
Heavy lifting done by tooling
No need for manual inspection of change quality
No manual progressing of change sets
No ‘worrying’ whether software will work
More time to focus on more valuable things
32
33
Reliable releases
Reliable releases
Reliable tests
Reliable deployments
Reliable rollbacks
Reliable monitoring, logging, metrics
34
How do activities change with
Continuous Delivery?
35
Agile → Continuous Delivery
36
Jez Humble, continuousdelivery.com
37
Early & continuous expertise
Early & continuous expertise
Bring expertise from Release Management /
Change Management / Testing / Operations into
software dev teams on an ongoing, daily basis
The ‘wise Yoda’ for the ‘young Jedi’ teams
Enable flow of change
38
39
Assess progress regularly
Assess progress regularly
Automated code checks across multiple
dimensions
Regular checks of engineering practices
Track delivery metrics: Cycle Time, Deployment
Frequency, mean time to restore service (MTTR)
40
How do we get to
Continuous Delivery?
41
42
Many parallel routes to live
Many parallel routes to live
Each family of applications and services has its
own route to live
Rigorous testing with stubs, fakes, proxies
Rapid detection of problems and rapid restore of
previous good version
43
44
Continuous operability
Continuous operability
Work on operational features ~30% of effort
every week, every month
Operational aspects tested using automated
tests in a deployment pipeline
Availability is the #1 feature
45
Continual small steps
46
Continual small steps
47
Continual small steps
There is no sudden “switch to CD”
Incremental improvements over many months
Track using metrics, especially cycle time
48
Summary:
Continuous Delivery
49
Continuous Delivery
Small, focused changes with rapid feedback
High-fidelity information on changes via tools
Early and continuous expertise from Testing,
Release Mgt, Change Mgt, Operations
Focus on operability to reduce the unexpected
50
Further reading
51
Continuous Delivery checklist
http://cdchecklist.info/
Continuous Delivery with Windows & .NET
http://cdwithwindows.net/
Continuous Delivery Learning Zones
https://learn.pipelineconf.info/
https://learn.londoncd.org.uk/
thank you
@ConfluxHQ
confluxdigital.net

Continuous Delivery for people who do not write code - Matthew Skelton - Conflux