-: CI/CD. In this lesson,
we're going to talk about three concepts.
This is known as continuous integration,
continuous delivery, and continuous deployment.
Before we do that, though,
we really have to take a look back
to the way the code is made and deployed
in most of our environments.
Now, in the old days,
the way we would do things is very linearly.
We would start out with development,
and we would start taking the code and putting it together
and figure out what it's going to do.
Then, we would move into testing and integration,
where we would put it into some kind of a test environment
and make sure it didn't break anything.
After that, we would start the integration process,
which means we might be buying new servers,
and we might start installing all the software
to see how it's going to operate in that full environment.
After that, we'd move into staging.
Now, staging is where we'd actually put things
into a set of servers
that look like our production environment,
getting ready to move from testing into staging,
and then from staging into production,
which brings us to our final step, which is production.
This is when that piece of software is actually deployed
onto those servers that are being used by your end users.
Now, this was a very slow process,
especially if you did it one step after another,
and the challenging thing is that these steps were all run
by different people.
So, when you had developers,
that was your programmers, they had one role,
and then they would send it over to another team,
who did testing, and then they would send it
to another team that did integration and staging.
And finally, you had the operations folks,
who took it from staging into production,
and so, there's a lot of handovers and a lot of problems here
because things were moving from one step to another,
and there'd be a lot of internal conflict
within your organization.
Now, the concepts involved with CI/CD tries to eliminate
a lot of that.
It tries to speed this process up.
For instance, I worked at one organization,
where when we wanted to add a new feature,
it could take nine to 12 months to go from development
all the way through to production.
So, instead, with continuous integration workflows,
you can actually speed this process up a lot.
When you're dealing with continuous integration workflows,
you have a common source repository.
Everyone ends up checking in their code
to this common source.
Now, this can be your managers, your developers,
whoever's working on it.
Then, when you're ready to get this thing running,
you can take it from that common source
and pull it into the continuous integration server.
At that point, it gets built,
that means it compiles the code, it tests the code,
and then it tells you whether or not it succeeded
or it failed, and then based on that,
it can go back to the developers for the next step,
which might be moving into testing, moving into integration,
moving into staging, moving into production.
But by doing this, you can automate a lot of this function.
So, when we talk about continuous integration,
this is this first piece of this.
Continuous integration is a software development method
where code updates are tested and committed
to a development or build server or code repository rapidly.
So, this allows us to create something,
test it, and then once we know it's good, we can say,
this is ready to be implemented in the environment.
Now, by itself, continuous integration
doesn't do that much for us in terms of speeding things up.
Yes, we are shifting left a little bit here,
and we're letting our developers
do some more of the testing,
which is always a good thing,
but continuous integration can do more than that.
By using continuous integration,
you can actually test and commit updates
multiple times per day.
So, going from that feature, taking nine to 12 months,
we can now have systems
where we're doing continuous integration
five, 10, 20 times a day, if needed.
Now, how do we get that fast, though?
Well, that's where we have to bring in continuous delivery
and continuous deployment.
Now, when I talk about continuous integration,
it's really focused on detecting and resolving
development conflicts early and often.
So, remember, I said here in the workflow,
we have all of our developers
who are using the same sources.
Well, if I'm doing something
where I take a big feature and it takes 100 developers
to work on it,
that's 100 different people making changes to code.
If they're all working on it
and they're working on these things
and they're checking out for maybe a week at a time
or two weeks at a time,
that causes divergences from what we started with
a week ago, to where we are a week later,
because as you're working on something
and I'm working on something for a whole week,
that means we have a lot of differences.
So, instead, with continuous integration,
we're constantly taking our code,
we're doing these integrations,
we're testing it and then putting it back to the master.
So, we're all working from the same sheet of music.
This way, we're making sure we don't have
these big changes and these big conflicts.
Now, if we want to take this a step further,
we can actually start speeding up the delivery of things,
and this is known as continuous delivery.
Now, if you're going to do continuous delivery,
you have to do continuous integration.
But just because you're doing continuous integration
doesn't mean you're doing continuous delivery.
These things are not A equals B and B equals A.
It's more like if you have A, you can do B,
but if you have B, you must be doing A.
Now, when I talk about continuous delivery,
this is a software development method
where the application and platform requirements
are frequently tested and validated
for immediate availability.
So, I go out and I code some new feature.
I test it through continuous integration.
Now that I've tested it,
I can go through continuous delivery,
which means it's going to go through all the tests,
all the compliance, and all the validations.
So, it's now ready to be installed
on that staging server or into production.
Now, I'm not actually going to go forward
and install it on staging
or install it on the production server,
that's not continuous delivery.
That is continuous deployment.
Now, with continuous deployment,
we take the concept of continuous integration
and continuous delivery,
and we take it even one step further.
Now, we have a software development model
where application and platform updates
are committed to production rapidly.
Essentially, I'm going to create some new piece of code,
maybe a security fix.
It's going to go through the integration testing.
Once that's been approved,
it goes back to the code repository.
At that point, we can go through
and do continuous deployment,
where it gets tested and ready to go into staging.
But instead of just sitting there
waiting for somebody to actually install it
in staging, with continuous deployment,
we can take that code and actually deploy it to staging,
and then at regular intervals,
move things from staging into production.
This allows us to do things much quicker
in terms of deployment and release cycles.
Now, when we talk about continuous delivery,
I want you to remember that continuous delivery
is focused on automated testing of code
in order to get it ready for release.
Not released, just ready for release.
Now, when I talk about continuous deployment,
I'm taking it a step further.
I'm focusing on automated testing and the release of code
in order to get it into the production environment
much more quickly.
Now, what are the real big benefits here?
Well, think about it like this.
If you're dealing with something like coding a security fix,
do you want it to take three weeks or three months
or three years to get it out there?
No, you want it out there right now,
and so by doing continuous integration,
continuous delivery, and continuous deployment,
you can shorten that cycle and get things out today,
or even within a couple of hours.
Now, for the exam, these concepts are just a few quick topics
that we needed to cover based on your textbook,
but you're really unlikely to get many questions on these
during the exam.
This is really much more focused
on software development life cycle
and things of that nature.
If you get into IT service management
and you start working in DevSecOps,
you'll probably become very familiar with these terms,
but for now,
I just wanted you to be introduced to them
and to cover them
because I wanted to give you
a full coverage of your textbook.