1.
Continuous Delivery for people
who do not write code
Matthew Skelton, Head of Consulting, Conflux
confluxdigital.net / @ConfluxHQ
Leeds, 24 Sept 2018

2.
2

3.
Continuously Delivering CD since 2012
Matthew Skelton, Conflux
@matthewpskelton
matthewskelton.net
Leeds, UK
3
2012 2014 2015 2016

4.
Continuous Delivery Learning Zones
4
learn.londoncd.org.uk learn.pipelineconf.info
Over 150 talks on
Continuous
Delivery from
practitioners
around the world

5.
What is Continuous Delivery?
5

6.
6

7.
7

8.
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.

9.
Continuous Delivery for all
Applies to all kinds
of software:
● Mobile
● Embedded
● Web
● ... From Continuous Delivery with Windows & .NET, O’Reilly, 2016, cdwithwindows.net

10.
Why Continuous Delivery?
10

11.
11
speed
safety

12.
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.
13
High risk
Low risk

14.
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

15.
Agile → Continuous Delivery
15
Jez Humble, continuousdelivery.com

16.
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

17.
CD practices for all areas
17

18.
CD practices for all areas
Business/Workstream applications & services
Core supporting products
Auxiliary tooling: build & deployment, monitoring
Infrastructure (Kubernetes, environments, etc.)
18

19.
cdchecklist.info
19

20.
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

21.
Real example - 2013
Use visibility to increase trust → speed & safety
21

22.
Short, wide pipelines
❌
✅
Shortest
(responsible)
path to live
Long wait for
complicated
testing
https://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/ 22

23.
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

24.
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

25.
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

26.
What does
Continuous Delivery
feel like?
26

27.
27
High-fidelity information

28.
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.
29
No waiting for a release train

30.
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.
31
Heavy lifting done by tooling

32.
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.
33
Reliable releases

34.
Reliable releases
Reliable tests
Reliable deployments
Reliable rollbacks
Reliable monitoring, logging, metrics
34

35.
How do activities change with
Continuous Delivery?
35

36.
Agile → Continuous Delivery
36
Jez Humble, continuousdelivery.com

37.
37
Early & continuous expertise

38.
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.
39
Assess progress regularly

40.
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

41.
How do we get to
Continuous Delivery?
41

42.
42
Many parallel routes to live

43.
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.
44
Continuous operability

45.
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

46.
Continual small steps
46

47.
Continual small steps
47

48.
Continual small steps
There is no sudden “switch to CD”
Incremental improvements over many months
Track using metrics, especially cycle time
48

49.
Summary:
Continuous Delivery
49

50.
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

51.
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/

52.
thank you
@ConfluxHQ
confluxdigital.net