1
00:00:00,040 --> 00:00:01,800
If it hurts, do it more often, 
right? 

2
00:00:02,120 --> 00:00:05,320
Continuous deployment is the 
perfect example of applying this

3
00:00:05,360 --> 00:00:08,360
principle and putting it into 
practice, because to me there is

4
00:00:08,360 --> 00:00:11,920
absolutely nothing I can think 
of that is more painful than 

5
00:00:11,920 --> 00:00:13,880
deploying to production for 
things, right. 

6
00:00:14,160 --> 00:00:16,560
So in the past we used to have 
like this manual approval stage 

7
00:00:16,560 --> 00:00:19,480
where, you know, somebody will 
decide when we actually deploy 

8
00:00:19,480 --> 00:00:21,880
to production. 
So tell us why it is very, very 

9
00:00:21,880 --> 00:00:24,560
important to actually remove 
this last critical piece. 

10
00:00:24,920 --> 00:00:28,240
So to explain why it is 
important, I'm going to connect 

11
00:00:28,240 --> 00:00:30,720
to the practice of Lean manual 
factory, right? 

12
00:00:31,120 --> 00:00:33,760
And you also got Dave Farley to 
write the forward of the book. 

13
00:00:33,760 --> 00:00:36,240
Write one of the co-authors of 
the You Know Seminole book 

14
00:00:36,240 --> 00:00:38,880
Continuous Delivery. 
Every single aspect of your work

15
00:00:38,880 --> 00:00:42,320
needs to be thought as a life 
change in a production 

16
00:00:42,320 --> 00:00:44,960
environment. 
So it feels much more like being

17
00:00:44,960 --> 00:00:47,440
an electrician working on an 
office building that is 

18
00:00:47,440 --> 00:00:49,600
currently in use, right? 
Well, I think it's a very nice 

19
00:00:49,600 --> 00:00:51,920
explanation. 
So I think also maybe for some 

20
00:00:51,920 --> 00:00:55,640
people who are still not yet in 
this kind of a working mode, 

21
00:00:55,680 --> 00:00:56,800
right? 
What do you see? 

22
00:00:56,800 --> 00:00:59,520
Some challenges. 
Surprisingly, there's a lot of 

23
00:00:59,520 --> 00:01:02,400
situations where you think you 
might not be able to do it, such

24
00:01:02,400 --> 00:01:05,640
as regulated industries, but in 
reality you're able to. 

25
00:01:06,040 --> 00:01:08,360
Continuous deployment doesn't 
mean that you just deploy 

26
00:01:08,360 --> 00:01:10,560
straight away. 
So tell us what is the minimum 

27
00:01:10,560 --> 00:01:13,840
thing that you should have in a 
continuous deployment and so? 

28
00:01:14,200 --> 00:01:17,960
Basically, there are a certain 
minimum amount of practices that

29
00:01:18,040 --> 00:01:20,120
you should definitely make sure 
that you have. 

30
00:01:35,200 --> 00:01:37,720
Hello everyone, welcome back to 
another new episode of the 

31
00:01:37,720 --> 00:01:40,480
Techni General Podcast. 
Today I have with me a lead 

32
00:01:40,480 --> 00:01:43,600
software developer from Thor 
Works and also the author of a 

33
00:01:43,600 --> 00:01:45,640
book titled Continuous 
Deployment. 

34
00:01:46,080 --> 00:01:49,480
So as you can tell, we are going
to discuss about continuous 

35
00:01:49,480 --> 00:01:51,400
deployment. 
How does it differ from, you 

36
00:01:51,400 --> 00:01:53,880
know what we know, CICD 
continuous integration, 

37
00:01:53,880 --> 00:01:56,720
continuous delivery. 
And yeah, happy to have you, 

38
00:01:56,720 --> 00:02:00,080
Valentina, in the show. 
Hi Henry, happy to be here. 

39
00:02:00,600 --> 00:02:03,960
Right, Valentina, maybe before 
we go dive deep into continuous 

40
00:02:03,960 --> 00:02:06,880
deployment and all that, maybe 
let's talk a little bit more 

41
00:02:06,880 --> 00:02:08,440
about yourself. 
Maybe if you can share any 

42
00:02:08,440 --> 00:02:10,840
career turning points that you 
think we can learn from you. 

43
00:02:11,640 --> 00:02:14,760
So well, you already gave a bit 
of an introduction. 

44
00:02:14,960 --> 00:02:18,240
As you said, my name is 
Valentina Servila and I am 

45
00:02:18,240 --> 00:02:21,960
currently at Teched at Dotworks.
I'm Italian, as you can tell 

46
00:02:22,040 --> 00:02:25,480
from my accent, but I'm actually
working in total Spain. 

47
00:02:25,880 --> 00:02:27,760
But I did start my career in 
Italy. 

48
00:02:27,760 --> 00:02:32,520
So basically I began by joining 
a very small agile consultancy. 

49
00:02:33,080 --> 00:02:36,960
That was my very first job and I
had a very amazing training. 

50
00:02:36,960 --> 00:02:40,120
So all of the juniors that 
joined this consultancy 

51
00:02:40,120 --> 00:02:42,360
basically were told to study for
three months. 

52
00:02:42,680 --> 00:02:46,600
As soon as I began on my first 
day, I got told to read the 

53
00:02:46,600 --> 00:02:49,840
Agile Manifesto, which is 
something that I still really 

54
00:02:49,840 --> 00:02:52,640
believe in, you know, all of the
agile principles and eventually 

55
00:02:52,640 --> 00:02:55,240
led to me writing a book about 
one of those. 

56
00:02:55,560 --> 00:02:58,800
So yeah, maybe this is a very 
good reminder to know, pay 

57
00:02:58,800 --> 00:03:01,720
attention to how you're training
your juniors because it really 

58
00:03:01,720 --> 00:03:04,240
does pay off. 
I think if I can use my 

59
00:03:04,240 --> 00:03:08,000
examples, three years later I 
joined the ThoughtWorks in Spain

60
00:03:08,000 --> 00:03:10,760
and I started working with much 
bigger companies. 

61
00:03:11,440 --> 00:03:16,120
I started working with more 
enterprise type clients and you 

62
00:03:16,120 --> 00:03:19,200
know, being a consultant in both
occasions I was able to jump 

63
00:03:19,200 --> 00:03:23,400
from client to client to client 
and see a wide variety of ways 

64
00:03:23,400 --> 00:03:26,200
of working of different team 
compositions, of different 

65
00:03:26,200 --> 00:03:28,640
practices. 
And I think that gave me a 

66
00:03:28,640 --> 00:03:32,520
really good perspective on all 
of the technical practices that 

67
00:03:32,520 --> 00:03:35,960
teams can adopt to be successful
or not to be successful. 

68
00:03:36,360 --> 00:03:40,640
I also in between that managed 
to go on a long term assignment 

69
00:03:40,640 --> 00:03:42,800
in Asia. 
So I was stationed in Bangkok 

70
00:03:42,800 --> 00:03:46,400
for about a couple of years. 
And so it was really nice as 

71
00:03:46,400 --> 00:03:49,720
well to see perspectives of how 
organisations work on the other 

72
00:03:49,720 --> 00:03:53,160
side of the world in my case. 
But yeah, now I am back in 

73
00:03:53,160 --> 00:03:56,400
Spain. 
I was back in Spain for a while.

74
00:03:56,400 --> 00:03:59,480
Now I wrote this book and let's 
see what's next. 

75
00:04:00,480 --> 00:04:04,320
This episode is brought to you 
by Swim dot IO and I'm excited 

76
00:04:04,320 --> 00:04:08,640
to have its CTO and Co founder 
Omar Rosenbaum with me today to 

77
00:04:08,640 --> 00:04:11,560
tell you more about Swim. 
Hi Henry, very nice to meet you 

78
00:04:11,560 --> 00:04:14,240
and thank you for having me. 
So tell us a little bit more, 

79
00:04:14,240 --> 00:04:17,560
what is swim dot IO? 
At Swim, we want to help 

80
00:04:17,720 --> 00:04:20,160
companies understand their code 
bases. 

81
00:04:20,240 --> 00:04:24,640
We combine static code analysis 
with generative AI to create 

82
00:04:24,640 --> 00:04:28,400
comprehensive documents that 
help you navigate the code base.

83
00:04:28,520 --> 00:04:31,120
As an engineer myself, I 
wouldn't want 10 years to spend 

84
00:04:31,120 --> 00:04:34,440
so much time understanding 
existing code. 

85
00:04:34,480 --> 00:04:38,000
I would want them to spend time 
creating and building new stuff.

86
00:04:38,360 --> 00:04:42,400
When you have code that has 
accumulated over decades, and 

87
00:04:42,400 --> 00:04:48,120
especially in legacy languages 
that not many people are adapted

88
00:04:48,200 --> 00:04:50,800
nowadays, then the problem is 
even bigger. 

89
00:04:51,200 --> 00:04:55,200
Swim dot IO is specializing into
helping mainframe developers to 

90
00:04:55,200 --> 00:04:57,160
understand their copies. 
Why mainframes? 

91
00:04:57,200 --> 00:05:01,800
We actually didn't start there. 
COBOL had been by some people 

92
00:05:01,880 --> 00:05:07,320
obsolete for a few years, and I 
discovered that it's not really 

93
00:05:07,320 --> 00:05:10,160
obsolete, not at all. 
There are more than 800 billion 

94
00:05:10,160 --> 00:05:14,000
lines of COBOL code that are in 
production and they drive lots 

95
00:05:14,000 --> 00:05:18,720
of the business in the world and
we got more and more requests. 

96
00:05:18,920 --> 00:05:21,760
From. 
Customers to help them 

97
00:05:21,760 --> 00:05:24,000
understand the legacy code 
business that was written 

98
00:05:24,000 --> 00:05:27,920
decades ago and get accumulated 
over a very long period of time.

99
00:05:28,080 --> 00:05:31,440
So from your customers so far, 
what are the some of the success

100
00:05:31,440 --> 00:05:34,880
stories that you can share? 
So we worked with an analyst who

101
00:05:35,120 --> 00:05:39,520
shared with us that it took them
a year to document a single 

102
00:05:39,520 --> 00:05:42,760
mainframe application, and using
SWIM they were able to document 

103
00:05:42,760 --> 00:05:45,360
a similar application in a 
matter of hours. 

104
00:05:45,840 --> 00:05:49,720
So saving that amount of time 
enables them to focus on other 

105
00:05:49,960 --> 00:05:52,840
tasks. 
Thanks Amir for sharing with us 

106
00:05:52,840 --> 00:05:55,600
about SWIM today. 
To learn more about SWIM, check 

107
00:05:55,600 --> 00:05:57,680
out their website at swim dot 
IO. 

108
00:05:59,760 --> 00:06:01,440
Wow, thank you for sharing your 
story. 

109
00:06:01,440 --> 00:06:03,760
I think one thing that you 
mentioned earlier, right? 

110
00:06:03,760 --> 00:06:06,920
So train your juniors. 
Well, I think maybe not all 

111
00:06:06,920 --> 00:06:10,320
juniors are fortunate enough to 
have this kind of good training,

112
00:06:10,440 --> 00:06:13,000
good principles being taught 
since the very early of their 

113
00:06:13,000 --> 00:06:15,040
career. 
So maybe for those who are maybe

114
00:06:15,040 --> 00:06:17,920
not so fortunate like you or 
maybe some of us. 

115
00:06:18,320 --> 00:06:21,120
So what advice would you give to
them such that even though they 

116
00:06:21,120 --> 00:06:24,240
don't get the good training from
the company or from the seniors 

117
00:06:24,240 --> 00:06:28,200
they work with, how can they 
still learn a good principles at

118
00:06:28,200 --> 00:06:31,720
the start of their career? 
I'm going to say, well, first of

119
00:06:31,720 --> 00:06:35,440
all, try to look at the 
literature because that has been

120
00:06:35,600 --> 00:06:38,560
really, really helpful for me. 
You know, in terms of good 

121
00:06:38,560 --> 00:06:42,320
practices, in terms of how to be
a better programmer. 

122
00:06:42,320 --> 00:06:44,360
The literature has so much 
insight. 

123
00:06:44,360 --> 00:06:47,000
Even if you cannot get it from 
your seniors or from your 

124
00:06:47,000 --> 00:06:49,640
mentors, you can always fall 
back to that. 

125
00:06:50,240 --> 00:06:52,880
Just don't be afraid to ask 
questions and be annoying, you 

126
00:06:52,880 --> 00:06:56,760
know, try to be the one with the
keyboard when you're pair 

127
00:06:56,760 --> 00:07:00,160
programming, for example. 
Yes, it will be a bit slower. 

128
00:07:00,160 --> 00:07:03,040
Yes, you will have more 
questions than someone else 

129
00:07:03,040 --> 00:07:05,120
would and hit more blockers than
someone else would. 

130
00:07:05,120 --> 00:07:08,600
But make the best of your 
mentors being there and don't be

131
00:07:08,600 --> 00:07:11,320
afraid to annoy them because 
that's the only way that you get

132
00:07:11,320 --> 00:07:12,920
to learn, you know, being hands 
on. 

133
00:07:13,800 --> 00:07:15,480
I like your term be the 
keyboard, right. 

134
00:07:15,480 --> 00:07:19,000
So sometimes we may not be 
comfortable asking questions to 

135
00:07:19,000 --> 00:07:22,200
senior and become like, I don't 
know, some people think they 

136
00:07:22,200 --> 00:07:24,280
might be a hindrance to the 
discussion and all that. 

137
00:07:24,280 --> 00:07:26,760
But I think, yeah, beginner's 
mind, I think that's always a 

138
00:07:26,760 --> 00:07:29,480
very good skills to have in any 
kind of team. 

139
00:07:29,640 --> 00:07:33,160
Yeah, I was going to say, and it
definitely helps the team as 

140
00:07:33,160 --> 00:07:35,280
well. 
You know, you might think that 

141
00:07:35,280 --> 00:07:37,680
you're annoying everyone by 
asking questions, but a lot of 

142
00:07:37,680 --> 00:07:40,720
times it actually uncovers 
something more to the 

143
00:07:40,720 --> 00:07:43,880
discussion, even what might be a
really obvious question. 

144
00:07:43,880 --> 00:07:47,400
So yeah, definitely don't feel 
like an annoyance. 

145
00:07:47,400 --> 00:07:50,000
What you're bringing is really, 
really valuable, which is a 

146
00:07:50,000 --> 00:07:52,920
fresh perspective. 
Right, I think that's really 

147
00:07:52,920 --> 00:07:55,400
great tips, right? 
So for all the beginners, even 

148
00:07:55,400 --> 00:07:58,000
maybe for seniors, right, 
Sometimes don't be afraid to ask

149
00:07:58,000 --> 00:08:01,960
like so-called stupid questions.
So let's go dive into your book,

150
00:08:01,960 --> 00:08:03,200
right? 
Continuous deployment. 

151
00:08:03,200 --> 00:08:05,240
For me, it's almost like 
natural. 

152
00:08:05,240 --> 00:08:07,800
One day somebody will write 
about this continuous 

153
00:08:07,800 --> 00:08:11,200
deployment, even though you 
know, like CICD has been, you 

154
00:08:11,200 --> 00:08:13,400
know, around for, I don't know, 
more than a decade, I guess. 

155
00:08:13,480 --> 00:08:16,560
So maybe in the 1st place. 
Tell us your story, the 

156
00:08:16,560 --> 00:08:19,560
background, What inspired you to
actually write this book? 

157
00:08:20,480 --> 00:08:22,640
Yeah, And actually I brought the
book. 

158
00:08:22,640 --> 00:08:25,320
It's right here, continues 
deployment. 

159
00:08:25,320 --> 00:08:27,840
You can get the physical copy on
Amazon, of course. 

160
00:08:28,120 --> 00:08:31,440
So what inspired me to write it,
basically, as you said, it 

161
00:08:31,440 --> 00:08:35,200
sounded like a really obvious 
gap in the literature that 

162
00:08:35,200 --> 00:08:38,159
somehow was missing. 
I don't know how nobody had 

163
00:08:38,159 --> 00:08:41,480
thought about writing this book 
yet, but it's definitely a gap 

164
00:08:41,480 --> 00:08:45,960
that I felt when I was working 
because being a consultant, I 

165
00:08:45,960 --> 00:08:49,960
was really lucky to be part of 
some teams at some clients that 

166
00:08:49,960 --> 00:08:51,800
were already doing continuous 
deployment. 

167
00:08:51,800 --> 00:08:55,080
They were doing it for many, 
many years, but sometimes we 

168
00:08:55,080 --> 00:08:58,680
were on boarding more junior 
people or consultants that 

169
00:08:58,680 --> 00:09:02,040
didn't have this experience. 
And even when they were really 

170
00:09:02,040 --> 00:09:04,800
familiar with other great 
practices like continuous 

171
00:09:04,800 --> 00:09:08,320
delivery, continuous integration
develops, there was still a bit 

172
00:09:08,320 --> 00:09:11,800
of a learning curve. 
So I found myself basically in a

173
00:09:11,800 --> 00:09:15,640
situation where I wanted to 
communicate what is the 

174
00:09:15,640 --> 00:09:19,360
difference between stopping your
commits at staging and every 

175
00:09:19,360 --> 00:09:22,040
commit going to prod. 
And it turns out there was quite

176
00:09:22,040 --> 00:09:25,600
a lot to communicate about it. 
And I had basically no 

177
00:09:25,600 --> 00:09:28,920
literature that I could just 
send them or articles that I 

178
00:09:28,920 --> 00:09:32,320
could just send them to, you 
know, just read up about it and 

179
00:09:32,320 --> 00:09:35,440
be ready the next day. 
And so, yeah, based on the 

180
00:09:35,720 --> 00:09:38,680
missing this kind of content, I 
decided to create it. 

181
00:09:38,680 --> 00:09:42,520
So I started the by writing some
blog posts and doing some talks 

182
00:09:42,520 --> 00:09:45,680
about the subject. 
And yeah, then it got picked up 

183
00:09:45,680 --> 00:09:50,240
by Riley and here it is up. 
So hopefully this will help 

184
00:09:50,240 --> 00:09:53,120
other people who have been in my
situations, for example, in 

185
00:09:53,120 --> 00:09:55,800
teams that are already 
practicing continuous deployment

186
00:09:55,800 --> 00:09:58,080
and you want to ember someone 
else or if you're one of the 

187
00:09:58,080 --> 00:10:01,800
people joining such a team. 
So this is a pretty condensed 

188
00:10:01,800 --> 00:10:06,000
version, even though it's 400 
pages long, of everything that 

189
00:10:06,000 --> 00:10:07,840
you might ever need to know 
about it. 

190
00:10:08,680 --> 00:10:11,400
Yeah, and he also got Dave 
Farley to write the forward of 

191
00:10:11,400 --> 00:10:14,000
the book, right, one of the 
co-authors of the, you know, I 

192
00:10:14,000 --> 00:10:16,080
would say Seminole book 
continuous delivery, right. 

193
00:10:16,400 --> 00:10:19,080
So I think maybe let's start 
from there, right? 

194
00:10:19,080 --> 00:10:22,320
The definition it's always very 
confusing when we talk about, 

195
00:10:22,320 --> 00:10:24,680
you know, CICD in the industry, 
right? 

196
00:10:24,680 --> 00:10:27,400
Some people even already 
associate CD with continuous 

197
00:10:27,400 --> 00:10:29,680
deployment. 
I guess maybe a little bit off 

198
00:10:29,680 --> 00:10:33,200
back to the fundamentals, if you
can elaborate what as continuous

199
00:10:33,200 --> 00:10:35,640
integration, continuous delivery
and continuous deployment. 

200
00:10:36,640 --> 00:10:39,680
Thank you. 
So this is a topic where the 

201
00:10:39,680 --> 00:10:43,840
terminology has undergone a lot 
of semantic diffusion, as Martin

202
00:10:43,840 --> 00:10:46,760
Fowler calls it. 
And a lot of people in the 

203
00:10:46,760 --> 00:10:52,880
industry refer to CI and or CD 
as the pipeline, effectively 

204
00:10:53,240 --> 00:10:56,080
forgetting that in reality all 
of these things started as 

205
00:10:56,080 --> 00:10:58,400
practices. 
So the pipeline is just an 

206
00:10:58,400 --> 00:11:02,560
artefact that helps you realise 
the practice, but there is quite

207
00:11:02,560 --> 00:11:05,320
a lot more to it. 
So starting with some 

208
00:11:05,320 --> 00:11:09,360
definitions, the first practice 
that came along was continuous 

209
00:11:09,360 --> 00:11:11,520
integration as part of extreme 
programming. 

210
00:11:11,880 --> 00:11:15,960
So the practice behind that 
outside of the pipeline tool was

211
00:11:15,960 --> 00:11:19,560
basically the act of integrating
your changes into a mainline 

212
00:11:19,560 --> 00:11:21,480
shared branch really, really 
frequently. 

213
00:11:22,040 --> 00:11:26,720
This had the purpose of always 
having all of the changes 

214
00:11:26,760 --> 00:11:30,680
bundled into a buildable 
artefact that could be validated

215
00:11:30,680 --> 00:11:33,840
by tests for example, and so 
that the team could always show 

216
00:11:33,840 --> 00:11:36,400
their progress. 
So it came with the practices 

217
00:11:36,400 --> 00:11:40,120
such as nobody pushes in a 
broken build, we have to 

218
00:11:40,120 --> 00:11:43,600
integrate changes frequently, 
not hold changes in really long 

219
00:11:43,600 --> 00:11:46,400
lived feature branches and so on
and so forth. 

220
00:11:46,840 --> 00:11:51,800
Then the pipeline, which is how 
implementation looks like or can

221
00:11:51,800 --> 00:11:54,480
look like of continuous 
integration, takes care of 

222
00:11:54,480 --> 00:11:57,640
taking this mainline branch, 
building an artifact from it and

223
00:11:57,640 --> 00:12:01,240
running some automated tests. 
And that was a really big change

224
00:12:01,240 --> 00:12:04,600
at the time because that wasn't 
a particular way of working that

225
00:12:04,600 --> 00:12:08,240
existed so much before. 
And suddenly it was really, 

226
00:12:08,240 --> 00:12:13,280
really easy to show progress and
say, look, this artefact 

227
00:12:13,720 --> 00:12:16,440
represents what we have been 
working on so far. 

228
00:12:16,800 --> 00:12:20,680
And it is buildable, it is 
testable, and it can be deployed

229
00:12:20,680 --> 00:12:24,520
because it contains every change
that has happened, say in the 

230
00:12:24,520 --> 00:12:28,160
past day or in the past week. 
That made the integration much 

231
00:12:28,160 --> 00:12:30,880
more frequent and introduced the
concept of the pipeline. 

232
00:12:30,880 --> 00:12:35,200
But then continuous delivery 
came along and it brought even 

233
00:12:35,200 --> 00:12:39,880
more to the conversation. 
So continuous delivery added on 

234
00:12:39,880 --> 00:12:43,600
top of continuous integration, 
the fact that not only your 

235
00:12:43,600 --> 00:12:46,680
changes should be frequently 
integrated, frequently tested, 

236
00:12:46,680 --> 00:12:50,240
frequently built, but also 
frequently deployed. 

237
00:12:50,600 --> 00:12:53,960
And every single change that 
goes through the automated 

238
00:12:53,960 --> 00:12:59,120
pipeline should be verified to 
such a greater confidence level 

239
00:12:59,200 --> 00:13:01,880
that should be considered 
deployable to production. 

240
00:13:02,640 --> 00:13:06,280
So basically this was a really 
big mindset shift because then 

241
00:13:06,280 --> 00:13:09,680
it came with other practices, 
say from the BOPS such as 

242
00:13:09,680 --> 00:13:13,360
infrastructure is called and 
automating the deployments 

243
00:13:13,360 --> 00:13:15,680
themselves, which didn't have to
be manual anymore. 

244
00:13:15,880 --> 00:13:18,880
But yeah, it was also a practice
before it was the automated 

245
00:13:18,880 --> 00:13:23,240
pipeline too. 
Then a further next step on top 

246
00:13:23,240 --> 00:13:26,760
of continuous delivery, again to
me and to many other people has 

247
00:13:26,760 --> 00:13:30,760
been continuous deployment. 
Where not only every change that

248
00:13:30,760 --> 00:13:33,760
goes through the pipeline should
be considered the deployment to 

249
00:13:33,760 --> 00:13:37,360
production candidate, but it 
should be actually deployed to 

250
00:13:37,360 --> 00:13:40,640
production. 
So basically this to me was a 

251
00:13:40,640 --> 00:13:43,840
culmination of this concept of 
the automated deployment 

252
00:13:43,840 --> 00:13:48,480
pipeline, where every single 
step between development and 

253
00:13:48,480 --> 00:13:51,120
deployment to production has 
been automated. 

254
00:13:51,680 --> 00:13:53,600
In the traditional 
implementation of continuous 

255
00:13:53,600 --> 00:13:57,400
delivery for example, you might 
see that many many teams deploy 

256
00:13:57,400 --> 00:14:00,720
automatically with their 
pipeline to some pre production 

257
00:14:00,720 --> 00:14:04,720
environments, say diverse aging.
But the deployment to 

258
00:14:04,720 --> 00:14:08,600
production, while it can be done
on demand, is still a manual 

259
00:14:08,600 --> 00:14:10,640
action. 
So it's the push of a button to 

260
00:14:10,640 --> 00:14:13,280
be done only when the team feels
confident enough. 

261
00:14:13,880 --> 00:14:18,160
Let's say continuous deployment 
is pushing that limit away and 

262
00:14:18,160 --> 00:14:22,600
removing that final manual gate 
in the value stream of building 

263
00:14:22,600 --> 00:14:24,160
software and deploying it to 
prod. 

264
00:14:24,560 --> 00:14:29,280
And so, yeah, it is definitely a
combination of a journey that 

265
00:14:29,280 --> 00:14:33,320
has maybe taken I'd say 20 years
since Extreme programming and 

266
00:14:33,320 --> 00:14:36,800
continues integration came along
and is bringing automation all 

267
00:14:36,800 --> 00:14:39,280
the way to the end of the value 
stream. 

268
00:14:40,160 --> 00:14:43,560
I like that you brought up the 
historical aspect of how all 

269
00:14:43,560 --> 00:14:45,360
this combination happened, 
right? 

270
00:14:45,360 --> 00:14:48,360
So from things like extreme 
programming, you know, DevOps, 

271
00:14:48,360 --> 00:14:51,400
Agile and things like that. 
And I like the specific thing 

272
00:14:51,400 --> 00:14:53,680
that you mentioned, right? 
It's not all about pipeline, 

273
00:14:53,680 --> 00:14:55,400
right? 
Because people associate maybe 

274
00:14:55,400 --> 00:14:59,000
CICD with pipeline concept, even
tools like Jenkins, maybe no 

275
00:14:59,000 --> 00:15:00,360
GitHub Actions and things like 
that. 

276
00:15:00,360 --> 00:15:01,840
But it's about the practices, 
right? 

277
00:15:02,040 --> 00:15:04,480
The practices that actually lead
us to use some of the tools that

278
00:15:04,480 --> 00:15:08,040
could help us actually adopt 
those practices, maybe slightly 

279
00:15:08,040 --> 00:15:09,760
a little bit more about 
definition as well. 

280
00:15:09,760 --> 00:15:12,240
People associate CIS less CD, 
right? 

281
00:15:12,240 --> 00:15:14,560
They think they are kind of like
a different thing. 

282
00:15:14,800 --> 00:15:17,600
And now what is the term that 
you're gonna use for continuous 

283
00:15:17,600 --> 00:15:19,760
deployment? 
Is it also the same CD or is 

284
00:15:19,760 --> 00:15:23,800
there any other term? 
Actually, that's not really set 

285
00:15:23,800 --> 00:15:26,280
in stone yet. 
I've been debating it with my 

286
00:15:26,280 --> 00:15:30,440
colleagues, some of them 
abbreviated to C deck just to 

287
00:15:30,440 --> 00:15:32,360
distinguish it from continuous 
delivery. 

288
00:15:32,360 --> 00:15:35,840
So I if you find it helpful, I 
encourage you to continue on 

289
00:15:35,840 --> 00:15:37,960
that. 
But yeah, otherwise you can just

290
00:15:37,960 --> 00:15:40,560
spell it out. 
Continuous deployment, just not 

291
00:15:40,560 --> 00:15:43,840
too confusing. 
So I think 1 aspect that is 

292
00:15:43,840 --> 00:15:46,600
very, very important that I 
would like you to also try to 

293
00:15:46,600 --> 00:15:49,120
explain, right? 
This thing in the extreme 

294
00:15:49,120 --> 00:15:51,520
programming, right? 
If it hurts, do it more often, 

295
00:15:51,520 --> 00:15:53,760
right? 
So I think this is maybe one of 

296
00:15:53,760 --> 00:15:57,080
the key reason why continuous 
delivery was kind of like 

297
00:15:57,080 --> 00:15:59,840
invented in the 1st place. 
Maybe tell us why this is 

298
00:15:59,840 --> 00:16:03,360
important for us, especially for
those teams who are still kind 

299
00:16:03,360 --> 00:16:06,400
of like fearful whenever they 
make code changes and they want 

300
00:16:06,400 --> 00:16:10,800
to deploy even to production. 
So I love that principle from 

301
00:16:10,800 --> 00:16:14,200
extreme Programming. 
To me, that is the essence of 

302
00:16:14,200 --> 00:16:18,000
extreme programming and most of 
agile practices themselves to be

303
00:16:18,000 --> 00:16:22,800
honest, is software has many 
more parts to it than just 

304
00:16:22,800 --> 00:16:25,200
writing it. 
There's integration, there's 

305
00:16:25,200 --> 00:16:30,480
testing, there's deployment and 
all of those other parts before 

306
00:16:30,480 --> 00:16:33,520
XP used to be pretty painful. 
So, you know, in an old fashion 

307
00:16:33,520 --> 00:16:37,160
waterfall process, you will 
maybe have your giant 

308
00:16:37,160 --> 00:16:41,680
development phase, then a big 
integration phase, then a BQA 

309
00:16:41,680 --> 00:16:44,400
phase and so on and so forth. 
Now that used to be pretty 

310
00:16:44,400 --> 00:16:47,000
painful because it was done 
infrequently, right? 

311
00:16:47,520 --> 00:16:51,480
So the principle of extreme 
programming basically says if 

312
00:16:51,920 --> 00:16:54,440
something is painful, such as 
these phases of writing 

313
00:16:54,440 --> 00:16:57,920
software, you should do them 
more often because doing them 

314
00:16:57,920 --> 00:17:01,440
more often encourages their 
automation, which is a great 

315
00:17:01,440 --> 00:17:03,800
thing. 
And in and on itself, automation

316
00:17:04,119 --> 00:17:09,000
allows you to first of all 
document and also make a process

317
00:17:09,160 --> 00:17:13,160
which can be replicated. 
It is not relying on someone's 

318
00:17:13,160 --> 00:17:17,440
knowledge on doing things by 
hand, but also more crucially, 

319
00:17:17,560 --> 00:17:20,640
if you do things more often, 
like integrating software, 

320
00:17:20,640 --> 00:17:24,920
testing software, there is less 
software to integrate and test 

321
00:17:24,920 --> 00:17:28,240
and deploy each time. 
So when your batches are 

322
00:17:28,240 --> 00:17:30,640
smaller, and here maybe I'll 
talk later about lean 

323
00:17:30,640 --> 00:17:34,440
manufacturing, suddenly all of 
those phases become much less 

324
00:17:34,440 --> 00:17:37,000
painful. 
And that is why this advice 

325
00:17:37,000 --> 00:17:39,960
seems counterintuitive, but 
actually it allows to feel less 

326
00:17:39,960 --> 00:17:42,240
pain in performing all of those 
phases. 

327
00:17:42,840 --> 00:17:45,720
That said, I believe that 
continuous deployment is the 

328
00:17:45,720 --> 00:17:49,480
perfect example of applying this
principle and putting it into 

329
00:17:49,480 --> 00:17:51,400
practice. 
Because to me, there is 

330
00:17:51,400 --> 00:17:55,320
absolutely nothing I can think 
of that is more painful than 

331
00:17:55,320 --> 00:17:57,480
deploying to production for 
teams, right? 

332
00:17:57,760 --> 00:18:01,640
That is so much more painful 
than resolving some git 

333
00:18:01,640 --> 00:18:05,040
conflicts. 
So during integration or 

334
00:18:05,120 --> 00:18:08,120
spending a lot of time on 
testing, the deployment to 

335
00:18:08,120 --> 00:18:12,040
production is when the website 
can go down, your app might stop

336
00:18:12,040 --> 00:18:15,040
working, you could scrap your 
database. 

337
00:18:15,160 --> 00:18:19,320
So because it is much more scary
and much more painful, that's 

338
00:18:19,640 --> 00:18:22,920
why I recommend to do it as 
often as you can, and in this 

339
00:18:22,920 --> 00:18:24,960
case automatically at every 
commit. 

340
00:18:25,640 --> 00:18:26,760
Yeah. 
So I think in the past, 

341
00:18:26,760 --> 00:18:29,960
traditionally, I also used to 
experience those Big Bang 

342
00:18:29,960 --> 00:18:32,480
release, right, where you kind 
of like have a certain window, 

343
00:18:32,480 --> 00:18:33,920
maybe quarterly, whatever that 
is. 

344
00:18:34,240 --> 00:18:36,680
And you kind of like build a 
ceremony around production 

345
00:18:36,680 --> 00:18:39,320
deployment, right? 
Kind of like fearful whenever 

346
00:18:39,320 --> 00:18:42,760
the new change going to be used 
by the real users and whether 

347
00:18:42,760 --> 00:18:45,560
there's going to be a big impact
or buck happening in the 

348
00:18:45,560 --> 00:18:48,000
production. 
So I think the spirit here, if 

349
00:18:48,000 --> 00:18:50,560
it hurts right, do it more often
so that your production 

350
00:18:50,560 --> 00:18:53,360
deployment becomes like a more 
boring kind of event. 

351
00:18:53,920 --> 00:18:57,080
I was going to say whole 
ceremony about deploying to 

352
00:18:57,080 --> 00:18:59,600
production, the whole do not 
deploy on Fridays. 

353
00:19:00,280 --> 00:19:03,840
That's not something that you 
should be prideful about. 

354
00:19:03,840 --> 00:19:07,400
That's actually a smell that 
your process might not really be

355
00:19:07,440 --> 00:19:09,120
so great. 
If that deployment is that 

356
00:19:09,120 --> 00:19:12,160
risky, it means maybe there's 
something going on that you need

357
00:19:12,160 --> 00:19:13,960
to address. 
Perhaps do it a bit more 

358
00:19:13,960 --> 00:19:17,360
frequently and split it in 
smaller smaller deployments. 

359
00:19:18,200 --> 00:19:19,640
Yeah. 
Speaking about the difference 

360
00:19:19,640 --> 00:19:22,800
between continuous delivery and 
continuous deployment, I mean 

361
00:19:22,800 --> 00:19:25,960
one big aspect that I see is the
big differentiator is what you 

362
00:19:25,960 --> 00:19:29,840
call the still kind of like the 
manual deployment production, 

363
00:19:29,840 --> 00:19:31,080
right. 
So in the past, we used to have 

364
00:19:31,080 --> 00:19:33,840
like this manual approval stage 
where you know somebody will 

365
00:19:33,840 --> 00:19:36,520
decide when we actually deploy 
to production. 

366
00:19:36,800 --> 00:19:40,080
So tell us why it is very, very 
important to actually remove 

367
00:19:40,080 --> 00:19:43,360
this last critical piece, 
because for some stakeholders, 

368
00:19:43,360 --> 00:19:46,280
maybe they think having that is 
kind of like a guardrails to 

369
00:19:46,480 --> 00:19:48,480
ensure things are still going to
be safe. 

370
00:19:48,480 --> 00:19:51,400
It's kind of like verified 
before things are deployed to 

371
00:19:51,400 --> 00:19:54,200
production. 
So to explain why it is 

372
00:19:54,200 --> 00:19:58,160
important to remove these, which
might seem like a small piece 

373
00:19:58,160 --> 00:20:02,560
and a very important guardly, 
I'm going to connect to the 

374
00:20:02,560 --> 00:20:04,440
practice of lean manufacturing, 
right? 

375
00:20:05,160 --> 00:20:09,320
To me, really the most 
foundational practice of Lean is

376
00:20:09,480 --> 00:20:12,440
removing inventory from the 
value stream of software. 

377
00:20:12,800 --> 00:20:17,800
So what we see as the founding 
principle of Lean is that 

378
00:20:17,840 --> 00:20:22,080
instead of having big batches of
inventory going in between 

379
00:20:22,080 --> 00:20:26,240
workstations, we should try to 
reduce the flow of inventory 

380
00:20:26,240 --> 00:20:30,200
that is going through the system
to basically be only one piece 

381
00:20:30,200 --> 00:20:32,760
at a time. 
This allows to do some crucial 

382
00:20:32,760 --> 00:20:34,960
things, which is to, for 
example, identify the 

383
00:20:35,400 --> 00:20:38,680
immediately as they flow through
the value stream, rather than 

384
00:20:38,840 --> 00:20:43,680
waiting for an entire batch of 
things to be processed and going

385
00:20:43,680 --> 00:20:47,320
to the next workstation. 
But also, even more crucially, 

386
00:20:47,320 --> 00:20:50,680
it allows to drastically reduce 
the cycle time, so the time it 

387
00:20:50,680 --> 00:20:55,240
takes for any piece of work to 
flow through the entire stream 

388
00:20:55,240 --> 00:20:57,200
and be in the hands of 
customers. 

389
00:20:57,560 --> 00:20:59,760
Now, how does this translate to 
software? 

390
00:21:00,400 --> 00:21:03,840
This is a principle that was 
very successful when applied to 

391
00:21:03,840 --> 00:21:07,840
manufacturing of physical goods.
But of course it's very hard to 

392
00:21:07,840 --> 00:21:12,040
define inventory and software. 
So what I think of inventory and

393
00:21:12,040 --> 00:21:16,120
software is pretty much every 
intellectual artefact that is 

394
00:21:16,120 --> 00:21:19,040
included in software 
manufacturing. 

395
00:21:19,040 --> 00:21:23,040
So this for example, could be 
user stories, it could be 

396
00:21:23,320 --> 00:21:26,000
architecture diagrams, or it 
could be code. 

397
00:21:26,320 --> 00:21:28,440
So I'm going to focus mostly 
about code here. 

398
00:21:29,240 --> 00:21:30,800
How to define a batch of 
software? 

399
00:21:30,800 --> 00:21:35,720
For me, it needs to depend on 
how to identify a unit of 

400
00:21:35,720 --> 00:21:38,200
software. 
Defining a batch of software 

401
00:21:38,200 --> 00:21:41,120
basically has to depend on 
defining a unit of software. 

402
00:21:41,680 --> 00:21:44,440
So what is really a unit of 
software like? 

403
00:21:44,440 --> 00:21:48,240
When do we know that we have a 
big batch of inventory? 

404
00:21:48,760 --> 00:21:53,160
A unit cannot be really defined 
as a single instruction in code.

405
00:21:53,160 --> 00:21:55,280
I don't feel like because that's
not self consistent. 

406
00:21:55,440 --> 00:22:00,120
Instead, I define a unit of code
as a commit because that is the 

407
00:22:00,120 --> 00:22:04,320
smallest unit that we can have 
flow through that value stream. 

408
00:22:04,440 --> 00:22:07,360
In this case, the value stream 
could be represented by our 

409
00:22:07,360 --> 00:22:10,320
pipeline. 
So a commit is the smallest 

410
00:22:10,320 --> 00:22:14,440
possible unit by which we can 
review software, test software, 

411
00:22:14,440 --> 00:22:19,560
and eventually deploy software. 
So to me, a batch becomes when 

412
00:22:19,560 --> 00:22:22,800
commits accumulate during this 
value stream, right? 

413
00:22:23,120 --> 00:22:26,160
So when commits accumulate in 
your pipeline and that is when 

414
00:22:26,160 --> 00:22:31,240
you have some inventory that is 
stuck at a specific phase of 

415
00:22:31,480 --> 00:22:34,480
your value stream of code and 
that is where the effects can 

416
00:22:34,480 --> 00:22:37,440
accumulate. 
That is where your cycle time is

417
00:22:37,440 --> 00:22:42,160
slowing down and that is where 
all of the anti patterns of not 

418
00:22:42,160 --> 00:22:46,400
doing lean start to emerge. 
So bringing this back to 

419
00:22:46,440 --> 00:22:50,280
continuous deployment, you can 
think of continuous integration 

420
00:22:50,280 --> 00:22:54,680
and continuous delivery as the 
gradual transition from an old 

421
00:22:54,920 --> 00:22:59,800
batch and queue processes such 
as Waterfall, for example, where

422
00:23:00,000 --> 00:23:03,200
there is a lot of inventory 
moving really, really slowly in 

423
00:23:03,200 --> 00:23:06,000
between workstation. 
Continuous integration and 

424
00:23:06,000 --> 00:23:09,040
continuous delivery represented 
a shift from that. 

425
00:23:09,040 --> 00:23:12,320
So with continuous integration, 
you're starting to have what 

426
00:23:12,320 --> 00:23:16,000
looks like a one piece flow from
the development phase at least 

427
00:23:16,000 --> 00:23:18,960
to the integration phase because
it says integrate frequently. 

428
00:23:18,960 --> 00:23:22,320
So how frequently can you 
integrate at every commit of 

429
00:23:22,320 --> 00:23:24,960
course, and how frequently can 
you test at every commit? 

430
00:23:25,360 --> 00:23:29,960
So you have commit suddenly 
flowing one by one through at 

431
00:23:29,960 --> 00:23:33,440
least some of the earlier phases
of software manufacturing. 

432
00:23:33,600 --> 00:23:37,040
And so your inventory there is 
checked with the maximum 

433
00:23:37,080 --> 00:23:41,120
granularity that it can be 
checked, of course, later than 

434
00:23:41,120 --> 00:23:43,600
those phases. 
So say the deployment phase 

435
00:23:43,920 --> 00:23:47,000
wasn't yet automated in 
continuous integration. 

436
00:23:47,000 --> 00:23:50,880
So that's where commits or 
inventory could accumulate right

437
00:23:50,880 --> 00:23:53,400
before a deployment. 
And basically it would go 

438
00:23:53,400 --> 00:23:55,720
through the rest of the process 
again in batches. 

439
00:23:56,240 --> 00:23:59,760
Now with continuous delivery, 
the deployment phases following 

440
00:23:59,760 --> 00:24:03,920
that have been automated. 
So again, this one piece flow of

441
00:24:03,920 --> 00:24:09,320
inventory had been extended, but
still with most implementations 

442
00:24:09,320 --> 00:24:12,320
of continuous integration 
commits still accumulating 

443
00:24:12,320 --> 00:24:16,840
preproduction or in staging. 
So that's where basically, 

444
00:24:16,840 --> 00:24:20,400
again, your defects are showing 
up and your commits are 

445
00:24:20,400 --> 00:24:22,520
accumulating right before 
production. 

446
00:24:23,080 --> 00:24:27,560
Now this makes deployments to 
productions riskier because of 

447
00:24:27,560 --> 00:24:30,240
course you have a bigger batch. 
And so I mean the fact that has 

448
00:24:30,240 --> 00:24:32,760
accumulated in that batch is 
going to show up upon 

449
00:24:32,760 --> 00:24:35,040
deployment. 
So I think if you want to 

450
00:24:35,040 --> 00:24:38,440
realize this one piece flow all 
the way end to end, you 

451
00:24:38,440 --> 00:24:42,800
shouldn't have any manual points
in the pipeline where these 

452
00:24:42,800 --> 00:24:45,440
commits can accumulate and 
become stale. 

453
00:24:46,160 --> 00:24:47,600
Wow. 
I think it's a very nice 

454
00:24:47,600 --> 00:24:51,280
explanation why we should work 
towards this manner, right? 

455
00:24:51,280 --> 00:24:53,440
This practice, right? 
So one piece flow, I think 

456
00:24:53,440 --> 00:24:56,600
that's a very important thing 
from lean principles, right? 

457
00:24:56,840 --> 00:25:00,960
So I think also maybe for some 
people who are still not yet in 

458
00:25:00,960 --> 00:25:03,000
this kind of working mode, 
right? 

459
00:25:03,280 --> 00:25:06,200
What do you see some challenges 
maybe from your consulting, 

460
00:25:06,520 --> 00:25:09,280
maybe from, you know, having the
chance working with enterprise 

461
00:25:09,280 --> 00:25:12,440
mostly I believe they will have 
a lot of money shifts that need 

462
00:25:12,440 --> 00:25:14,280
to happen. 
What will be some common 

463
00:25:14,280 --> 00:25:16,480
challenges? 
Because deploying every commit 

464
00:25:16,480 --> 00:25:19,480
straight into production is not 
something that all the team can 

465
00:25:19,480 --> 00:25:22,200
aspire to do, right? 
Some might have regulations, 

466
00:25:22,200 --> 00:25:24,920
some might have compliance 
checks, some might have any 

467
00:25:25,000 --> 00:25:27,000
gatekeeping inside the software 
delivery. 

468
00:25:27,080 --> 00:25:29,280
So what do you think are some 
common challenges that people 

469
00:25:29,280 --> 00:25:31,720
need to really start to move 
away? 

470
00:25:32,680 --> 00:25:34,480
Yeah. 
And what you just said is 

471
00:25:34,480 --> 00:25:38,200
exactly why I have at least two 
chapters of disclaimers around 

472
00:25:38,200 --> 00:25:40,960
the when can you really do 
continuous deployment, When can 

473
00:25:40,960 --> 00:25:43,800
you? 
Not surprisingly, there's a lot 

474
00:25:43,800 --> 00:25:46,840
of situations where you think 
you might not be able to do it, 

475
00:25:46,840 --> 00:25:50,680
such as regulated industries, 
but in reality you're able to. 

476
00:25:51,160 --> 00:25:53,680
It depends really on the 
framework and regulation. 

477
00:25:54,280 --> 00:25:59,320
For example, in my case studies,
I have a new bank called N 26, 

478
00:25:59,400 --> 00:26:03,440
which is subject to basically 
all core banking regulations, 

479
00:26:03,440 --> 00:26:06,960
but they were able to still use 
a continuous deployment workflow

480
00:26:07,440 --> 00:26:11,200
because they have an automated 
pipeline that basically 

481
00:26:11,200 --> 00:26:15,400
satisfies all of the 
auditability requirements of the

482
00:26:15,400 --> 00:26:18,840
process. 
And as they finally says in his 

483
00:26:18,840 --> 00:26:22,160
excellent article, continuous 
compliance, an automated 

484
00:26:22,160 --> 00:26:25,320
pipeline is an absolute gold 
mine for auditors. 

485
00:26:25,680 --> 00:26:29,760
Basically, it has so much 
information on which changes 

486
00:26:29,760 --> 00:26:33,760
were applied to production, 
when, by who, for what reason, 

487
00:26:33,800 --> 00:26:37,640
because it will be related to a 
certain ticket, what tests were 

488
00:26:37,640 --> 00:26:41,480
they performed on them, how did 
these tests prove that they were

489
00:26:41,480 --> 00:26:43,520
successful, and so on and so 
forth. 

490
00:26:43,520 --> 00:26:47,960
So that already really helps, 
and it's just a matter of 

491
00:26:48,440 --> 00:26:52,520
figuring out what parts of your 
process can really apply to 

492
00:26:52,520 --> 00:26:55,920
satisfy this regulation. 
At the same time, it's very 

493
00:26:55,920 --> 00:26:59,800
common in regulated environments
to have authorized rules where 

494
00:26:59,800 --> 00:27:02,600
nobody can really put a commit 
in production alone. 

495
00:27:03,080 --> 00:27:07,080
That is something that also this
bank was able to satisfy because

496
00:27:07,120 --> 00:27:10,720
they found a way by doing a 
combination of pair programming 

497
00:27:10,720 --> 00:27:13,760
and micro branches with like 
immediate pull requests approved

498
00:27:13,760 --> 00:27:16,680
by a pair. 
That was their way to prove that

499
00:27:16,800 --> 00:27:20,200
a commit was seen by at least 
two people, the person that 

500
00:27:20,280 --> 00:27:23,160
authored the commits and the 
person that merged. 

501
00:27:23,880 --> 00:27:28,600
It might sound counterintuitive,
but there are ways to still use 

502
00:27:28,600 --> 00:27:31,200
modern practices in regulated 
industries. 

503
00:27:31,440 --> 00:27:34,400
Not because these practices are 
less safe, but because they are 

504
00:27:34,400 --> 00:27:37,840
more safe than manual approvals 
and waterfall. 

505
00:27:37,840 --> 00:27:41,280
And we just need to find a way 
to articulate that and really 

506
00:27:41,280 --> 00:27:44,440
explain that. 
Other situations where it might 

507
00:27:44,440 --> 00:27:47,560
be difficult to perform 
continuous deployment are 

508
00:27:47,560 --> 00:27:50,880
usually more by technical 
challenges rather than 

509
00:27:51,240 --> 00:27:53,240
regulatory ones, in my 
experience. 

510
00:27:53,680 --> 00:27:57,080
So for example, something that 
is really common that happens to

511
00:27:57,080 --> 00:28:00,360
teams that maybe want to move 
from continuous delivery to 

512
00:28:00,360 --> 00:28:03,960
continuous deployment is when 
you start doing deployments 

513
00:28:03,960 --> 00:28:07,040
really, really frequently, you 
might find out that your system 

514
00:28:07,040 --> 00:28:10,760
is more sensitive to deployments
than you might think. 

515
00:28:11,040 --> 00:28:14,480
And so this might affect things 
like your reliance on caches. 

516
00:28:15,200 --> 00:28:18,320
Suddenly when you deploy many 
different versions all in the 

517
00:28:18,320 --> 00:28:21,600
same day, your caches, if you 
have in memory ones, are going 

518
00:28:21,600 --> 00:28:23,920
to be mostly cold most of the 
day. 

519
00:28:24,320 --> 00:28:28,480
So that's when you need to find 
maybe architectural workarounds 

520
00:28:28,480 --> 00:28:30,920
such as moving your caches 
externally and so on. 

521
00:28:31,280 --> 00:28:34,800
Also, this applies to any kind 
of in memory state that you 

522
00:28:34,800 --> 00:28:39,800
might have in your application. 
So if your user flow depends on 

523
00:28:39,800 --> 00:28:42,680
certain state being stored in 
memory for whatever reason, that

524
00:28:42,680 --> 00:28:45,320
is something that the frequent 
deployments are going to be 

525
00:28:45,600 --> 00:28:47,480
disrupting really, really 
frequently. 

526
00:28:47,600 --> 00:28:51,240
So you need to also fix those 
kinds of scenarios before you 

527
00:28:51,240 --> 00:28:53,080
can really move on to this 
workflow. 

528
00:28:53,640 --> 00:28:57,280
Another really common scenario 
where people have trouble, and 

529
00:28:57,280 --> 00:29:01,960
maybe this one is not so easily 
fixable, is when your production

530
00:29:01,960 --> 00:29:05,160
environment that you want to 
continuously deploy to doesn't 

531
00:29:05,160 --> 00:29:08,240
belong to you. 
So after we think of production 

532
00:29:08,240 --> 00:29:12,240
as a server that is in our hands
and it is in our capability to 

533
00:29:12,240 --> 00:29:17,120
deploy to, but what about, for 
example, mobile apps or IoT 

534
00:29:17,120 --> 00:29:20,040
devices or on premises 
infrastructure that belongs to 

535
00:29:20,040 --> 00:29:23,360
someone else, right? 
In that case, it's a bit more of

536
00:29:23,360 --> 00:29:25,840
a grey area. 
What does it even mean to be 

537
00:29:25,840 --> 00:29:27,560
done with the deployment to 
production? 

538
00:29:27,800 --> 00:29:31,520
Are you done with your 
deployment when the first user 

539
00:29:31,520 --> 00:29:36,280
device has been updated or when 
the last one has been updated? 

540
00:29:36,520 --> 00:29:41,080
So there, that's when probably 
continuous deployment is not so 

541
00:29:41,280 --> 00:29:44,040
easy to implement. 
But again, there are workarounds

542
00:29:44,040 --> 00:29:47,840
that you can use. 
So for example, you can use Pwas

543
00:29:48,160 --> 00:29:50,680
to move control back to the 
server web views. 

544
00:29:51,160 --> 00:29:53,640
But yeah, that's when you may 
struggle a little bit. 

545
00:29:54,560 --> 00:29:56,240
Yeah. 
Thanks for the overview of some 

546
00:29:56,240 --> 00:29:59,680
of the challenges which I assume
some teams would have, right, 

547
00:29:59,680 --> 00:30:01,960
whenever they want to try to 
implement this continuous 

548
00:30:01,960 --> 00:30:04,200
deployment. 
But having said that, there's 

549
00:30:04,240 --> 00:30:07,480
also another team which probably
claimed that they do continuous 

550
00:30:07,480 --> 00:30:09,880
deployment, which I want you to 
kind of like explain because 

551
00:30:10,160 --> 00:30:11,880
they may not have so many 
processes. 

552
00:30:11,880 --> 00:30:15,360
They just have a commit and they
maybe do something in the build 

553
00:30:15,360 --> 00:30:17,400
pipeline, right? 
Maybe creating the artefact and 

554
00:30:17,400 --> 00:30:20,360
just deployed production. 
I'm sure this is not something 

555
00:30:20,360 --> 00:30:23,000
that you are advocating, right? 
Continuous deployment doesn't 

556
00:30:23,000 --> 00:30:25,560
mean that you just deploy 
straight away, but there are 

557
00:30:25,560 --> 00:30:28,360
certain processes in place. 
So tell us what is the minimum 

558
00:30:28,360 --> 00:30:30,840
thing that you should have in 
the continuous deployment? 

559
00:30:31,640 --> 00:30:33,200
Yeah. 
And thank you so much for asking

560
00:30:33,200 --> 00:30:36,700
that question because I don't 
want anybody to take as a take 

561
00:30:36,700 --> 00:30:39,880
away from this interview that 
whatever your the state of your 

562
00:30:39,880 --> 00:30:42,960
automation now you can just get 
rid of any manual approval and 

563
00:30:42,960 --> 00:30:45,200
go straight to prod and nothing 
will happen. 

564
00:30:45,200 --> 00:30:50,120
So basically there are a certain
minimum amount of practices that

565
00:30:50,160 --> 00:30:52,480
you should definitely make sure 
that you have. 

566
00:30:52,720 --> 00:30:57,920
So again, a pipeline that is 
fully automated, but that 

567
00:30:57,920 --> 00:31:00,960
pipeline needs to contain tests 
and a lot of them. 

568
00:31:01,320 --> 00:31:04,200
So that's what I go back to 
recommending, you know, the 

569
00:31:04,360 --> 00:31:07,760
typical testing pyramid, which 
means you should have a pretty, 

570
00:31:07,760 --> 00:31:11,640
pretty good unit test coverage, 
a pretty good coverage of 

571
00:31:11,720 --> 00:31:15,600
automated tests both before and 
after deployments, if that is 

572
00:31:15,600 --> 00:31:18,560
possible for you. 
There are practices that can 

573
00:31:18,560 --> 00:31:21,920
maximize this coverage. 
And the ones that I use most 

574
00:31:21,920 --> 00:31:25,480
often are the ones that 
basically allow you to write 

575
00:31:25,480 --> 00:31:29,080
your test first. 
So TDD is my prime example and 

576
00:31:29,080 --> 00:31:33,800
outside in TDD, if you use this,
you know that your coverage is 

577
00:31:33,800 --> 00:31:37,600
growing together with your code 
in the same commit which is done

578
00:31:37,600 --> 00:31:40,480
going through the pipeline. 
So those can make you pretty 

579
00:31:40,480 --> 00:31:44,080
safe. 
Then alongside tests, which are 

580
00:31:44,080 --> 00:31:48,080
great for functional changes, I 
always recommend some forms of 

581
00:31:48,080 --> 00:31:52,200
static code analysis to be in 
your pipeline, such as security 

582
00:31:52,200 --> 00:31:55,000
scanning, performance scanning. 
If you use a tool like Sonar 

583
00:31:55,000 --> 00:31:58,880
Cube, that is going to be really
effective at catching most 

584
00:31:58,880 --> 00:32:01,680
regressions that maybe might be 
missed by your tests. 

585
00:32:01,920 --> 00:32:03,040
And that's really important, 
right? 

586
00:32:03,040 --> 00:32:06,400
Because if you're publishing 
every commit, then every single 

587
00:32:06,400 --> 00:32:09,360
commit might affect the 
performance of production or 

588
00:32:09,360 --> 00:32:13,600
open a security vulnerability. 
So static scanning can really, 

589
00:32:13,600 --> 00:32:17,000
really catch all of those 
regressions and that really more

590
00:32:17,040 --> 00:32:20,800
granularity. 
Then of course, another question

591
00:32:20,800 --> 00:32:23,720
that I get really often about 
what are the prerequisites is 

592
00:32:23,720 --> 00:32:26,520
how do you hide your work in 
progress if you're just 

593
00:32:26,520 --> 00:32:28,160
publishing every commit to 
production? 

594
00:32:28,400 --> 00:32:30,960
Because you say you shouldn't 
have long Fisher branches where 

595
00:32:30,960 --> 00:32:34,800
you hide your changes, but also 
everything on master needs to go

596
00:32:34,800 --> 00:32:38,600
to prod immediately. 
So we need to also be 

597
00:32:38,600 --> 00:32:43,080
comfortable with our team to use
patterns like feature flags and 

598
00:32:43,080 --> 00:32:46,720
the typical expand and contract 
pattern or parallel change or 

599
00:32:46,840 --> 00:32:49,320
branch by extraction, whatever 
you call it. 

600
00:32:49,680 --> 00:32:54,080
All of the those patterns can 
help you hide any new change 

601
00:32:54,080 --> 00:32:56,640
that you don't want your users 
to see, even though that change 

602
00:32:56,640 --> 00:32:59,440
is in production. 
So I highly recommend to be 

603
00:32:59,440 --> 00:33:03,000
familiar with those. 
Then finally, of course, you 

604
00:33:03,000 --> 00:33:05,880
need to have 0 downtime 
deployments as a minimum 

605
00:33:05,880 --> 00:33:08,200
practice. 
I think most teams do these 

606
00:33:08,200 --> 00:33:12,040
days, but it's always best to 
check so you can achieve those 

607
00:33:12,040 --> 00:33:15,400
with rolling updates. 
You can achieve it with 

608
00:33:15,400 --> 00:33:17,680
blue-green deployments or red, 
black. 

609
00:33:17,920 --> 00:33:21,120
You can also perform cannery 
deployments with tools like 

610
00:33:21,120 --> 00:33:25,000
Spinacer, where basically the 
tool is going to be connected to

611
00:33:25,000 --> 00:33:29,320
your observability tool and 
observe for example, the error 

612
00:33:29,320 --> 00:33:32,640
rate of your application and 
roll back immediately if that 

613
00:33:32,640 --> 00:33:37,200
error rate becomes worse. 
So observability and alerting is

614
00:33:37,200 --> 00:33:40,680
maybe the final absolute 
prerequisite that I recommend 

615
00:33:40,680 --> 00:33:43,760
before turning on, you know, the
fully automated pipeline, 

616
00:33:43,760 --> 00:33:47,400
removing the last gate to prod. 
Because as employments get more 

617
00:33:47,400 --> 00:33:49,840
frequent, there is also less 
oversight on them. 

618
00:33:49,840 --> 00:33:53,600
As you said, they become just a 
boring event that happens 

619
00:33:53,640 --> 00:33:56,880
multiple times a day. 
So we need to be proactively 

620
00:33:56,880 --> 00:34:00,560
notified in the very rare event 
that something does go wrong. 

621
00:34:00,800 --> 00:34:04,920
And that's where I recommend 
having a really, really sturdy 

622
00:34:05,000 --> 00:34:07,480
dashboard, keeping track of all 
your metrics. 

623
00:34:07,920 --> 00:34:11,199
And most of all, take care of 
your alerting based on your 

624
00:34:11,199 --> 00:34:15,440
metrics, because you definitely 
don't want your team to be used 

625
00:34:15,440 --> 00:34:19,400
to seeing a lot of alerts and 
not having to react to them. 

626
00:34:19,400 --> 00:34:23,280
So keeping those really tidy and
only keeping alerts that are 

627
00:34:23,280 --> 00:34:27,239
useful and require any sort of 
action that's going to really 

628
00:34:27,239 --> 00:34:29,560
help. 
Thanks for the clarification. 

629
00:34:29,560 --> 00:34:32,280
I mean just to re emphasize one 
more time, continuous deployment

630
00:34:32,280 --> 00:34:35,280
doesn't mean that any kind of 
commit you just deploy to 

631
00:34:35,280 --> 00:34:37,880
production straight away, right?
So there are certain practices, 

632
00:34:37,880 --> 00:34:39,960
certain minimum that you need to
achieve, right. 

633
00:34:40,239 --> 00:34:42,639
And Valentin, I just mentioned, 
you know several of them, right,

634
00:34:42,639 --> 00:34:45,400
which I believe are like some 
core practices that every 

635
00:34:45,400 --> 00:34:46,960
engineering team should aspire 
to do. 

636
00:34:47,360 --> 00:34:49,920
I think 1 aspect of continuous 
delivery that is also very 

637
00:34:49,920 --> 00:34:53,320
important is that everything 
that you prepare to go to 

638
00:34:53,320 --> 00:34:55,719
production, right, must be 
verifiable and you have high 

639
00:34:55,719 --> 00:34:58,800
degree of confidence that it 
will work in production as well.

640
00:34:58,800 --> 00:35:01,760
So it's not something that you 
kind of like Yolo, you know, you

641
00:35:01,760 --> 00:35:03,760
just wait for the users to 
report the bugs to you. 

642
00:35:04,400 --> 00:35:07,280
And I think one other aspect is 
about backward compatibility, 

643
00:35:07,280 --> 00:35:09,360
right? 
So whenever you make so many 

644
00:35:09,360 --> 00:35:12,240
changes, right, I'm sure some 
users, maybe some servers are 

645
00:35:12,240 --> 00:35:14,520
not taking the changes straight 
away, right? 

646
00:35:14,520 --> 00:35:16,960
So you need to make sure that 
some backward compatibility must

647
00:35:16,960 --> 00:35:20,200
be in place, which brings me to 
this thing that you mentioned, 

648
00:35:20,200 --> 00:35:21,960
right? 
Hiding work in progress, 

649
00:35:22,360 --> 00:35:24,120
definitely. 
If every commit must go to 

650
00:35:24,120 --> 00:35:27,440
production, we cannot finish a 
new feature just within one 

651
00:35:27,440 --> 00:35:29,600
commit, right? 
So you mentioned about feature 

652
00:35:29,600 --> 00:35:31,840
flag or maybe expand and 
contract. 

653
00:35:31,840 --> 00:35:34,680
Tell us more a little bit about 
this practice because I'm sure 

654
00:35:34,680 --> 00:35:38,120
some people might still think, 
oh, I cannot work this way 

655
00:35:38,120 --> 00:35:40,840
simply because I have some work 
that I can't finish. 

656
00:35:41,120 --> 00:35:44,160
So tell us how we can use those 
techniques to do this. 

657
00:35:45,320 --> 00:35:47,120
Yeah, thank you for mentioning 
those. 

658
00:35:47,120 --> 00:35:50,440
They are the ones that I rely on
most heavily throughout the book

659
00:35:50,440 --> 00:35:52,480
as well. 
So I think it's definitely worth

660
00:35:52,480 --> 00:35:54,200
to take the time and understand 
them. 

661
00:35:54,800 --> 00:35:58,120
So let's start with the feature 
flags. 

662
00:35:58,360 --> 00:36:02,160
So I recommend using feature 
flags whenever there are visible

663
00:36:02,160 --> 00:36:06,720
changes to the code base and the
application that if deploy to 

664
00:36:06,720 --> 00:36:10,040
production, will alter what the 
user experiencing and the 

665
00:36:10,040 --> 00:36:11,880
observable behaviour of the 
system. 

666
00:36:12,440 --> 00:36:16,280
Most people are used to hiding 
such changes in version control 

667
00:36:16,280 --> 00:36:21,120
branches and then the act of 
publishing them will be to merge

668
00:36:21,160 --> 00:36:24,840
the version control branch into 
main and finally let's main go 

669
00:36:24,840 --> 00:36:27,680
to production. 
Using a feature flag instead 

670
00:36:27,960 --> 00:36:31,440
still uses a kind of branch, but
it is not a branch that belongs 

671
00:36:31,440 --> 00:36:35,240
in the version control system, 
it is a branch that belongs to 

672
00:36:35,240 --> 00:36:38,000
the tree of classes and 
functions within your 

673
00:36:38,000 --> 00:36:40,840
application. 
So I call it an execution branch

674
00:36:41,240 --> 00:36:45,400
for that reason, and that will 
do exactly the same job of 

675
00:36:45,400 --> 00:36:48,640
Aversion control branch, except 
it's going to still allow you to

676
00:36:48,720 --> 00:36:52,040
integrate your code frequently 
and deploy your code to 

677
00:36:52,040 --> 00:36:55,480
production frequently. 
So during development, you will 

678
00:36:55,480 --> 00:36:59,480
basically put a feature flag as 
the very first step of beginning

679
00:36:59,560 --> 00:37:04,080
any new feature, and the feature
flag will be off until that 

680
00:37:04,080 --> 00:37:08,040
feature is released to the users
in production. 

681
00:37:08,480 --> 00:37:11,600
I think this is really powerful 
because it also allows you to 

682
00:37:11,600 --> 00:37:15,440
express the conditional logic of
when you want your feature to be

683
00:37:15,440 --> 00:37:19,040
seen or not seen, for example, 
for a reason, in a way that is 

684
00:37:19,040 --> 00:37:22,600
much more expressive than just 
the textual control that version

685
00:37:22,600 --> 00:37:25,880
control gives you. 
So I really rely on feature 

686
00:37:25,880 --> 00:37:29,600
flags a lot for that reason. 
Finally, for expand and 

687
00:37:29,600 --> 00:37:33,240
contract, that is a pattern that
I tend to use when I'm making 

688
00:37:33,240 --> 00:37:36,960
not so visible changes, but 
changes that I still I'm not 

689
00:37:36,960 --> 00:37:39,960
feeling super confident in, or 
that I want to split into 

690
00:37:39,960 --> 00:37:43,120
smaller and smaller increments. 
An example of this could be 

691
00:37:43,120 --> 00:37:47,320
refactoring a really big 
subsystem of your code base, or 

692
00:37:47,320 --> 00:37:50,320
for example an entire endpoint 
of an API. 

693
00:37:50,680 --> 00:37:54,040
That's when I would basically 
duplicate the flow completely, 

694
00:37:54,040 --> 00:37:57,480
making sure that the interface 
of the old flow and the 

695
00:37:57,480 --> 00:38:00,480
interface of the new flow is 
respected equally. 

696
00:38:01,040 --> 00:38:04,400
That allows you to basically 
commit at any point, because you

697
00:38:04,400 --> 00:38:08,480
can migrate the clients of the 
old flow to the new flow 1 by 1 

698
00:38:08,480 --> 00:38:12,440
and still completely respect the
functionality of the system, 

699
00:38:12,440 --> 00:38:15,400
which your regression tests 
should be able to catch if you 

700
00:38:15,400 --> 00:38:18,320
broke that. 
So yeah, you can read more about

701
00:38:18,320 --> 00:38:20,840
this in the book. 
I have a lot of concrete code 

702
00:38:20,840 --> 00:38:24,120
examples. 
Yeah, I highly recommend reading

703
00:38:24,120 --> 00:38:27,200
this part because I think this 
is one key practice that is very

704
00:38:27,200 --> 00:38:29,680
important in continuous delivery
and continuous deployment, 

705
00:38:29,680 --> 00:38:32,240
right? 
So for those of you who also 

706
00:38:32,360 --> 00:38:34,960
have not heard about expand and 
contract before, some people 

707
00:38:34,960 --> 00:38:38,520
call it branch by abstraction. 
Maybe if you have like OOP, you 

708
00:38:38,520 --> 00:38:41,080
have interface implementation, 
different abstract class and 

709
00:38:41,080 --> 00:38:43,720
different implementation. 
This is also one aspect that is 

710
00:38:43,720 --> 00:38:45,880
kind of like similar in terms of
implementation. 

711
00:38:46,400 --> 00:38:49,080
And I think this is also a good 
time to actually explain the 

712
00:38:49,080 --> 00:38:52,520
difference between what we call 
deployment versus release, 

713
00:38:52,520 --> 00:38:54,080
right? 
Because with things like feature

714
00:38:54,080 --> 00:38:57,440
flag, it allows us to kind of 
like control the time to release

715
00:38:57,440 --> 00:38:59,480
a particular feature. 
So tell us about this 

716
00:38:59,480 --> 00:39:02,520
difference. 
Yeah, and this is the reason why

717
00:39:02,520 --> 00:39:05,840
I love feature flags, right? 
So with continuous delivery, it 

718
00:39:05,840 --> 00:39:09,280
was still true that you could 
use feature flags and have a 

719
00:39:09,680 --> 00:39:11,720
separation of deployment and 
release. 

720
00:39:12,240 --> 00:39:15,240
But with continuous deployment 
it becomes mandatory and the 

721
00:39:15,240 --> 00:39:18,480
user feature flags becomes 
mandatory because your pipeline 

722
00:39:18,480 --> 00:39:21,840
is not gonna stop anything 
visible from going to prod if 

723
00:39:21,840 --> 00:39:24,520
the tests are green. 
Because those practices are 

724
00:39:24,520 --> 00:39:28,400
mandatory, the distinction 
between deployment and release 

725
00:39:28,480 --> 00:39:32,680
becomes much more well marked 
and much more important for 

726
00:39:32,680 --> 00:39:36,320
teams. 
So a deployment in itself during

727
00:39:36,320 --> 00:39:41,000
continuous deployment is any 
roll out of new conversions into

728
00:39:41,000 --> 00:39:42,920
production. 
But a deployment in and of 

729
00:39:42,920 --> 00:39:46,560
itself should never alter the 
visible behavior of the system. 

730
00:39:46,960 --> 00:39:51,120
At the same time, a release 
usually becomes the act of 

731
00:39:51,120 --> 00:39:55,000
turning on a feature flag, which
again, if you have a good 

732
00:39:55,000 --> 00:39:57,880
feature flag framework, should 
never require a deployment 

733
00:39:57,920 --> 00:39:59,840
because you can do so at 
runtime. 

734
00:40:00,120 --> 00:40:03,720
So there is a very, very clear 
distinction in the timing and 

735
00:40:03,720 --> 00:40:07,520
how these two things happen. 
A deployment becomes just an 

736
00:40:07,520 --> 00:40:11,760
engineering concern and release 
becomes a product concern. 

737
00:40:11,760 --> 00:40:14,160
It's like, when is there a time 
to turn on this feature? 

738
00:40:14,640 --> 00:40:17,800
Do we want? 
The entire user base to see it? 

739
00:40:17,800 --> 00:40:20,520
Or do we want to run a 5050 test
first? 

740
00:40:20,600 --> 00:40:22,520
Or do we want to do a gradual 
ramp up? 

741
00:40:22,600 --> 00:40:26,360
How does product feel like this 
would be best released? 

742
00:40:26,880 --> 00:40:30,320
And this also brings us to a 
really great situation where a 

743
00:40:30,320 --> 00:40:34,600
deployment being purely an 
engineering concern can be done 

744
00:40:34,600 --> 00:40:36,960
without the input of products. 
So we should never be in the 

745
00:40:36,960 --> 00:40:41,120
situation, say, where I as a 
developer get told please do not

746
00:40:41,120 --> 00:40:46,080
deploy any new version because 
we are in the peak season for 

747
00:40:46,080 --> 00:40:48,960
example, for our business and 
the product wants to wait. 

748
00:40:49,280 --> 00:40:52,600
At the same time, I should never
be in the situation where as a 

749
00:40:52,600 --> 00:40:56,480
developer I have to tell product
that feature cannot be released 

750
00:40:56,480 --> 00:40:59,680
because as there is a pending 
deployment because all the code 

751
00:40:59,680 --> 00:41:02,120
should have been in production 
in the 1st place. 

752
00:41:02,560 --> 00:41:06,120
So yeah, definitely these two 
things kind of take a life of 

753
00:41:06,120 --> 00:41:08,160
their own with the use of 
feature flags. 

754
00:41:08,160 --> 00:41:11,520
And that is why I consider them 
such a strong, strong 

755
00:41:11,520 --> 00:41:14,880
prerequisite for any modern 
pipeline, be it continuous 

756
00:41:14,880 --> 00:41:16,840
deployment or also continuous 
delivery. 

757
00:41:17,680 --> 00:41:19,320
Yeah, I think that's a good 
distinction, right? 

758
00:41:19,320 --> 00:41:21,440
Deployment should be the 
technical or engineering 

759
00:41:21,440 --> 00:41:25,000
concern, while release should be
the product or stakeholders 

760
00:41:25,000 --> 00:41:27,400
position, right. 
If the team can separate these 

761
00:41:27,400 --> 00:41:30,920
kind of A2 important activities,
I think that's a really great 

762
00:41:30,920 --> 00:41:33,360
shape. 
And I think feature flag, so 

763
00:41:33,360 --> 00:41:36,840
many tools these days, I'm sure 
having a platform that can allow

764
00:41:36,840 --> 00:41:39,920
you to do this behavior is 
something that is not impossible

765
00:41:39,920 --> 00:41:42,600
anymore. 
Another important thing that I 

766
00:41:42,600 --> 00:41:45,680
think what to call out here is 
about slicing the work, right? 

767
00:41:45,680 --> 00:41:48,600
Because if let's say I want to 
build a new feature, sometimes a

768
00:41:48,600 --> 00:41:51,640
feature is not like very simple 
like change a color of something

769
00:41:51,840 --> 00:41:53,560
or create a button or something 
like that. 

770
00:41:53,560 --> 00:41:57,400
But it's more like a maybe like 
workflow or something like that.

771
00:41:57,680 --> 00:42:01,040
How do you actually advise us to
slice the work right? 

772
00:42:01,040 --> 00:42:05,000
Because making sure that the 
small batch committed up to 

773
00:42:05,000 --> 00:42:07,680
production is something that 
maybe some of us are not used 

774
00:42:07,680 --> 00:42:09,680
to. 
That's a great question. 

775
00:42:09,680 --> 00:42:13,920
So there's always been that 
eternal battle between slicing 

776
00:42:13,920 --> 00:42:18,680
work by code base and slicing 
work more vertically by feature.

777
00:42:19,120 --> 00:42:23,200
I'm going to say with this type 
of workflow, continuous 

778
00:42:23,200 --> 00:42:26,680
deployment is even more 
important than it was before to 

779
00:42:26,680 --> 00:42:30,400
start thinking of slicing work 
vertically by feature instead of

780
00:42:30,480 --> 00:42:33,200
by code base. 
And it's for the very simple 

781
00:42:33,200 --> 00:42:36,560
reason that as I mentioned, we 
have practices like feature 

782
00:42:36,560 --> 00:42:41,360
flags and especially expand and 
contract that require multiple 

783
00:42:41,360 --> 00:42:45,480
small changes to production on 
different systems a lot of the 

784
00:42:45,480 --> 00:42:49,080
time to guarantee backwards 
compatibility until the feature 

785
00:42:49,080 --> 00:42:52,920
is completed. 
So for example, in order to add 

786
00:42:52,920 --> 00:42:57,600
the some new functionality to my
system, I might need to alter my

787
00:42:57,960 --> 00:43:01,160
front end and back end code base
and my DB. 

788
00:43:01,280 --> 00:43:06,680
Right now, because I'm doing 
continuous deployment, I want to

789
00:43:06,840 --> 00:43:12,560
maybe build it slowly and deploy
multiple commits one at a time 

790
00:43:12,560 --> 00:43:16,240
into production to guarantee for
example backwards compatibility 

791
00:43:16,240 --> 00:43:18,960
of my back end, say with my 
database schema. 

792
00:43:19,240 --> 00:43:23,080
Maybe I need to create a new 
table, migrate something in my 

793
00:43:23,080 --> 00:43:26,960
back end to go to this new table
instead of the old one that's a 

794
00:43:26,960 --> 00:43:30,280
new deployment on the back end. 
And then maybe I need to 

795
00:43:30,280 --> 00:43:33,440
redeploy my database to clean up
the old table, let me 

796
00:43:33,440 --> 00:43:37,360
synchronize some data. 
So if I slice these tasks 

797
00:43:37,400 --> 00:43:42,080
horizontally, I have to create 
so many tasks just to jump 

798
00:43:42,080 --> 00:43:44,920
around on which change do I need
to make now on this system and 

799
00:43:44,920 --> 00:43:47,840
on this system, And they're all 
gonna be blocking each other. 

800
00:43:47,840 --> 00:43:51,680
So it's not a really efficient 
way to work with these ways of 

801
00:43:51,680 --> 00:43:54,960
working. 
Instead, if I slice vertically, 

802
00:43:55,080 --> 00:43:59,360
I can split my task, my user 
story into multiple commits, but

803
00:43:59,360 --> 00:44:03,600
I have the freedom of relating 
them all to that ticket or that 

804
00:44:03,600 --> 00:44:07,600
user story and to really plan 
out within the story what 

805
00:44:07,960 --> 00:44:10,560
commits do I really need to do 
in which system and in which 

806
00:44:10,560 --> 00:44:13,760
order to achieve that 
functionality at the very end. 

807
00:44:14,080 --> 00:44:17,200
So yeah, it becomes much, much 
more important to slice 

808
00:44:17,200 --> 00:44:20,280
vertically. 
And it also allows you really to

809
00:44:20,280 --> 00:44:23,440
leverage the granularity of 
continuous deployment as a 

810
00:44:23,440 --> 00:44:27,120
practice because the fact that 
everything is in production all 

811
00:44:27,120 --> 00:44:31,480
the time, it can make emerge 
some situations where actually 

812
00:44:31,880 --> 00:44:35,280
you're ready to release a 
feature in a state where you 

813
00:44:35,280 --> 00:44:38,960
previously thought you wouldn't.
So say after maybe only two or 

814
00:44:38,960 --> 00:44:42,480
three user stories instead of 
after all 10 user stories, 

815
00:44:42,480 --> 00:44:45,560
because perhaps product wants to
run an IB test a bit earlier. 

816
00:44:45,840 --> 00:44:48,920
And so not only becomes 
important for technical reasons,

817
00:44:48,920 --> 00:44:52,520
but also it's like you really 
leverage the speed of continuous

818
00:44:52,520 --> 00:44:54,120
deployment. 
Yeah. 

819
00:44:54,120 --> 00:44:56,360
So I think vertical slicing is 
the key here, right? 

820
00:44:56,360 --> 00:44:58,800
It also goes back to how you 
slice your story, right? 

821
00:44:58,800 --> 00:45:01,600
So a feature should be sliced 
into a different shape of 

822
00:45:01,600 --> 00:45:03,440
stories. 
And if you can shape it more 

823
00:45:03,440 --> 00:45:06,400
vertically, that brings value 
like any kind of value to the 

824
00:45:06,400 --> 00:45:09,000
users, maybe some other third 
parties, right? 

825
00:45:09,000 --> 00:45:11,880
I think that will be the key. 
Talking about third parties, I 

826
00:45:11,880 --> 00:45:14,520
know these days people are 
working in a kind of like micro 

827
00:45:14,520 --> 00:45:17,320
service or service oriented 
architecture, continuous 

828
00:45:17,320 --> 00:45:19,840
deployment also have this 
challenge of having to 

829
00:45:19,840 --> 00:45:23,960
coordinate your changes with 
other third parties APIs, 

830
00:45:23,960 --> 00:45:26,880
whatever that is, right? 
So tell us how can we do this 

831
00:45:26,880 --> 00:45:28,600
better? 
Because obviously you can't 

832
00:45:28,600 --> 00:45:32,160
control how the other team is 
ready or taking changes from 

833
00:45:32,160 --> 00:45:35,280
your new version, right? 
So how would you advise us to do

834
00:45:35,280 --> 00:45:37,080
this? 
It depends. 

835
00:45:37,080 --> 00:45:40,040
There's third parties and third 
parties, right? 

836
00:45:40,480 --> 00:45:43,560
If you're working in a team that
takes care of micro service 

837
00:45:43,880 --> 00:45:47,720
within a larger ecosystem, 
another team within the same 

838
00:45:47,720 --> 00:45:49,880
organization will be a third 
party to you. 

839
00:45:50,720 --> 00:45:53,840
But also it could be that you 
have to communicate with a 

840
00:45:53,840 --> 00:45:57,240
vendor system which is in a 
completely separate organization

841
00:45:57,240 --> 00:46:00,000
and they have a completely 
different change management 

842
00:46:00,000 --> 00:46:02,080
process. 
So I'm gonna say there is much 

843
00:46:02,080 --> 00:46:05,320
more flexibility when you're 
dealing with other teams as 

844
00:46:05,320 --> 00:46:09,520
third parties because you can 
coordinate much more frequently 

845
00:46:09,520 --> 00:46:13,880
on what new version of what is 
going live at which point. 

846
00:46:13,880 --> 00:46:16,760
And you might even be able to 
pair with someone from another 

847
00:46:16,760 --> 00:46:20,240
team to always guarantee 
synchronisation between the 

848
00:46:20,240 --> 00:46:23,840
systems changing. 
On the other hand, if you're 

849
00:46:23,840 --> 00:46:26,760
dealing with third party 
vendors, that's when you need 

850
00:46:26,760 --> 00:46:32,080
some stronger practices that are
much more formal to manage the 

851
00:46:32,080 --> 00:46:35,440
contracts in between systems. 
And that's where I usually fall 

852
00:46:35,440 --> 00:46:38,960
back to things like API 
versioning, which is something 

853
00:46:38,960 --> 00:46:42,360
that I wouldn't do necessarily 
if I have an API just for 

854
00:46:42,360 --> 00:46:45,240
internal usage. 
I can very easily coordinate 

855
00:46:45,600 --> 00:46:49,040
with other teams and say, hey, 
please change your usage like 

856
00:46:49,040 --> 00:46:53,280
this and we'll tidy up without 
the need to maintain 1000 

857
00:46:53,280 --> 00:46:56,040
different versions of some API. 
That is going to be a lot of 

858
00:46:56,040 --> 00:46:59,040
maintenance, but with an 
extended vendor where I have no 

859
00:46:59,040 --> 00:47:01,760
control or what they're doing, 
that's when I would pay the 

860
00:47:01,760 --> 00:47:04,080
price of versioning an API, for 
example. 

861
00:47:04,400 --> 00:47:06,040
Same thing with contract 
testing. 

862
00:47:06,040 --> 00:47:09,080
I'm going to have much stronger 
contract testing and 

863
00:47:09,080 --> 00:47:13,160
requirements if I am consuming 
or producing an API for a third 

864
00:47:13,160 --> 00:47:16,760
party vendor than for a team 
within my same organization. 

865
00:47:17,120 --> 00:47:20,720
So that's how I would handle it.
And of course within the 

866
00:47:20,720 --> 00:47:23,920
organization, that's what 
practices like expanding 

867
00:47:23,920 --> 00:47:27,520
contract and feature flags get 
even more useful them within 

868
00:47:27,520 --> 00:47:31,760
just a singular system because 
they not only allow to hide the 

869
00:47:31,760 --> 00:47:35,680
work in progress within one 
system, but also across several 

870
00:47:35,680 --> 00:47:38,600
system. 
So they can also be used to 

871
00:47:38,600 --> 00:47:42,120
guarantee backwards 
compatibility of systems that 

872
00:47:42,120 --> 00:47:45,800
are independently deployed and 
where therefore you cannot bump 

873
00:47:45,800 --> 00:47:48,560
everything to the next version 
exactly at the same time. 

874
00:47:48,880 --> 00:47:53,160
So I encourage teams to look 
into these practices as well for

875
00:47:53,160 --> 00:47:56,640
working with micro services and 
testing integration with other 

876
00:47:56,640 --> 00:47:58,720
micro services. 
Yeah. 

877
00:47:58,720 --> 00:48:00,680
And I would like to again 
emphasize backward 

878
00:48:00,680 --> 00:48:04,200
compatibility, always ensure 
that you support a few versions 

879
00:48:04,200 --> 00:48:07,080
behind, right, simply because 
you can't control the other 

880
00:48:07,080 --> 00:48:09,640
teams whether they are taking a 
changes straight away or they 

881
00:48:09,640 --> 00:48:12,640
will take some time before they 
actually apply those changes, 

882
00:48:12,680 --> 00:48:14,600
right. 
So I think you mentioned also 

883
00:48:14,600 --> 00:48:16,760
contract testing and things like
that definitely is a good 

884
00:48:16,760 --> 00:48:19,800
practice as well. 
I just wanted to add as well 

885
00:48:19,800 --> 00:48:23,040
that this is not just something 
that needs to be taken care of 

886
00:48:23,040 --> 00:48:26,000
when you have a micro service 
environment. 

887
00:48:26,800 --> 00:48:29,920
The concept of backwards 
compatibility applies to any 

888
00:48:29,920 --> 00:48:32,920
system which is distributed, 
even if at a glance it looks 

889
00:48:32,920 --> 00:48:37,320
like a monolithic system. 
In my experience any system that

890
00:48:37,320 --> 00:48:40,000
is interesting rarely is really 
monolithic right? 

891
00:48:40,000 --> 00:48:44,440
For example, even if you have 
just one simple website with one

892
00:48:44,440 --> 00:48:48,080
database, you already have 3 
distributed components that you 

893
00:48:48,080 --> 00:48:50,440
need to keep backwards 
compatible at all times. 

894
00:48:50,440 --> 00:48:54,000
You have your front end which is
executed on the user browser and

895
00:48:54,000 --> 00:48:56,320
it's not going to receive 
changes at the same time your 

896
00:48:56,320 --> 00:48:58,800
server does. 
Then you have your server, and 

897
00:48:58,800 --> 00:49:02,840
then your database is a 
completely separate executable 

898
00:49:02,840 --> 00:49:05,600
and most often deployed on a 
different machine as well. 

899
00:49:06,000 --> 00:49:10,280
So the thing you really need to 
take into consideration is inter

900
00:49:10,280 --> 00:49:13,880
process communication. 
Whenever there is such a thing, 

901
00:49:13,880 --> 00:49:18,240
which is almost always, you 
would probably want to rely on 

902
00:49:18,560 --> 00:49:21,880
things like feature flags or 
expand and contract at a 

903
00:49:21,880 --> 00:49:24,200
minimum. 
Continuous deployment just makes

904
00:49:24,200 --> 00:49:27,680
it much more evident because 
with that it happens all the 

905
00:49:27,680 --> 00:49:29,600
time. 
You do deployments all the time 

906
00:49:29,600 --> 00:49:32,880
and usually micro service 
oriented environments. 

907
00:49:32,920 --> 00:49:36,160
But this is not a new problem. 
This is a problem that we should

908
00:49:36,160 --> 00:49:38,440
have been solving already much 
before. 

909
00:49:38,440 --> 00:49:41,480
And you know, when deployments 
are infrequent, sometimes it's 

910
00:49:41,480 --> 00:49:44,440
easy to ignore if there's some 
deployment glitches. 

911
00:49:44,760 --> 00:49:47,360
Whereas with continuous 
deployment you can't ignore them

912
00:49:47,360 --> 00:49:50,400
anymore because they just happen
every single day. 

913
00:49:51,360 --> 00:49:52,760
Yeah. 
And this goes back again to the 

914
00:49:52,760 --> 00:49:54,840
principle. 
If it hurts, do it more often. 

915
00:49:54,920 --> 00:49:57,280
You should not have. 
If it hurts, then you stop doing

916
00:49:57,280 --> 00:49:59,960
it, or you kind of like reduce 
the frequency of doing it, 

917
00:49:59,960 --> 00:50:01,640
right. 
So I think the more you do it, 

918
00:50:01,640 --> 00:50:04,440
the more you figure it out how 
to make it safer, how to make 

919
00:50:04,440 --> 00:50:07,200
it, you know, smoother. 
Another thing, apart from 

920
00:50:07,200 --> 00:50:10,640
technical practices, are there 
cultural aspects or maybe you 

921
00:50:10,640 --> 00:50:13,560
know, like onset shift that 
people should know about before 

922
00:50:13,560 --> 00:50:16,080
they can actually implement this
continuous deployment? 

923
00:50:16,960 --> 00:50:20,480
Yeah, for sure. 
And that's why I wrote a book 

924
00:50:20,480 --> 00:50:24,480
about it as well. 
I think a lot of it has to be a 

925
00:50:24,480 --> 00:50:27,560
mindset shift change, especially
for developers. 

926
00:50:27,600 --> 00:50:33,000
First and foremost, imagine that
anytime you do git push origin 

927
00:50:33,000 --> 00:50:36,160
main because you're working in a
trunk based development fashion,

928
00:50:36,160 --> 00:50:37,920
of course you're not doing PRS 
right? 

929
00:50:38,440 --> 00:50:43,760
Every time you do that seven 
times a day, your users are on 

930
00:50:43,800 --> 00:50:46,680
that live system that is going 
to receive that update 20 

931
00:50:46,680 --> 00:50:49,800
minutes later. 
Suddenly, if you were using 

932
00:50:49,800 --> 00:50:53,560
continuous delivery before, it 
can be very paralyzing to think 

933
00:50:53,560 --> 00:50:56,600
about what you're putting in the
pipeline at any given time. 

934
00:50:57,000 --> 00:50:58,560
But it doesn't have to be, 
right? 

935
00:50:58,560 --> 00:51:02,760
So there needs to to be this 
mindset shift of putting 

936
00:51:02,760 --> 00:51:05,440
production as a first class 
citizen every time you're 

937
00:51:05,440 --> 00:51:09,120
writing code and really think 
through before you pick up a new

938
00:51:09,120 --> 00:51:13,200
task or a new user story. 
What commits am I going to put 

939
00:51:13,200 --> 00:51:15,600
in my pipeline that are going to
make that happen? 

940
00:51:15,680 --> 00:51:19,120
And which subsystem do I need to
start from to not break 

941
00:51:19,120 --> 00:51:22,440
production at any point? 
For example, if I have a 

942
00:51:22,480 --> 00:51:25,960
database back in the front end, 
that is going to be probably the

943
00:51:25,960 --> 00:51:28,720
database system that I'm 
starting from if I'm adding 

944
00:51:28,720 --> 00:51:31,960
something new. 
Otherwise, if I deploy the front

945
00:51:31,960 --> 00:51:35,400
end 1st and that's what I start 
developing, there's nothing 

946
00:51:35,400 --> 00:51:37,120
underneath to make the feature 
work. 

947
00:51:37,120 --> 00:51:40,760
It's all going to be broken. 
Every single aspect of your work

948
00:51:40,760 --> 00:51:44,560
needs to be thought as a live 
change in a production 

949
00:51:44,560 --> 00:51:48,680
environment rather than a plan 
for a change that might happen 

950
00:51:48,680 --> 00:51:53,240
somewhere later and might be 
deployed by someone else at some

951
00:51:53,240 --> 00:51:56,680
specified point in time. 
So it feels much more like being

952
00:51:56,680 --> 00:51:59,400
an electrician working on an 
office building that is 

953
00:51:59,400 --> 00:52:01,920
currently in use, right? 
You have to always be careful of

954
00:52:02,240 --> 00:52:05,480
which diversions you're 
installing, how you're going to 

955
00:52:05,480 --> 00:52:09,040
maintain compatibility with your
system, to not disrupt this 

956
00:52:09,040 --> 00:52:12,880
living beast that is production.
And that also includes not only 

957
00:52:12,880 --> 00:52:16,240
functional changes, but also 
security performance. 

958
00:52:16,680 --> 00:52:20,040
There's going to be a lot that 
you you were used to thinking 

959
00:52:20,040 --> 00:52:24,040
about maybe when your changes 
are in staging and you have to 

960
00:52:24,040 --> 00:52:29,360
now anticipate all that thought 
during development, which to me 

961
00:52:29,520 --> 00:52:32,960
is actually really positive. 
It can be overwhelming, but once

962
00:52:32,960 --> 00:52:36,640
you're used to it, it means that
you've fully shifted left. 

963
00:52:37,040 --> 00:52:39,640
All of those quality aspects, 
all of those cross functional 

964
00:52:39,640 --> 00:52:43,080
requirements for example, that 
maybe used to be relegated more 

965
00:52:43,080 --> 00:52:46,120
towards the end of development. 
Yeah. 

966
00:52:46,120 --> 00:52:47,880
So I like the concept that you 
mentioned. 

967
00:52:47,880 --> 00:52:50,640
Always make sure that deploying 
to production is the first class

968
00:52:50,640 --> 00:52:52,640
citizen, right? 
So ensure that you think 

969
00:52:52,640 --> 00:52:55,080
whenever you make change, it's 
going to be straight away go to 

970
00:52:55,080 --> 00:52:57,720
production, right? 
So sometimes this requires you 

971
00:52:57,720 --> 00:53:00,760
to carefully think how you 
actually implement the changes 

972
00:53:01,120 --> 00:53:03,200
and things like that, including 
the shift left. 

973
00:53:03,200 --> 00:53:06,440
I think shift left still kind of
like the correct mindset for 

974
00:53:06,440 --> 00:53:09,280
implementing this, right? 
As much as possible automate as 

975
00:53:09,280 --> 00:53:12,080
well those checks so that you 
know the pipeline can just 

976
00:53:12,080 --> 00:53:14,440
automatically deploy the 
production once everything is 

977
00:53:14,440 --> 00:53:18,080
verified working. 
So 1 aspect that is very trendy 

978
00:53:18,080 --> 00:53:21,040
these days is about AI. 
Anything related to AI that can 

979
00:53:21,040 --> 00:53:22,920
help continuous deployment 
practice. 

980
00:53:23,880 --> 00:53:28,000
I don't know whether it can 
help, maybe it's more something 

981
00:53:28,000 --> 00:53:32,080
to be aware of and slightly 
concerned about. 

982
00:53:32,680 --> 00:53:36,640
So especially for teams that use
continuous deployment today, I 

983
00:53:36,640 --> 00:53:41,480
see that it is very common right
now to just adopt Copilot. 

984
00:53:41,680 --> 00:53:44,120
I'm one of the culprits of this 
by the way. 

985
00:53:44,120 --> 00:53:46,960
I've recently installed it in my
Intellij. 

986
00:53:46,960 --> 00:53:50,120
I just have it generate some 
code for me from time to time 

987
00:53:50,120 --> 00:53:54,520
when I can't be bothered to look
up some configuration or maybe I

988
00:53:54,520 --> 00:53:57,160
can't be bothered to do some 
test coverage. 

989
00:53:57,160 --> 00:54:01,480
I ask it to give me a nice suite
of tests for a certain function.

990
00:54:01,880 --> 00:54:05,080
But yeah, of course, if you're 
continuously deploying, it means

991
00:54:05,080 --> 00:54:09,120
you have to double check, triple
check, quadruple check anything 

992
00:54:09,120 --> 00:54:14,440
that the AI is giving you in 
order to be fairly sure that is 

993
00:54:14,440 --> 00:54:17,200
going through the pipeline. 
So when you re stick that you 

994
00:54:17,200 --> 00:54:21,880
could use this, for example, 
perhaps the AI could generate 

995
00:54:21,880 --> 00:54:25,520
the production code, but maybe 
you should be the one writing 

996
00:54:25,520 --> 00:54:28,560
your tests so that at least 
worst case scenario your 

997
00:54:28,560 --> 00:54:32,240
pipeline will fail. 
And in general, again, all the 

998
00:54:32,400 --> 00:54:36,360
practices that I've recommended 
before as base prerequisites, 

999
00:54:36,360 --> 00:54:40,640
such as test coverage, static 
code analysis, observability, 

1000
00:54:40,840 --> 00:54:44,040
those are also going to be a 
really good safety net. 

1001
00:54:44,600 --> 00:54:48,160
And yeah, you you should really 
double triple check that your 

1002
00:54:48,160 --> 00:54:51,320
pipeline is really going to 
catch any and all types of 

1003
00:54:51,320 --> 00:54:54,880
regressions if your team is 
relying on AI really heavily. 

1004
00:54:55,320 --> 00:54:59,040
That said, it's a great tool. 
It can speed you up even more, 

1005
00:54:59,040 --> 00:55:03,240
but please be careful with it. 
Take it with a grain of salt 

1006
00:55:03,240 --> 00:55:07,560
whatever is spitting out on your
screen because it is very easy 

1007
00:55:07,560 --> 00:55:11,480
to make mistakes if you're just 
get used to not double checking 

1008
00:55:11,480 --> 00:55:14,880
it and just trusting it blindly.
Yeah, I think that's a really 

1009
00:55:14,880 --> 00:55:17,440
great advice, right? 
Because AI, one thing for sure, 

1010
00:55:17,440 --> 00:55:19,240
it can help us turn out more 
code. 

1011
00:55:19,400 --> 00:55:21,960
But more code doesn't always 
mean good, right? 

1012
00:55:21,960 --> 00:55:25,160
Sometimes you have to check, 
especially if you don't have 

1013
00:55:25,160 --> 00:55:28,200
robust pipeline, robust 
automation tests and things like

1014
00:55:28,200 --> 00:55:30,320
that, right? 
So always ensure that the 

1015
00:55:30,320 --> 00:55:33,520
principles actually the one that
matters the most rather than 

1016
00:55:33,760 --> 00:55:36,720
churning out the code. 
So Valentina, it's been a 

1017
00:55:36,720 --> 00:55:39,200
pleasure talking to you. 
As we reach the end of our 

1018
00:55:39,200 --> 00:55:42,000
conversation, I have one last 
question I'd like to ask you, 

1019
00:55:42,600 --> 00:55:44,800
which I call the three technical
leadership wisdom. 

1020
00:55:45,120 --> 00:55:46,960
Just think of it like an advice 
you want to give to the 

1021
00:55:46,960 --> 00:55:48,760
listeners here. 
Maybe if you can share your 

1022
00:55:48,760 --> 00:55:50,440
version? 
Sure. 

1023
00:55:50,440 --> 00:55:54,040
So I thought a bit about it. 
I would say especially relevant 

1024
00:55:54,360 --> 00:55:58,520
to today's episode, we've been 
talking about like really modern

1025
00:55:58,600 --> 00:56:01,040
practices, I think continuous 
deployment. 

1026
00:56:01,480 --> 00:56:05,080
There's nothing faster and more 
modern than that that I know of 

1027
00:56:05,200 --> 00:56:09,280
in software development as like 
ways of working goes, one of the

1028
00:56:09,280 --> 00:56:12,960
main pieces of advice that I 
like to give is many tech leads 

1029
00:56:12,960 --> 00:56:16,480
and developers tend to get sad 
if they can't use all the latest

1030
00:56:16,480 --> 00:56:18,840
and greatest in terms of ways of
working tech. 

1031
00:56:19,200 --> 00:56:23,480
And it's really sad because I 
believe it's not necessarily a 

1032
00:56:23,480 --> 00:56:26,640
must have, right? 
Having everything perfect all 

1033
00:56:26,640 --> 00:56:29,640
the time. 
I think as long as the current 

1034
00:56:29,640 --> 00:56:33,240
practices of the organization 
are improving, that is a good 

1035
00:56:33,240 --> 00:56:35,760
thing in and of itself. 
So don't be worried so much 

1036
00:56:35,760 --> 00:56:38,600
about the status quo, be more 
worried about the trend. 

1037
00:56:38,600 --> 00:56:41,880
Is the trend an improvement or 
are we getting worse? 

1038
00:56:42,520 --> 00:56:44,880
And that's also true for people 
who are doing continuous 

1039
00:56:44,880 --> 00:56:47,840
deployment and really nice and 
modern things. 

1040
00:56:47,960 --> 00:56:51,800
You know, are you getting better
at it every day or are you 

1041
00:56:52,080 --> 00:56:55,520
slowly getting worse even though
you've enabled it some time ago?

1042
00:56:56,000 --> 00:56:59,760
So worry about the trend would 
be my first piece of advice. 

1043
00:57:00,200 --> 00:57:05,120
The second one is sometimes as 
developers and tech leads, we 

1044
00:57:05,120 --> 00:57:07,560
get emotionally attached to 
solutions. 

1045
00:57:07,920 --> 00:57:11,560
Again, I think of this is a bit 
of a pitfall and I believe our 

1046
00:57:11,560 --> 00:57:14,400
job is maybe more about 
informing. 

1047
00:57:14,400 --> 00:57:18,360
So informing of all different 
options and then let's take 

1048
00:57:18,360 --> 00:57:20,960
holders determine what is their 
preferred one. 

1049
00:57:21,080 --> 00:57:24,520
As long as they are aware of the
pros and cons and they 

1050
00:57:24,520 --> 00:57:27,240
acknowledge any risks, let them 
do it. 

1051
00:57:27,240 --> 00:57:32,840
Don't take it too personally. 
And finally, yeah, my main piece

1052
00:57:32,840 --> 00:57:36,320
of advice is just if you're a 
tech leader like me, just trust 

1053
00:57:36,520 --> 00:57:38,000
the people that you're working 
with. 

1054
00:57:38,480 --> 00:57:42,040
Trust them to have thought about
the edge cases, trust them to do

1055
00:57:42,040 --> 00:57:45,080
their spikes, trust them that 
they're working and doing the 

1056
00:57:45,080 --> 00:57:47,920
best they can. 
So don't micromanage if you're a

1057
00:57:47,920 --> 00:57:50,720
tech kid, would be my final 
piece of advice. 

1058
00:57:51,400 --> 00:57:54,520
Really beautiful advice, right? 
So I, I particularly like the 

1059
00:57:54,520 --> 00:57:56,120
first one, worry about the 
trend, right? 

1060
00:57:56,160 --> 00:57:57,800
The direction that you're going,
right? 

1061
00:57:57,800 --> 00:58:01,080
Sometimes you can take some more
gradual steps rather than a big 

1062
00:58:01,080 --> 00:58:03,840
bangs approach, right? 
But still, if you're going to 

1063
00:58:03,840 --> 00:58:06,120
the right direction, I think 
that's the important thing. 

1064
00:58:06,560 --> 00:58:09,160
So Valentina, if people love 
this conversation, they want to 

1065
00:58:09,160 --> 00:58:11,520
check out more your resources. 
Is there a place where they can 

1066
00:58:11,520 --> 00:58:14,720
find you online? 
Yeah, so I'm mostly posting on 

1067
00:58:14,720 --> 00:58:16,920
LinkedIn, so you can follow me 
there. 

1068
00:58:17,160 --> 00:58:19,160
Valentina Servila, feel free to 
write. 

1069
00:58:20,080 --> 00:58:25,040
I used to be on Twitter slash X,
but now I've left, so I migrated

1070
00:58:25,040 --> 00:58:27,520
to Blue Sky. 
You can find me there, but I 

1071
00:58:27,520 --> 00:58:29,480
don't post as much as on 
LinkedIn. 

1072
00:58:29,480 --> 00:58:32,760
So yeah, mainly LinkedIn, maybe 
Blue Sky or just drop me an 

1073
00:58:32,760 --> 00:58:34,240
e-mail. 
You'll find the address in the 

1074
00:58:34,240 --> 00:58:36,240
book. 
Thank you so much for your time.

1075
00:58:36,240 --> 00:58:38,760
I'm sure people learn a lot 
about continuous deployment 

1076
00:58:38,760 --> 00:58:41,840
today, so hopefully people get 
to adopt these practices more 

1077
00:58:41,840 --> 00:58:43,320
and more. 
Thank you.