Releasing small, incremental updates to production multiple times a day is the pinnacle of productivity that a software team can achieve. In this talk, I present the main advantages of continuous deployment over traditional release processes, explain the essential components of a continuous deployment infrastructure, and discuss typical challenges as well as strategies to overcome them.

1. Continuous
Deployment
Work
fl
ows
VS.1A

2. Marco
Otte-Witte
Founder, Mainmatter
2

4. 4
Let's ship bug-free software
that users like, fast!
– all of us
Let's ship bug-free software
that users like, fast!

5. 🤔
5

6. The
Classic
Approach

7. 7
main
develop
feature-1
feature-2
release-1
🔎
🚀
hotfix-1
hotfix-1
🚀

8. Everything that happens after
merging my PR is mostly a
black-box to me…

9. Long(ish)
Intervals
9

10. 10
main
develop
feature-1
feature-2
release-1
🔎
hotfix-1
hotfix-1
🚀 🚀

11. No continuous integration
11

12. 12
main
develop
feature-1
feature-2
release-1
🔎
hotfix-1
hotfix-1
🚀

13. Long(ish) time
between task completion
& (possible) rework
13

14. 14
Our "de
fi
nition of done" is
something is kind-of mostly
done …for now
– an agile team 🤡

15. Users need to wait longer
for changes
15

16. User feedback only comes
late in the process
16

17. Large, risky deployments
17

18. 18
🙀
🥰

19. Continuous
Deployment

20. 20
– Wikipedia
Continuous Deployment
≠ Continuous Delivery
Continuous deployment (CD) is
a software engineering approach
in which software functionalities
are delivered frequently through
automated deployments.

21. main
develop
feature-1
feature-2
release-1
🚀
hotfix-1
hotfix-1
🚀 🚀
21

22. main
feature-1
feature-2
🚀 🚀 🚀
22
hotfix-1
hotfix-1

23. main
feature-2-pt1
feature-1-pt-1
🚀 🚀
feature-2-pt2
hotfix-1
feature-2-pt-3
🚀 🚀
feature-1-pt-2
🚀 🚀
23

24. main 🚀
register-with-twitter
[refactor signup
controller]
[split user
accounts]
[migrate user
data]
[add Twitter
registration]
24

25. main 🚀
refactor
🚀 🚀 🚀 🚀 🚀
accounts
-model
data-
migration
drop-
compat
twitter-
de-only
twitter-
intl
25

26. photo source / giphy.com

27. photo source / giphy.com

28. Large, risky deployments
28

29. No continuous integration
29

30. Long(ish) time
between task completion
& (possible) rework
30
Done = Done

31. Users need to wait longer
for changes
31

32. Continuous
Deployment
Pipelines

33. (This all works best for web/
cloud apps)
33
⚠

34. 1-2 days
main
feature-2-pt1
feature-1-pt-1
🚀 🚀
feature-2-pt2
hotfix-1
feature-2-pt-3
🚀 🚀
feature-1-pt-2
🚀 🚀
34

35. Automatic
Deployment
35

36. Stable, fast, reversible
36

37. photo source / unsplash.com
37

38. Observability
photo source / istockphoto.com
38

39. Testing
photo source / unsplash.com
39

40. 40
main 🚀
develop
change-1
release-1
🔎

41. develop
change-1
🚀
🔎

42. Manual testing is not
an option here!
42

43. Functional correctness
(within one subsystem)
43

44. Functional correctness
(across subsystems)
44

45. Visual
correctness
45

46. Performance
46

47. Security
47

48. 48
Testing the deployment

49. photo source / unsplash.com
49
Stakeholder
approval

50. There is no staging
system anymore!
50

51. …instead, there's now many
staging systems – one per branch/PR!
develop
change
-1
🚀
🔎
🖥
51

52. 52

53. Adopting
Continuous
Deployment

54. photo source / unsplash.com
54
Technology
1. Challenge:
54

55. Automatic deployments
55

56. Automatic functional,
visual, performance testing,
security and i18n testing
56

57. From a stable set
of environments
to ad-hoc systems
57

58. photo source / unsplash.com
58
Culture
2. Challenge:

59. Breaking down walls
59

60. Bene
fi
ts of
Continuous
Deployment
Work
fl
ows

61. Increased productivity
61

62. Improved collaboration
62

63. Improved quality
63

64. Increased stability
64

65. Accelerated value delivery
65

66. Improved morale
66

67. 67
Let's ship bug-free software
that users like, fast!
– all of us

68. 68
[People] who have worked on teams
with a short delivery cycle are unwilling
to ever work anywhere else again. […]
No[body] ever got burned out from
shipping too much. [People] get
burned out from shipping too little.
– Charity Majors

69. Thanks!
info@mainmatter.com
+49 89 452 139 03
Mainmatter GmbH
Managing Director: Marco Otte-Witte
Hans-Sachs-Str. 12
München, 80469 Germany
Court of registry: Amtsgericht München
Registration number: HRB 217887
EU VAT ID: DE299706241