WEBVTT

1
00:00.000 --> 00:04.200
So now let's talk a little bit about the software development lifecycle and

2
00:04.200 --> 00:11.550
critically how a continuous integration and continuous deployment pipeline

3
00:11.550 --> 00:12.000
works.

4
00:12.000 --> 00:17.000
This is very often called a DevOps pipeline.

5
00:17.000 --> 00:22.640
But really when we talk about a DevOps pipeline, we are literally meaning a CI

6
00:22.640 --> 00:26.000
CD pipeline, continuous integration and continuous deployment.

7
00:26.000 --> 00:30.000
First of all, what's the plan? What is it that we're trying to do?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

7
00:26.000 --> 00:30.000
First of all, what's the plan? What is it that we're trying to do?

8
00:30.000 --> 00:35.770
The software development lifecycle is kind of broken down like an infinity

9
00:35.770 --> 00:40.000
symbol because the amount of work we have to do never stops.

10
00:40.000 --> 00:44.000
It just keeps on going, doesn't it?

11
00:44.000 --> 00:48.000
You start off by planning what it is that we want to do.

12
00:48.000 --> 00:52.000
Think about it. What's the goal here? What are we trying to do?

13
00:52.000 --> 00:56.900
When we're talking about microservices and when we're talking about daily

14
00:56.900 --> 01:02.000
deployments, these are not big things that we're planning.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:56.900 --> 01:02.000
deployments, these are not big things that we're planning.

15
01:02.000 --> 01:07.120
These are going to be really, really small things like change the font, change

16
01:07.120 --> 01:12.480
the color, make this one tiny little thing work the way we thought it would

17
01:12.480 --> 01:13.000
work.

18
01:13.000 --> 01:22.730
We're not really rolling out massive features. If we were trying to roll out

19
01:22.730 --> 01:25.000
massive features, we would then break them down into the smallest units of work

20
01:25.000 --> 01:28.000
that we need to accomplish in order to get to the feature.

21
01:28.000 --> 01:32.850
And that's what we're talking about delivering right here, one of these tiny
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
01:28.000 --> 01:32.850
And that's what we're talking about delivering right here, one of these tiny

22
01:32.850 --> 01:34.000
units of work.

23
01:34.000 --> 01:39.900
So after we've done planning what it is that we want to do, we're going to then

24
01:39.900 --> 01:41.000
build it.

25
01:41.000 --> 01:46.650
The code writer themselves are going to go through the process of actually

26
01:46.650 --> 01:51.000
writing the code and then checking it into source control.

27
01:51.000 --> 01:54.830
Ultimately, when they're ready to rock and roll, they'll submit something

28
01:54.830 --> 01:56.000
called a pull request.

29
01:56.000 --> 02:00.760
The pull request will inevitably kick off the CI/CD pipeline, which we're going
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:56.000 --> 02:00.760
The pull request will inevitably kick off the CI/CD pipeline, which we're going

30
02:00.760 --> 02:09.000
to talk about next, which ultimately delivers to infrastructure.

31
02:09.000 --> 02:11.000
And then what happens?

32
02:11.000 --> 02:16.000
Once it's in the infant structure, we monitor it.

33
02:16.000 --> 02:23.000
And then we, let's go to red here, collect feedback.

34
02:23.000 --> 02:29.000
Did it work? Did it not work? What could be improved on, if anything?

35
02:29.000 --> 02:32.000
If it did work, how do we move on to the next step?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
02:29.000 --> 02:32.000
If it did work, how do we move on to the next step?

36
02:32.000 --> 02:38.000
And that is what starts the process all over again.

37
02:38.000 --> 02:45.150
It's either going to fail, at which point we fail fast, that's the term here,

38
02:45.150 --> 02:50.000
of getting to the correct state that we want to be in as quickly as possible.

39
02:50.000 --> 02:55.410
Thank goodness we only shipped a small update, so we only need to ship a small

40
02:55.410 --> 02:56.000
fix.

41
02:56.000 --> 03:03.000
Or it did work, and we want to iterate on that and make it work even better.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
02:56.000 --> 03:03.000
Or it did work, and we want to iterate on that and make it work even better.

42
03:03.000 --> 03:08.000
There is a third possibility, and that's that there's no change at all.

43
03:08.000 --> 03:12.000
We're not really looking to measure success anywhere here.

44
03:12.000 --> 03:15.000
This may have just been a quality of life thing that we changed.

45
03:15.000 --> 03:21.220
But the point is, is that this software development life cycle keeps going, and

46
03:21.220 --> 03:22.000
it just keeps going.

47
03:22.000 --> 03:28.000
So when we have microservices, we have small applications to begin with.

48
03:28.000 --> 03:32.600
Then, when we're doing this development work and we're developing small
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
03:28.000 --> 03:32.600
Then, when we're doing this development work and we're developing small

49
03:32.600 --> 03:38.000
incremental changes and shipping that, the deployment time that we're usually

50
03:38.000 --> 03:45.050
looking at is anywhere from one to three weeks to complete this full life cycle

51
03:45.050 --> 03:48.000
from plan all the way through feedback.

52
03:48.000 --> 03:51.000
We should be expecting this to be one to three weeks.

53
03:51.000 --> 03:56.300
So if this is our first one to three weeks sprint, that's what we usually call

54
03:56.300 --> 04:02.040
these, then somewhere in the mix, we'll have another one to three weeks sprint,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
03:56.300 --> 04:02.040
these, then somewhere in the mix, we'll have another one to three weeks sprint,

55
04:02.040 --> 04:05.000
and then another one to three weeks sprint.

56
04:05.000 --> 04:10.000
In all of this work is happening concurrently on our application.

57
04:10.000 --> 04:13.000
Maybe this is the shopping cart.

58
04:13.000 --> 04:16.000
Maybe this is the search bar.

59
04:16.000 --> 04:21.000
Maybe this is something with logistics down here.

60
04:21.000 --> 04:26.930
So the full application like Amazon.com could be experiencing updates every

61
04:26.930 --> 04:28.000
single day.

62
04:28.000 --> 04:33.640
But the individual microservices might only see things on a one to three week
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
04:28.000 --> 04:33.640
But the individual microservices might only see things on a one to three week

63
04:33.640 --> 04:35.000
update cycle.

64
04:35.000 --> 04:40.090
Do you see what I mean when I say that DevOps is really more of a lifestyle and

65
04:40.090 --> 04:42.000
a management practice?

66
04:42.000 --> 04:47.500
And it's really about managing how the flow of work happens and how it

67
04:47.500 --> 04:50.000
interacts with each other.

68
04:50.000 --> 04:56.020
Well, this does beg the question that we zoom in right here of going from the

69
04:56.020 --> 05:01.000
persons, the developers laptop to running on the infrastructure itself.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
04:56.020 --> 05:01.000
persons, the developers laptop to running on the infrastructure itself.

70
05:01.000 --> 05:06.190
I did elaborate in the last video that that was one of the biggest pain points

71
05:06.190 --> 05:09.000
that we have or a couple of videos ago.

72
05:09.000 --> 05:12.350
That's one of the biggest pain points that we have that it's stopped the

73
05:12.350 --> 05:13.000
process.

74
05:13.000 --> 05:18.270
So knowing that that stopped the process and understanding that we really want

75
05:18.270 --> 05:24.120
to have new update shipped every week, two or three, we don't have, we can't

76
05:24.120 --> 05:28.450
stop the process to wait for a server to be deployed or for the network to be

77
05:28.450 --> 05:29.000
updated.

78
05:29.000 --> 05:31.000
So what do we do?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
05:29.000 --> 05:31.000
So what do we do?

79
05:31.000 --> 05:36.000
We use CI/CD pipelines and infrastructure as code.

80
05:36.000 --> 05:37.000
Let me show you.

81
05:37.000 --> 05:41.000
I've brought up something here called a GitHub action.

82
05:41.000 --> 05:46.660
The idea with a GitHub action among other things is to actually use continuous

83
05:46.660 --> 05:50.000
integration and continuous deployment.

84
05:50.000 --> 05:56.640
With this, we automate, we automate the building of our code and the delivery

85
05:56.640 --> 06:00.000
of that code to the infrastructure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
05:56.640 --> 06:00.000
of that code to the infrastructure.

86
06:00.000 --> 06:05.810
This is automatically happening as soon as the software developer checks in

87
06:05.810 --> 06:10.360
their code in the source control or requests that it gets merged into a

88
06:10.360 --> 06:12.000
different branch.

89
06:12.000 --> 06:19.530
This can automatically kick off a series of systems that will build, test, and

90
06:19.530 --> 06:23.000
deliver all of our code for us automatically.

91
06:23.000 --> 06:33.310
Continuous integration is making sure our code integrates successfully into our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
06:23.000 --> 06:33.310
Continuous integration is making sure our code integrates successfully into our

92
06:33.310 --> 06:35.000
ex...

93
06:35.000 --> 06:37.000
Oh, at least spell that a little bit better.

94
06:37.000 --> 06:43.000
Our existing code base.

95
06:43.000 --> 06:48.910
If we write some code to update something like the shopping cart, that's not

96
06:48.910 --> 06:53.000
allowed to break other parts of the application.

97
06:53.000 --> 07:01.340
The CI makes sure that the full application continues to work after we have the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
06:53.000 --> 07:01.340
The CI makes sure that the full application continues to work after we have the

98
07:01.340 --> 07:05.000
code, the new code integrated into the current code base.

99
07:05.000 --> 07:11.000
When CI/CD pipelines fail, nine times out of ten, they fail here.

100
07:11.000 --> 07:17.030
Something about the way the developer wrote the code or something about their

101
07:17.030 --> 07:23.000
environment broke its ability to integrate into the existing code base.

102
07:23.000 --> 07:27.760
So if it breaks, that new code never gets delivered to the production

103
07:27.760 --> 07:29.000
environment.

104
07:29.000 --> 07:32.000
The production environment stays on the whole time.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

104
07:29.000 --> 07:32.000
The production environment stays on the whole time.

105
07:32.000 --> 07:38.000
Right here on the screen, you can see where I defined a build stage.

106
07:38.000 --> 07:40.000
This is what we're trying to do.

107
07:40.000 --> 07:44.000
We're trying to build the code and make sure that it integrates successfully.

108
07:44.000 --> 07:49.540
I define things like, "Hey, when you do this, when you actually go to build my

109
07:49.540 --> 07:53.000
code, do it on a Ubuntu server."

110
07:53.000 --> 07:58.000
GitHub behind the scene actually spins up a Ubuntu server just to do it.

111
07:58.000 --> 08:04.250
It copies the code, it installs the Node.js version that I specified right here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
07:58.000 --> 08:04.250
It copies the code, it installs the Node.js version that I specified right here

112
08:04.250 --> 08:06.000
, version 16.

113
08:06.000 --> 08:10.000
This repos a few years old at this point, I think 16 is now deprecated.

114
08:10.000 --> 08:16.000
It builds my Node.js or my JavaScript application.

115
08:16.000 --> 08:23.210
It copies all of the built code, it zips it up, and it uploads it into an

116
08:23.210 --> 08:27.000
environment that we can then deliver later.

117
08:27.000 --> 08:32.000
One of the other things that it does right here is ARM templates.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
08:27.000 --> 08:32.000
One of the other things that it does right here is ARM templates.

118
08:32.000 --> 08:34.000
ARM templates is an Azure thing.

119
08:34.000 --> 08:40.310
The idea with an ARM template is we check to make sure we actually have the

120
08:40.310 --> 08:43.000
infrastructure that we need to deploy on.

121
08:43.000 --> 08:48.680
If we don't have the correct number of web servers or the correct configuration

122
08:48.680 --> 08:50.000
of those web servers,

123
08:50.000 --> 08:55.260
the ARM template will connect into Azure and automatically deploy these virtual

124
08:55.260 --> 08:56.000
machines.

125
08:56.000 --> 08:59.000
This again is a big part of integration.

126
08:59.000 --> 09:04.300
Before I even attempt to deliver my code to its end target, the question is, do
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
08:59.000 --> 09:04.300
Before I even attempt to deliver my code to its end target, the question is, do

127
09:04.300 --> 09:06.000
I even have end targets?

128
09:06.000 --> 09:11.000
If not, build them automatically in Azure.

129
09:11.000 --> 09:15.000
Again, this happens automatically.

130
09:15.000 --> 09:20.050
No manager is logging into Azure and deploying virtual machines, no software

131
09:20.050 --> 09:25.000
developer is stopped waiting on these virtual machines to be deployed.

132
09:25.000 --> 09:30.160
As soon as the software developer has done their work and pushed this code into
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
09:25.000 --> 09:30.160
As soon as the software developer has done their work and pushed this code into

133
09:30.160 --> 09:34.000
GitHub, this pipeline is automatically running,

134
09:34.000 --> 09:39.000
building the application itself, and deploying the virtual machines.

135
09:39.000 --> 09:44.000
Once that's done, we will say CI has succeeded.

136
09:44.000 --> 09:49.020
We didn't run into any errors while trying to build the application, nor did we

137
09:49.020 --> 09:54.000
run into any errors building out infrastructure to run the application.

138
09:54.000 --> 10:01.300
Once CI has succeeded, we move into continuous deployment, sometimes also known
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

138
09:54.000 --> 10:01.300
Once CI has succeeded, we move into continuous deployment, sometimes also known

139
10:01.300 --> 10:03.000
as continuous delivery.

140
10:03.000 --> 10:10.760
Here, under the deploy section, the big thing we see is we download the

141
10:10.760 --> 10:14.000
application that we just built,

142
10:14.000 --> 10:20.160
and when we scroll down some more, we deploy that application to the Azure web

143
10:20.160 --> 10:22.000
apps that were deployed.

144
10:22.000 --> 10:26.000
Or the Azure servers or virtual machines that we deploy.

145
10:26.000 --> 10:28.000
That's what we're talking about here.

146
10:28.000 --> 10:34.290
So at this point, the developer pushed their code into GitHub, and within a few
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

146
10:28.000 --> 10:34.290
So at this point, the developer pushed their code into GitHub, and within a few

147
10:34.290 --> 10:41.440
minutes, it's automatically built, tested, and up and running on an Azure

148
10:41.440 --> 10:43.000
virtual machine set.

149
10:43.000 --> 10:45.000
Now, I can't stress this enough.

150
10:45.000 --> 10:48.000
This is a very basic CI/CD pipeline.

151
10:48.000 --> 10:54.090
Absolutely anything that you can dream of can be configured with a CI/CD

152
10:54.090 --> 10:55.000
pipeline.

153
10:55.000 --> 10:59.410
If you need to adjust DNS settings and load balancing settings and firewall

154
10:59.410 --> 11:06.160
settings, or deploy, you can even deploy fully new virtual Cisco firewalls or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
10:59.410 --> 11:06.160
settings, or deploy, you can even deploy fully new virtual Cisco firewalls or

155
11:06.160 --> 11:11.000
Cisco CSR 1000 V's and configure them in this way as part of your pipeline.

156
11:11.000 --> 11:17.440
Your whole infrastructure can be automated in a pipeline to facilitate the

157
11:17.440 --> 11:23.000
delivery of the development or the delivery of the application.

158
11:23.000 --> 11:27.000
Again, dev ops.

159
11:27.000 --> 11:33.520
The operations are there to facilitate the dev, the dev work, because
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
11:27.000 --> 11:33.520
The operations are there to facilitate the dev, the dev work, because

160
11:33.520 --> 11:38.420
ultimately the people who use dev ops, the product that they're selling is

161
11:38.420 --> 11:40.000
their application.

162
11:40.000 --> 11:44.000
That's the revenue generating thing. It's the most important thing.

163
11:44.000 --> 11:50.260
So everything should be done to help facilitate the delivery of new updates in

164
11:50.260 --> 11:51.000
code.

165
11:51.000 --> 11:56.000
CI/CD is the way that we go about doing that.

166
11:56.000 --> 12:00.000
But wait a minute. We're here to talk about security, aren't we?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

166
11:56.000 --> 12:00.000
But wait a minute. We're here to talk about security, aren't we?

167
12:00.000 --> 12:05.090
Maybe in the next video we'll start to talk about what dev sec ops is and where

168
12:05.090 --> 12:10.000
it fits in to this whole picture of software development and delivery.