1
00:00:07,117 --> 00:00:09,567
- Finally, we're ready
to release on demand.

2
00:00:09,567 --> 00:00:11,872
Let's talk about what we mean by that.

3
00:00:11,872 --> 00:00:14,241
We talked about cadence and
synchronization at length,

4
00:00:14,241 --> 00:00:16,268
I definitely belabored the point.

5
00:00:16,268 --> 00:00:18,509
We need cadence and
synchronization to make routine

6
00:00:18,509 --> 00:00:19,832
that which can be routine.

7
00:00:19,832 --> 00:00:22,136
We need cadence and
synchronization to assure

8
00:00:22,136 --> 00:00:25,507
that we can do objective
evaluation of working systems,

9
00:00:25,507 --> 00:00:27,891
either at this level, or at this level.

10
00:00:27,891 --> 00:00:29,025
We need those things.

11
00:00:29,025 --> 00:00:30,836
That's the way we manage
our development environment.

12
00:00:30,836 --> 00:00:32,653
We call that develop on cadence.

13
00:00:32,653 --> 00:00:35,512
But we want to decouple
that from this other thing,

14
00:00:35,512 --> 00:00:39,459
which is that it may be
possible to release here.

15
00:00:39,459 --> 00:00:41,293
It may be that I decide to release at only

16
00:00:41,293 --> 00:00:42,296
these boundaries.

17
00:00:42,296 --> 00:00:44,984
More likely, I have a
completely decoupled world.

18
00:00:44,984 --> 00:00:47,265
My development cadence and
my release cases are unalike.

19
00:00:47,265 --> 00:00:50,016
I don't remember for whatever
reason, but we released

20
00:00:50,016 --> 00:00:52,877
the last version of Safe, I
think it was like June 26,

21
00:00:52,877 --> 00:00:55,369
I have no idea if that was
on a sprint boundary or not,

22
00:00:55,369 --> 00:00:56,547
it was just a milestone.

23
00:00:56,547 --> 00:00:57,613
That didn't matter.

24
00:00:57,613 --> 00:01:00,941
We approached it with a solid
and predictable cadence,

25
00:01:00,941 --> 00:01:03,245
but when the time came, we released it.

26
00:01:03,245 --> 00:01:05,080
We were able to do that
because we had used

27
00:01:05,080 --> 00:01:07,616
these practices to get to that point.

28
00:01:07,616 --> 00:01:09,240
So I want to make sure that we separate

29
00:01:09,240 --> 00:01:10,260
those concerns.

30
00:01:10,260 --> 00:01:12,055
And by the way, you
can release on cadence.

31
00:01:12,055 --> 00:01:13,571
It can be very handy to do that.

32
00:01:13,571 --> 00:01:15,597
I know some larger
enterprises that deliver

33
00:01:15,597 --> 00:01:19,245
big time infrastructure
systems, and they've moved

34
00:01:19,245 --> 00:01:20,824
from once a year to quarterly.

35
00:01:20,824 --> 00:01:21,827
That's great.

36
00:01:21,827 --> 00:01:23,379
Their customers are saying
we don't want it more

37
00:01:23,379 --> 00:01:24,429
frequently than that.

38
00:01:24,429 --> 00:01:27,843
We all have examples
of continuous delivery

39
00:01:27,843 --> 00:01:30,103
and continuous release.

40
00:01:30,103 --> 00:01:32,468
I mean my iPhone continuously releases.

41
00:01:32,468 --> 00:01:35,482
Over the weekend, there was upgrades to my

42
00:01:35,482 --> 00:01:37,973
Apple router software,
so I naturally pressed

43
00:01:37,973 --> 00:01:39,146
the upgrade button.

44
00:01:39,146 --> 00:01:40,141
And guess what?

45
00:01:40,141 --> 00:01:41,150
It took down the network.

46
00:01:41,150 --> 00:01:42,924
So there's still risk, even in that model.

47
00:01:42,924 --> 00:01:45,270
So we want to make sure that
we separate those concerns.

48
00:01:45,270 --> 00:01:49,347
We do develop on cadence,
but release on demand.

49
00:01:49,347 --> 00:01:53,272
What's more, releasing is
not a monolithic thing.

50
00:01:53,272 --> 00:01:55,960
Virtually every system
that I'm aware of consists

51
00:01:55,960 --> 00:01:57,624
of releasable elements.

52
00:01:57,624 --> 00:02:01,122
And frankly, the more
releasable elements you have,

53
00:02:01,122 --> 00:02:03,892
the more quickly you can
move to continuous delivery.

54
00:02:03,892 --> 00:02:06,390
When Google says they
release x times a minute,

55
00:02:06,390 --> 00:02:08,694
second, microsecond,
whatever, I don't know what

56
00:02:08,694 --> 00:02:10,616
their current stats are,
they're not releasing

57
00:02:10,616 --> 00:02:13,325
the entire system, they're
releasing an element

58
00:02:13,325 --> 00:02:14,648
of that system.

59
00:02:14,648 --> 00:02:17,098
Even our simple Safe
website has a big picture.

60
00:02:17,098 --> 00:02:19,232
We don't want to update
that very often because

61
00:02:19,232 --> 00:02:21,304
people don't like it when
the big picture changes

62
00:02:21,304 --> 00:02:23,331
very often, they're in
the middle of a large

63
00:02:23,331 --> 00:02:25,463
implementation, that big
picture is integrated

64
00:02:25,463 --> 00:02:27,251
into this course where I'm delivering.

65
00:02:27,251 --> 00:02:29,048
If I change that big picture tomorrow,

66
00:02:29,048 --> 00:02:30,947
the courseware is immediately obsolete.

67
00:02:30,947 --> 00:02:33,208
That's not gonna work.

68
00:02:33,208 --> 00:02:34,847
I have really some constraints
about how frequently

69
00:02:34,847 --> 00:02:36,344
we release Safe.

70
00:02:36,344 --> 00:02:40,013
However, if there is a defect or a bug,

71
00:02:40,013 --> 00:02:41,805
we could fix it now.

72
00:02:41,805 --> 00:02:43,212
There are people sitting
in this room with me

73
00:02:43,212 --> 00:02:45,171
right now that if we
logged in and found a bug,

74
00:02:45,171 --> 00:02:47,007
they could fix that instantly.

75
00:02:47,007 --> 00:02:48,973
If there's a security flaw
or a patch, within an hour

76
00:02:48,973 --> 00:02:51,123
we can fix that, so there
are different cycles

77
00:02:51,123 --> 00:02:53,022
of different types of things.

78
00:02:53,022 --> 00:02:55,736
Now, we blog kind of asynchronously.

79
00:02:55,736 --> 00:02:57,763
We release articles
asynchronously, so we have

80
00:02:57,763 --> 00:03:01,175
lots of ways to deliver
value without changing

81
00:03:01,175 --> 00:03:03,949
the big picture, because we're architected

82
00:03:03,949 --> 00:03:04,950
for releasability.

83
00:03:04,950 --> 00:03:06,168
Big systems are.

84
00:03:06,168 --> 00:03:08,643
The SAAS companies that I'm
familiar with most closely

85
00:03:08,643 --> 00:03:12,543
have gone through to get
to the point from a major

86
00:03:12,543 --> 00:03:16,003
big bang release every six
months, to continuous delivery,

87
00:03:16,003 --> 00:03:20,291
they've gone through two
and three significant

88
00:03:20,291 --> 00:03:21,632
architectural refactors.

89
00:03:21,632 --> 00:03:25,770
If you're going to release
frequently, you have to

90
00:03:25,770 --> 00:03:28,117
design for releasability,
and that's an architectural

91
00:03:28,117 --> 00:03:30,058
concern a little outside the scope of what

92
00:03:30,058 --> 00:03:31,784
we're talking about here.

93
00:03:31,784 --> 00:03:33,557
We call these things,
just to give 'em a label,

94
00:03:33,557 --> 00:03:35,047
a value streamlet.

95
00:03:35,047 --> 00:03:37,397
So if we think about our
value stream, the value stream

96
00:03:37,397 --> 00:03:40,320
of Safe is delivering
hopefully great intellectual

97
00:03:40,320 --> 00:03:43,404
property to the end user,
streamlets include things

98
00:03:43,404 --> 00:03:46,378
like the blog that has
its own release cycle.

99
00:03:46,378 --> 00:03:48,320
It still has release
governance, we don't just shove

100
00:03:48,320 --> 00:03:50,026
a thing on the blog when
somebody thinks it's a

101
00:03:50,026 --> 00:03:52,352
good idea, but it's entirely
different governance

102
00:03:52,352 --> 00:03:53,866
than we do on an article.

103
00:03:53,866 --> 00:03:55,594
So let's say this is an article.

104
00:03:55,594 --> 00:03:57,341
Articles have to go
through fairly extensive

105
00:03:57,341 --> 00:03:58,688
peer review.

106
00:03:58,688 --> 00:04:00,155
The graphics have to be rendered.

107
00:04:00,155 --> 00:04:01,376
We have to create high resolution images,

108
00:04:01,376 --> 00:04:03,061
because it's eventually
gonna appear in the book.

109
00:04:03,061 --> 00:04:04,582
So that's a different
release cycle, and as I

110
00:04:04,582 --> 00:04:06,473
mentioned, big picture
is the slowest of all.

111
00:04:06,473 --> 00:04:08,757
Every system has that potential.

112
00:04:08,757 --> 00:04:11,018
You're either already able
to release it, but you

113
00:04:11,018 --> 00:04:13,557
just hadn't thought about
it that way, or you start

114
00:04:13,557 --> 00:04:15,536
to architect now for releasability.

115
00:04:15,536 --> 00:04:17,546
And now when we think back a little bit,

116
00:04:17,546 --> 00:04:19,570
just a few modules ago about how you

117
00:04:19,570 --> 00:04:22,090
form agile teams, how
about you form a team

118
00:04:22,090 --> 00:04:23,648
so it can release something.

119
00:04:23,648 --> 00:04:26,077
You form a feature team
because it releases features

120
00:04:26,077 --> 00:04:28,960
independently, how about
agile release trains

121
00:04:28,960 --> 00:04:30,112
in a large organization?

122
00:04:30,112 --> 00:04:32,541
Obviously they want to release,
it's in their various names.

123
00:04:32,541 --> 00:04:35,411
How about creating large
solutions where specific

124
00:04:35,411 --> 00:04:37,728
agile release trains can
release their piece of that

125
00:04:37,728 --> 00:04:40,202
large solution at the
large solutions level?

126
00:04:40,202 --> 00:04:42,933
So we have to architect and
design for releasability.

127
00:04:42,933 --> 00:04:45,706
We also recognize that
continuous delivery runs

128
00:04:45,706 --> 00:04:47,456
into a few barriers.

129
00:04:47,456 --> 00:04:49,589
There are some things
that we need to do that

130
00:04:49,589 --> 00:04:53,767
simply aren't economically
efficient every day.

131
00:04:53,767 --> 00:04:57,184
One example is user acceptance testing.

132
00:04:57,184 --> 00:04:59,360
Another example is it
might be a tough time

133
00:04:59,360 --> 00:05:01,728
for me to get my hands
on all the tools I need

134
00:05:01,728 --> 00:05:03,925
to be able to test that
my infusion pump meets

135
00:05:03,925 --> 00:05:05,760
all it's non functional requirements.

136
00:05:05,760 --> 00:05:08,874
Does it work under heat and load?

137
00:05:08,874 --> 00:05:11,477
Does it work under certain
kind of failure modes?

138
00:05:11,477 --> 00:05:13,418
Are all the air conditions addressed?

139
00:05:13,418 --> 00:05:16,585
If I crash the processor at any point,

140
00:05:17,493 --> 00:05:19,688
will it recover in such
a way as it won't overrun

141
00:05:19,688 --> 00:05:21,696
infusion and kill the patient?

142
00:05:21,696 --> 00:05:23,423
All of those things--I
may not be able to do that

143
00:05:23,423 --> 00:05:26,088
every single day, so I may
have to batch some of this.

144
00:05:26,088 --> 00:05:28,435
Sometimes I have to get
into a lab to test my

145
00:05:28,435 --> 00:05:30,613
avionics with the airplane manufacturer.

146
00:05:30,613 --> 00:05:31,974
I can't do that every day.

147
00:05:31,974 --> 00:05:34,688
And sometimes I have to get
documentation sign offs,

148
00:05:34,688 --> 00:05:36,714
official meetings and assignments.

149
00:05:36,714 --> 00:05:38,566
As we talk about compliance
a little bit later,

150
00:05:38,566 --> 00:05:40,832
we're gonna push all of
those things back as far

151
00:05:40,832 --> 00:05:43,498
in the life cycle as we
possibly can, but the

152
00:05:43,498 --> 00:05:46,037
net result is still
the fact that there are

153
00:05:46,037 --> 00:05:48,554
things to do that are
not economically viable

154
00:05:48,554 --> 00:05:49,728
every single day.

155
00:05:49,728 --> 00:05:52,565
Well, so we have to communicate
release communications.

156
00:05:52,565 --> 00:05:56,064
We do release notes when
we update even a toolkit.

157
00:05:56,064 --> 00:05:58,240
Do I do a release not
every day in case I might

158
00:05:58,240 --> 00:05:59,413
release it that day?

159
00:05:59,413 --> 00:06:00,437
No, that's silly.

160
00:06:00,437 --> 00:06:02,908
I only do the release
notes when I'm prepared

161
00:06:02,908 --> 00:06:03,913
to release.

162
00:06:03,913 --> 00:06:05,512
Same goes for certain
other types of things.

163
00:06:05,512 --> 00:06:07,861
The final bomb is to prepare to finalize.

164
00:06:07,861 --> 00:06:09,074
And you know what these things are.

165
00:06:09,074 --> 00:06:10,424
Am I gonna train people in stuff I haven't

166
00:06:10,424 --> 00:06:11,257
released yet?

167
00:06:11,257 --> 00:06:12,090
No.

168
00:06:12,090 --> 00:06:12,923
So I'm gonna wait for that.

169
00:06:12,923 --> 00:06:15,752
So there is some batching
of certain types of

170
00:06:15,752 --> 00:06:18,890
economics based upon
the u-curve optimization

171
00:06:18,890 --> 00:06:22,261
of the frequency versus
cost of doing that thing.

172
00:06:22,261 --> 00:06:24,117
And that brings us to
the point where we can

173
00:06:24,117 --> 00:06:26,483
release, very frequently.

174
00:06:26,483 --> 00:06:30,409
I heard one person call
it 'continuish' delivery,

175
00:06:30,409 --> 00:06:33,886
because it's largely
continuing, but still has

176
00:06:33,886 --> 00:06:37,364
some kind of frequency or
cadence or pace of release

177
00:06:37,364 --> 00:06:39,473
that's other than every
single hour, every single day.

178
00:06:39,473 --> 00:06:42,676
And for most of us, that's
kind of a more practical event.

179
00:06:42,676 --> 00:06:45,554
Tell me about your
continuous deliver pipeline,

180
00:06:45,554 --> 00:06:47,668
or pretend like I could
hear if you told me.

181
00:06:47,668 --> 00:06:49,673
Take a minute, and take a note.

182
00:06:49,673 --> 00:06:51,529
It's not an easy thing to implement the

183
00:06:51,529 --> 00:06:52,913
continuous delivery pipeline.

184
00:06:52,913 --> 00:06:55,476
You've seen it here, you've
seen the elements of it.

185
00:06:55,476 --> 00:06:56,840
You've seen continuous
exploration, you've seen

186
00:06:56,840 --> 00:06:59,058
continuous integration, you've
seen continuous deployment,

187
00:06:59,058 --> 00:07:00,852
you've seen release on demand.

188
00:07:00,852 --> 00:07:02,494
It's a non-trivial feat.

189
00:07:02,494 --> 00:07:04,646
So if your organization
is moving towards dev ops,

190
00:07:04,646 --> 00:07:06,330
you're gonna need lean and agile to do it.

191
00:07:06,330 --> 00:07:07,570
You can't separate the two.

192
00:07:07,570 --> 00:07:09,937
You can't do waterfall
dev ops, you have to have

193
00:07:09,937 --> 00:07:11,460
small batches, you have
to have automation.

194
00:07:11,460 --> 00:07:13,460
You have to bust everything
up into small batches

195
00:07:13,460 --> 00:07:15,422
that move through the system more quickly.

196
00:07:15,422 --> 00:07:16,553
Take a moment.

197
00:07:16,553 --> 00:07:17,850
What are some improvements
that you could make?

198
00:07:17,850 --> 00:07:19,220
Just jot down a few.

199
00:07:19,220 --> 00:07:21,524
In five minutes or so, I
bet you will have identified

200
00:07:21,524 --> 00:07:23,407
some things that you
could do better to be able

201
00:07:23,407 --> 00:07:27,197
to help facilitate
migration to your ability

202
00:07:27,197 --> 00:07:29,711
to provide more continuous releases.