1
00:00:00,040 --> 00:00:04,080
OK, so we all know continuous 
integration CI, right? 

2
00:00:04,240 --> 00:00:07,240
It's pretty much the bedrock of 
how modern software gets built. 

3
00:00:07,440 --> 00:00:10,280
Merging, building basic tests. 
Absolutely. 

4
00:00:10,280 --> 00:00:13,960
CI is table stakes now. 
It solves that classic developer

5
00:00:13,960 --> 00:00:16,680
headache. 
Merge conflicts, broken builds, 

6
00:00:16,680 --> 00:00:18,960
you know, right? 
But it often stops there, 

7
00:00:18,960 --> 00:00:20,720
doesn't it? 
The code gets built, maybe 

8
00:00:20,720 --> 00:00:23,840
passes some unit tests, but 
there's still this this gap. 

9
00:00:23,920 --> 00:00:25,760
It's not actually out there with
users. 

10
00:00:25,840 --> 00:00:28,320
Exactly. 
CI often leaves the code, well, 

11
00:00:28,680 --> 00:00:31,640
in a kind of limbo. 
It's technically OK, maybe, but 

12
00:00:31,880 --> 00:00:34,680
not fully vetted for production.
Or it's just sitting there 

13
00:00:34,800 --> 00:00:37,520
waiting for someone to manually 
push the big red button. 

14
00:00:37,640 --> 00:00:40,560
In that gap, that space between 
code merged and code live, 

15
00:00:40,920 --> 00:00:42,120
that's what we're diving into 
today. 

16
00:00:42,120 --> 00:00:45,040
We're moving past CI and into 
the deep end with continuous 

17
00:00:45,040 --> 00:00:46,960
deployment. 
Our goal here is to really 

18
00:00:46,960 --> 00:00:49,280
unpack continuous deployment or 
CD. 

19
00:00:49,520 --> 00:00:51,320
What is it? 
How does it radically change 

20
00:00:51,320 --> 00:00:53,200
things? 
And crucially, how is it 

21
00:00:53,200 --> 00:00:54,760
different from continuous 
delivery? 

22
00:00:55,000 --> 00:00:56,560
Because those terms get mixed up
a lot. 

23
00:00:56,920 --> 00:01:00,000
They really do. 
And that core your idea of CD 

24
00:01:00,000 --> 00:01:03,600
is, well, it's pretty radical. 
It's total automation. 

25
00:01:03,760 --> 00:01:07,200
When you commit the CD, you're 
saying every single commit that 

26
00:01:07,200 --> 00:01:10,200
makes it to the main branch and 
passes tests go straight to 

27
00:01:10,200 --> 00:01:14,800
production automatically. 
No human gatekeeper, no final 

28
00:01:14,800 --> 00:01:15,560
sign off. 
Nope. 

29
00:01:15,920 --> 00:01:18,040
Typically within hours, 
sometimes minutes that. 

30
00:01:18,040 --> 00:01:21,760
Kind of speed is. 
It's almost scary. 

31
00:01:22,080 --> 00:01:25,680
It really begs the question, how
can you possibly trust a system 

32
00:01:25,760 --> 00:01:28,440
moving that fast? 
If you take out the manual 

33
00:01:28,440 --> 00:01:30,960
checks, the automation has to be
absolutely bulletproof. 

34
00:01:30,960 --> 00:01:32,680
It does, and that's why the 
workflow is key. 

35
00:01:32,800 --> 00:01:35,480
OK, let's get into that right? 
How does a piece of code 

36
00:01:35,520 --> 00:01:38,200
actually travel from a 
developer's laptop to the 

37
00:01:38,200 --> 00:01:41,080
customer screen in this fully 
automated CD world? 

38
00:01:41,160 --> 00:01:44,480
It's a very structured, 
automated 4 step process. 

39
00:01:44,480 --> 00:01:47,280
It has to be much more rigorous 
than just basic CI. 

40
00:01:47,280 --> 00:01:51,040
Think of it like the automation 
demands complete accountability 

41
00:01:51,040 --> 00:01:53,440
at every single stage. 
OK, walk us through it step by 

42
00:01:53,440 --> 00:01:54,840
step. 
All right, step one is still 

43
00:01:54,840 --> 00:01:57,040
local. 
The developer writes their code,

44
00:01:57,040 --> 00:01:59,080
tests it thoroughly on their own
machine. 

45
00:01:59,160 --> 00:02:01,320
You know, make sure it works 
before it even goes anywhere 

46
00:02:01,320 --> 00:02:02,400
else. 
Standard practice. 

47
00:02:02,640 --> 00:02:06,280
Right then, Step 2, they commit 
the code, the CI server 

48
00:02:06,280 --> 00:02:09,840
immediately picks it up, reruns 
those basic unit tests just like

49
00:02:09,840 --> 00:02:11,880
normal CI. 
OK, still sounds like CI. 

50
00:02:12,560 --> 00:02:15,720
So where does it diverge? 
What makes this a deployment 

51
00:02:15,720 --> 00:02:19,760
pipeline, not just integration? 
The divergent is really in Step 

52
00:02:19,760 --> 00:02:23,480
3, the sheer magnitude of the 
automated validation. 

53
00:02:23,480 --> 00:02:26,600
This is where it gets serious. 
Several times a day the pipeline

54
00:02:26,600 --> 00:02:29,240
grabs commits that pass the 
initial checks and throws a 

55
00:02:29,240 --> 00:02:32,560
whole battery of additional non 
negotiable tests at them. 

56
00:02:32,560 --> 00:02:33,840
What kind of tests are we 
talking about? 

57
00:02:33,920 --> 00:02:37,320
We're talking heavy duty stuff, 
rigorous integration tests, 

58
00:02:37,320 --> 00:02:40,760
making sure different parts work
together, full end to end test 

59
00:02:40,760 --> 00:02:43,920
that simulate real user 
journeys, performance and load 

60
00:02:43,920 --> 00:02:47,360
testing, maybe simulating 
thousands of users or running 

61
00:02:47,360 --> 00:02:49,640
against a production like 
staging environment. 

62
00:02:49,640 --> 00:02:52,960
So it's not just does the code 
work in isolation, it's does it 

63
00:02:52,960 --> 00:02:54,640
work under pressure with 
everything else. 

64
00:02:54,640 --> 00:02:57,240
Exactly. 
It's testing against a simulated

65
00:02:57,240 --> 00:02:59,400
reality. 
The system has to earn its trust

66
00:02:59,400 --> 00:03:01,920
through this intense validation.
OK, makes sense. 

67
00:03:02,040 --> 00:03:06,600
And then Step 4 is the payoff if
and only if all those 

68
00:03:06,600 --> 00:03:09,800
comprehensive tests pass. 
Only if everything is green. 

69
00:03:10,120 --> 00:03:12,000
Then the commits are 
automatically deployed into 

70
00:03:12,000 --> 00:03:14,520
production. 
Customers get access almost 

71
00:03:14,520 --> 00:03:18,440
immediately, and crucially this 
usually includes things like 

72
00:03:18,720 --> 00:03:22,000
automated production health 
checks, 0 downtime deployment 

73
00:03:22,000 --> 00:03:25,440
strategies, and importantly, 
automatic rollback capabilities 

74
00:03:25,440 --> 00:03:27,320
if anything looks off post 
deployment. 

75
00:03:27,720 --> 00:03:30,800
So there are safety Nets built 
into the automation. 

76
00:03:30,840 --> 00:03:32,800
Absolutely. 
That's how you build trust in a 

77
00:03:32,800 --> 00:03:35,240
system like this. 
OK, so assuming you have this 

78
00:03:35,240 --> 00:03:40,520
incredibly robust, trustworthy 
automation, what's the big win? 

79
00:03:40,800 --> 00:03:43,000
What is this actually by the 
organization? 

80
00:03:43,000 --> 00:03:45,800
Let's talk advantages like the 
feature funnel idea. 

81
00:03:46,040 --> 00:03:49,240
Right, the traditional way is 
often batching features, right? 

82
00:03:49,400 --> 00:03:53,000
You wait for feature F1F2F3 and 
maybe all the way to F and then 

83
00:03:53,000 --> 00:03:55,720
do one big risky, stressful 
release. 

84
00:03:55,720 --> 00:03:57,240
We've all lived through those 
weekends. 

85
00:03:57,280 --> 00:04:00,000
Oh yeah, continuous deployment 
flips that entirely. 

86
00:04:00,320 --> 00:04:02,920
Features don't get batched, they
get released the moment they are

87
00:04:02,920 --> 00:04:06,040
ready and pass the test. 
More releases, but smaller ones.

88
00:04:06,280 --> 00:04:09,000
Exactly. 
Way more frequent releases, but 

89
00:04:09,000 --> 00:04:11,040
each one contains far fewer 
changes. 

90
00:04:11,640 --> 00:04:14,880
This dramatically reduces the 
time between a feature being 

91
00:04:14,880 --> 00:04:17,360
done and a customer actually 
using it. 

92
00:04:17,360 --> 00:04:21,320
And that ties into making 
releases boring, right? 

93
00:04:21,360 --> 00:04:24,240
And not event it gets rid of 
that huge deadline pressure. 

94
00:04:24,240 --> 00:04:27,080
Precisely. 
Those big release deadlines are 

95
00:04:27,080 --> 00:04:30,800
a massive source of stress. 
Missing 1 can push a critical 

96
00:04:30,800 --> 00:04:33,080
feature back by weeks, even 
months. 

97
00:04:33,560 --> 00:04:36,720
CD basically eliminates that 
specific type of deadline 

98
00:04:36,720 --> 00:04:38,480
pressure. 
The code goes out when it's 

99
00:04:38,480 --> 00:04:39,480
ready. 
Period. 

100
00:04:39,560 --> 00:04:41,600
That must be huge for developer 
morale too. 

101
00:04:41,720 --> 00:04:43,880
It really is. 
Imagine you finish a piece of 

102
00:04:43,880 --> 00:04:47,560
work and within hours, 
potentially real customers are 

103
00:04:47,560 --> 00:04:49,080
using it. 
You're not just coding into a 

104
00:04:49,080 --> 00:04:51,680
void for months on end. 
You get that feedback loop 

105
00:04:51,680 --> 00:04:53,800
incredibly quickly. 
Yeah, that immediate connection 

106
00:04:53,800 --> 00:04:56,840
to impact must be powerful. 
Definitely, and it fuels another

107
00:04:56,840 --> 00:05:00,280
big advantage, data-driven 
development and experimentation.

108
00:05:00,520 --> 00:05:03,000
When you can deploy small 
changes so quickly, you can 

109
00:05:03,000 --> 00:05:05,240
start treating deployment as a 
learning opportunity. 

110
00:05:05,280 --> 00:05:07,280
How so? 
Like AB testing. 

111
00:05:07,480 --> 00:05:10,400
Exactly like AB testing or using
feature flags. 

112
00:05:10,720 --> 00:05:13,320
You don't have to launch a big 
new feature to everyone at once.

113
00:05:13,480 --> 00:05:16,760
You can deploy it behind a flag,
turn it on for maybe 1% of 

114
00:05:16,760 --> 00:05:18,360
users. 
See how they react. 

115
00:05:18,520 --> 00:05:21,640
Collect real world data. 
And then decide whether to roll 

116
00:05:21,640 --> 00:05:25,240
it out further, tweak it, or 
even scrap it based on actual 

117
00:05:25,240 --> 00:05:27,240
usage, not just guesswork. 
Precisely. 

118
00:05:27,360 --> 00:05:30,320
Deployment becomes part of the 
product discovery process, not 

119
00:05:30,320 --> 00:05:32,800
just the endpoint you ship to 
learn. 

120
00:05:33,000 --> 00:05:35,400
OK, this all sounds great 
philosophically, but let's 

121
00:05:35,400 --> 00:05:37,640
ground it. 
Our sources mentioned some 

122
00:05:37,640 --> 00:05:41,400
concrete data from Facebook back
in 2016, a place known for 

123
00:05:41,400 --> 00:05:44,560
massive scale CD. 
It really shows how small these 

124
00:05:44,560 --> 00:05:46,560
changes need to be. 
Yeah, that data is pretty eye 

125
00:05:46,600 --> 00:05:47,800
opening. 
It really highlights the 

126
00:05:47,800 --> 00:05:50,400
discipline required. 
On average at Facebook then, 

127
00:05:50,400 --> 00:05:53,480
each developer was deploying 
about 3.5 updates into 

128
00:05:53,480 --> 00:05:56,560
production per week. 3 1/2 * a 
week per developer. 

129
00:05:56,600 --> 00:05:57,880
Wow. 
And the size. 

130
00:05:58,120 --> 00:06:01,080
This is the kicker. 
Those updates added or modified 

131
00:06:01,120 --> 00:06:04,640
on average only 92 lines of 
code. 92 lines. 

132
00:06:04,680 --> 00:06:06,120
That's tiny. 
Almost nothing. 

133
00:06:06,320 --> 00:06:09,240
It's incredibly small. 
It means developers just cannot 

134
00:06:09,240 --> 00:06:12,640
work on huge, sprawling changes 
that touch everything. 

135
00:06:12,960 --> 00:06:15,440
The whole model relies on atomic
commits. 

136
00:06:15,880 --> 00:06:18,200
So what's the skill shift there?
What is that demand from 

137
00:06:18,200 --> 00:06:20,640
engineers? 
It demands a very specific 

138
00:06:20,640 --> 00:06:25,080
skill, the ability to break down
complex problems, even big new 

139
00:06:25,080 --> 00:06:28,640
features, into tiny, 
independent, safely deployable 

140
00:06:28,640 --> 00:06:31,680
chunks. 
Each chunk has to be testable on

141
00:06:31,680 --> 00:06:33,960
its own and releasable on its 
own. 

142
00:06:34,160 --> 00:06:37,120
Because if you have a massive 
pull request touching thousands 

143
00:06:37,120 --> 00:06:39,880
of lines. 
The automated pipeline grinds to

144
00:06:39,880 --> 00:06:43,480
a halt, the risk skyrockets, and
the whole CD advantage just 

145
00:06:43,480 --> 00:06:46,000
evaporates. 
It forces an architecture and a 

146
00:06:46,000 --> 00:06:49,080
mindset focused on small, 
incremental steps. 

147
00:06:49,320 --> 00:06:51,640
Right, it sounds like it really 
favors architectures designed 

148
00:06:51,640 --> 00:06:54,160
for isolation and independent 
deployment, like micro services 

149
00:06:54,160 --> 00:06:55,960
maybe. 
It certainly aligns very well 

150
00:06:55,960 --> 00:06:58,480
with those kinds of 
architectures, yes, but the core

151
00:06:58,480 --> 00:07:01,400
principle is decomposition, 
regardless of the specific 

152
00:07:01,400 --> 00:07:03,760
architecture. 
Even and large refactorings have

153
00:07:03,760 --> 00:07:06,760
to be done incrementally, often 
using techniques like parallel 

154
00:07:06,760 --> 00:07:09,320
runs or feature flags to avoid 
breaking anything. 

155
00:07:09,320 --> 00:07:11,040
So discipline and decomposition 
are key. 

156
00:07:11,040 --> 00:07:14,080
Absolutely fundamental. 
OK, this makes a ton of sense 

157
00:07:14,080 --> 00:07:18,800
for say a web application or a 
back end service where updates 

158
00:07:18,800 --> 00:07:22,720
can happen behind the scenes 
transparently to the user. 

159
00:07:23,200 --> 00:07:27,000
But it can't be the right answer
for everything, can it? 

160
00:07:27,000 --> 00:07:29,120
No, definitely not. 
And that's where we need to draw

161
00:07:29,120 --> 00:07:31,920
that crucial distinction we 
mentioned earlier, continuous 

162
00:07:31,920 --> 00:07:34,880
deployment. 
This fully automated model isn't

163
00:07:34,880 --> 00:07:38,000
really suitable for certain 
types of systems because the 

164
00:07:38,000 --> 00:07:40,920
update process itself isn't 
transparent or server 

165
00:07:40,920 --> 00:07:42,760
controlled. 
Think about desktop 

166
00:07:42,760 --> 00:07:47,840
applications, your IDE maybe, or
a web browser or embedded 

167
00:07:47,840 --> 00:07:50,000
software like firmware for your 
printer. 

168
00:07:50,080 --> 00:07:52,480
Things you actually have to 
install on your local machine. 

169
00:07:52,480 --> 00:07:56,000
Exactly. 
These rely on client resources, 

170
00:07:56,000 --> 00:07:57,960
user permissions. 
You can't just push an update 

171
00:07:57,960 --> 00:08:00,720
silently from a server. 
The user usually has to actively

172
00:08:00,720 --> 00:08:04,000
download and install it, and 
users frankly don't want 

173
00:08:04,000 --> 00:08:06,640
mandatory installs popping up 
multiple times a day. 

174
00:08:06,640 --> 00:08:07,960
Yeah, that would be incredibly 
annoying. 

175
00:08:07,960 --> 00:08:11,560
So for those kinds of systems 
where there's a manual client 

176
00:08:11,560 --> 00:08:14,040
sidestep involved, what's the 
alternative? 

177
00:08:14,120 --> 00:08:16,440
The alternative, and the term 
that often gets confused with 

178
00:08:16,440 --> 00:08:19,960
CD, is Continuous delivery. 
We sometimes call it CDEL for 

179
00:08:19,960 --> 00:08:21,000
short. 
OK. 

180
00:08:21,000 --> 00:08:23,320
Continuous delivery. 
How is it different? 

181
00:08:23,880 --> 00:08:26,760
The core idea is smaller in the 
preparation phase. 

182
00:08:27,040 --> 00:08:30,680
With continuous delivery, every 
code push is still automatically

183
00:08:30,680 --> 00:08:33,480
built, tested, and prepared for 
immediate deployment. 

184
00:08:34,120 --> 00:08:36,799
The delivery part is still 
continuous and automated. 

185
00:08:37,080 --> 00:08:39,520
The code is ready to go at any 
time. 

186
00:08:40,240 --> 00:08:42,919
OK, so the automation handles 
everything up to the release. 

187
00:08:42,919 --> 00:08:45,640
Precisely. 
The crucial difference is that 

188
00:08:45,640 --> 00:08:48,720
final step, the actual 
deployment to production, 

189
00:08:48,720 --> 00:08:53,680
requires manual authorization. 
Someone, an external authority, 

190
00:08:53,680 --> 00:08:56,360
has to give the green light. 
Who's that authority typically? 

191
00:08:56,360 --> 00:08:59,200
Could be a project manager, 
could be someone in marketing, 

192
00:08:59,200 --> 00:09:00,800
maybe a dedicated release 
manager. 

193
00:09:01,000 --> 00:09:03,800
It depends on the organization. 
The point is, the code is 

194
00:09:03,800 --> 00:09:07,480
technically ready, verified, 
probably sitting in a staging 

195
00:09:07,480 --> 00:09:10,400
environment, but a human makes 
the call on when to push it 

196
00:09:10,400 --> 00:09:12,560
live. 
And why hold back if the code is

197
00:09:12,560 --> 00:09:14,320
ready and tested? 
What drives that manual 

198
00:09:14,320 --> 00:09:15,200
decision? 
It's. 

199
00:09:15,200 --> 00:09:18,640
Usually business or strategic 
reasons, not technical ones. 

200
00:09:19,080 --> 00:09:21,680
Marketing campaigns, maybe 
coordinating with a big 

201
00:09:21,680 --> 00:09:25,520
announcement or a trade show, 
perhaps seasonal timing or other

202
00:09:25,520 --> 00:09:29,680
corporate strategic initiatives.
They want to control the exact 

203
00:09:29,680 --> 00:09:32,640
moment the feature becomes 
available, even if engineering 

204
00:09:32,640 --> 00:09:34,360
finished it weeks ago. 
Got it. 

205
00:09:34,360 --> 00:09:37,960
So the when is driven by 
strategy, not just readiness. 

206
00:09:37,960 --> 00:09:40,600
Exactly. 
OK, so let's really nail down 

207
00:09:40,600 --> 00:09:43,600
these definitions then. 
It sounds like they hinge on the

208
00:09:43,600 --> 00:09:46,320
difference between getting ready
and actually releasing. 

209
00:09:46,400 --> 00:09:49,160
That's a great way to put it. 
The source material defines it 

210
00:09:49,160 --> 00:09:51,680
clearly. 
Deployment is the actual act of 

211
00:09:51,680 --> 00:09:54,280
releasing new software versions 
to customers. 

212
00:09:54,360 --> 00:09:57,280
Putting it out there, right? 
Whereas delivery is the process 

213
00:09:57,280 --> 00:09:59,800
of preparing those new patients 
for potential deployment, 

214
00:09:59,920 --> 00:10:02,320
getting them ready, fully 
tested, lined up on the 

215
00:10:02,320 --> 00:10:05,440
launchpad. 
OK, so summarizing in continuous

216
00:10:05,440 --> 00:10:09,000
deployment CD, both the 
preparation delivery and the 

217
00:10:09,000 --> 00:10:13,480
release deployment are automatic
and continuous full end to end 

218
00:10:13,480 --> 00:10:16,240
automation. 
Correct, it's a completely hands

219
00:10:16,240 --> 00:10:18,240
off pipeline once the code is 
committed. 

220
00:10:18,400 --> 00:10:22,400
Whereas in continuous delivery 
sidelo, the preparation delivery

221
00:10:22,800 --> 00:10:26,160
is frequent and automated, 
ensuring the code is always 

222
00:10:26,160 --> 00:10:29,680
release ready, but the final 
deployment step requires that 

223
00:10:29,680 --> 00:10:33,000
explicit manual go ahead. 
That's the key difference, the 

224
00:10:33,000 --> 00:10:35,800
human authorization for the 
final release. 

225
00:10:36,280 --> 00:10:39,480
It seems like regardless of 
whether a company fully embraces

226
00:10:39,480 --> 00:10:43,720
CD or OPS for C Dell, the 
overall trend is clear, isn't 

227
00:10:43,720 --> 00:10:45,480
it? 
Everyone is trying to shorten 

228
00:10:45,480 --> 00:10:47,240
those release cycles. 
Absolutely. 

229
00:10:47,240 --> 00:10:50,240
Whether it's fully automated 
deployment or just continuously 

230
00:10:50,240 --> 00:10:53,040
delivering release candidates, 
the whole industry is moving 

231
00:10:53,040 --> 00:10:55,360
towards faster, more frequent 
releases. 

232
00:10:55,800 --> 00:10:59,000
It's about staying competitive, 
getting feedback faster, keeping

233
00:10:59,000 --> 00:11:02,080
users engaged, and frankly, 
keeping development teams 

234
00:11:02,080 --> 00:11:04,640
motivated. 
Yeah, the days of the massive 

235
00:11:04,640 --> 00:11:07,640
once a year release seem 
numbered for most software. 

236
00:11:07,640 --> 00:11:10,440
Definitely, the pressure for 
speed and responsiveness is just

237
00:11:10,440 --> 00:11:13,080
too high. 
So the big take away here, maybe

238
00:11:13,080 --> 00:11:15,880
the thing to really chew on 
isn't just about the tools or 

239
00:11:15,880 --> 00:11:18,960
the automation pipelines. 
It's how adopting something like

240
00:11:18,960 --> 00:11:22,080
continuous deployment forces a 
fundamental shift in 

241
00:11:22,080 --> 00:11:25,520
organizational culture. 
It changes how you think about 

242
00:11:25,520 --> 00:11:29,600
risk, how you handle failure, 
because small failures happen 

243
00:11:29,600 --> 00:11:32,200
more often but are less 
catastrophic, and critically, 

244
00:11:32,640 --> 00:11:34,960
how you train engineers to 
breakdown work. 

245
00:11:35,560 --> 00:11:38,760
Not just features, but the 
smallest possible safest 

246
00:11:38,760 --> 00:11:40,920
component of a feature. 
It really does demand a 

247
00:11:40,920 --> 00:11:43,760
different mindset, a mental 
restructuring almost focused on 

248
00:11:43,760 --> 00:11:46,840
constant incremental progress 
and immediate accountability. 

249
00:11:47,040 --> 00:11:48,680
Constant immediate 
accountability. 

250
00:11:48,680 --> 00:11:51,080
That sums it up well. 
Well, thank you for joining us 

251
00:11:51,080 --> 00:11:54,360
for this deep dive into the 
world of continuous deployment 

252
00:11:54,720 --> 00:11:55,920
and continuous delivery.