So now let's talk a little bit about the software development lifecycle and
critically how a continuous integration and continuous deployment pipeline
works.
This is very often called a DevOps pipeline.
But really when we talk about a DevOps pipeline, we are literally meaning a CI
CD pipeline, continuous integration and continuous deployment.
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
First of all, what's the plan? What is it that we're trying to do?
The software development lifecycle is kind of broken down like an infinity
symbol because the amount of work we have to do never stops.
It just keeps on going, doesn't it?
You start off by planning what it is that we want to do.
Think about it. What's the goal here? What are we trying to do?
When we're talking about microservices and when we're talking about daily
deployments, these are not big things that we're planning. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
deployments, these are not big things that we're planning.
These are going to be really, really small things like change the font, change
the color, make this one tiny little thing work the way we thought it would
work.
We're not really rolling out massive features. If we were trying to roll out
massive features, we would then break them down into the smallest units of work
that we need to accomplish in order to get to the feature.
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
And that's what we're talking about delivering right here, one of these tiny
units of work.
So after we've done planning what it is that we want to do, we're going to then
build it.
The code writer themselves are going to go through the process of actually
writing the code and then checking it into source control.
Ultimately, when they're ready to rock and roll, they'll submit something
called a pull request.
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
The pull request will inevitably kick off the CI/CD pipeline, which we're going
to talk about next, which ultimately delivers to infrastructure.
And then what happens?
Once it's in the infant structure, we monitor it.
And then we, let's go to red here, collect feedback.
Did it work? Did it not work? What could be improved on, if anything?
If it did work, how do we move on to the next step? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If it did work, how do we move on to the next step?
And that is what starts the process all over again.
It's either going to fail, at which point we fail fast, that's the term here,
of getting to the correct state that we want to be in as quickly as possible.
Thank goodness we only shipped a small update, so we only need to ship a small
fix.
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
Or it did work, and we want to iterate on that and make it work even better.
There is a third possibility, and that's that there's no change at all.
We're not really looking to measure success anywhere here.
This may have just been a quality of life thing that we changed.
But the point is, is that this software development life cycle keeps going, and
it just keeps going.
So when we have microservices, we have small applications to begin with.
Then, when we're doing this development work and we're developing small WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then, when we're doing this development work and we're developing small
incremental changes and shipping that, the deployment time that we're usually
looking at is anywhere from one to three weeks to complete this full life cycle
from plan all the way through feedback.
We should be expecting this to be one to three weeks.
So if this is our first one to three weeks sprint, that's what we usually call
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
these, then somewhere in the mix, we'll have another one to three weeks sprint,
and then another one to three weeks sprint.
In all of this work is happening concurrently on our application.
Maybe this is the shopping cart.
Maybe this is the search bar.
Maybe this is something with logistics down here.
So the full application like Amazon.com could be experiencing updates every
single day.
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
But the individual microservices might only see things on a one to three week
update cycle.
Do you see what I mean when I say that DevOps is really more of a lifestyle and
a management practice?
And it's really about managing how the flow of work happens and how it
interacts with each other.
Well, this does beg the question that we zoom in right here of going from the
persons, the developers laptop to running on the infrastructure itself. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
persons, the developers laptop to running on the infrastructure itself.
I did elaborate in the last video that that was one of the biggest pain points
that we have or a couple of videos ago.
That's one of the biggest pain points that we have that it's stopped the
process.
So knowing that that stopped the process and understanding that we really want
to have new update shipped every week, two or three, we don't have, we can't
stop the process to wait for a server to be deployed or for the network to be
updated.
So what do we do? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what do we do?
We use CI/CD pipelines and infrastructure as code.
Let me show you.
I've brought up something here called a GitHub action.
The idea with a GitHub action among other things is to actually use continuous
integration and continuous deployment.
With this, we automate, we automate the building of our code and the delivery
of that code to the infrastructure. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of that code to the infrastructure.
This is automatically happening as soon as the software developer checks in
their code in the source control or requests that it gets merged into a
different branch.
This can automatically kick off a series of systems that will build, test, and
deliver all of our code for us automatically.
Continuous integration is making sure our code integrates successfully into our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Continuous integration is making sure our code integrates successfully into our
ex...
Oh, at least spell that a little bit better.
Our existing code base.
If we write some code to update something like the shopping cart, that's not
allowed to break other parts of the application.
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
The CI makes sure that the full application continues to work after we have the
code, the new code integrated into the current code base.
When CI/CD pipelines fail, nine times out of ten, they fail here.
Something about the way the developer wrote the code or something about their
environment broke its ability to integrate into the existing code base.
So if it breaks, that new code never gets delivered to the production
environment.
The production environment stays on the whole time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The production environment stays on the whole time.
Right here on the screen, you can see where I defined a build stage.
This is what we're trying to do.
We're trying to build the code and make sure that it integrates successfully.
I define things like, "Hey, when you do this, when you actually go to build my
code, do it on a Ubuntu server."
GitHub behind the scene actually spins up a Ubuntu server just to do it.
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
It copies the code, it installs the Node.js version that I specified right here
, version 16.
This repos a few years old at this point, I think 16 is now deprecated.
It builds my Node.js or my JavaScript application.
It copies all of the built code, it zips it up, and it uploads it into an
environment that we can then deliver later.
One of the other things that it does right here is ARM templates. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One of the other things that it does right here is ARM templates.
ARM templates is an Azure thing.
The idea with an ARM template is we check to make sure we actually have the
infrastructure that we need to deploy on.
If we don't have the correct number of web servers or the correct configuration
of those web servers,
the ARM template will connect into Azure and automatically deploy these virtual
machines.
This again is a big part of integration.
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
Before I even attempt to deliver my code to its end target, the question is, do
I even have end targets?
If not, build them automatically in Azure.
Again, this happens automatically.
No manager is logging into Azure and deploying virtual machines, no software
developer is stopped waiting on these virtual machines to be deployed.
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
As soon as the software developer has done their work and pushed this code into
GitHub, this pipeline is automatically running,
building the application itself, and deploying the virtual machines.
Once that's done, we will say CI has succeeded.
We didn't run into any errors while trying to build the application, nor did we
run into any errors building out infrastructure to run the application.
Once CI has succeeded, we move into continuous deployment, sometimes also known WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Once CI has succeeded, we move into continuous deployment, sometimes also known
as continuous delivery.
Here, under the deploy section, the big thing we see is we download the
application that we just built,
and when we scroll down some more, we deploy that application to the Azure web
apps that were deployed.
Or the Azure servers or virtual machines that we deploy.
That's what we're talking about here.
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
So at this point, the developer pushed their code into GitHub, and within a few
minutes, it's automatically built, tested, and up and running on an Azure
virtual machine set.
Now, I can't stress this enough.
This is a very basic CI/CD pipeline.
Absolutely anything that you can dream of can be configured with a CI/CD
pipeline.
If you need to adjust DNS settings and load balancing settings and firewall
settings, or deploy, you can even deploy fully new virtual Cisco firewalls or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
settings, or deploy, you can even deploy fully new virtual Cisco firewalls or
Cisco CSR 1000 V's and configure them in this way as part of your pipeline.
Your whole infrastructure can be automated in a pipeline to facilitate the
delivery of the development or the delivery of the application.
Again, dev ops.
The operations are there to facilitate the dev, the dev work, because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The operations are there to facilitate the dev, the dev work, because
ultimately the people who use dev ops, the product that they're selling is
their application.
That's the revenue generating thing. It's the most important thing.
So everything should be done to help facilitate the delivery of new updates in
code.
CI/CD is the way that we go about doing that.
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
But wait a minute. We're here to talk about security, aren't we?
Maybe in the next video we'll start to talk about what dev sec ops is and where
it fits in to this whole picture of software development and delivery.