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'd move into testing and integration
where we'd 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/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 need 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 lifecycle
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.