By now, you're probably wondering what exactly is S.I CD or continuous integration, continuous delivery,
continuous deployment so many times and I ironically, does it affect us?
Why should we care about us or what?
What are these only buzzwords or what do they mean?
So let's first start with continuous integration and understand what continuous integration is.
And actually the continuous integration is simply a practice.
And when you are using continuous integration, you're integrating your code with other developers.
Now, usually you're not the only one working on a project.
And by using continuous integration, what it means is that every time you make a change to the code,
that code is being integrated with the work that I just did.
And usually the way of integrating this is to see if the build is still running.
So, for example, you have a compile task or you're somehow building the project.
And if that task doesn't work anymore, then it means that the last one, probably the last one who
has made a change to the project did something that made the project not work anymore.
So this is one step of continuous integration.
The other step would be, of course, to see if everything still works, if you test it.
So let's say the project is still building properly.
There are no errors.
But if you're working on a website or any product, if the core functionality of that product isn't
working anymore, we usually check such things in an automatic way by writing tests.
And there are different levels of tests that we can write.
But this is generally continuous integration.
We try to integrate the work that we do all the time continuously.
So there's no we integrate our work once a week and after one week nothing works anymore.
We constantly integrate every change that you do to a repository, or if the project is spent over multiple
repositories, every work, every change that is done there is integrated with the work of other developers,
other people working on the same project as early as possible so that we can get continuous feedback
and to know what you have changed.
The project has is actually incompatible with what have changed.
So let's try to find a way and fix the project so that it works for everybody.
Continuous delivery is after continuous integration, and usually you cannot do continuous delivery
without doing continuous integration first.
And the idea between continuous delivery is that in the previous step you have created a package or
something that you can deliver to production and you're automatically installing this package on a staging
system, on a pre production or testing, or there are different names for it.
But on a system that doesn't go live, doesn't affect real customers or whoever is using this software
product.
So the idea between continuous delivery is to build packages all the time and to install them in an
environment and only by using manual intervention.
You can decide if a specific package, if a specific change said should go life.
And usually you'll have this review system where somebody looks, oh, these are the changes that will
go live.
Is it OK from a business standpoint and so on and so forth.
And then we'll say, OK, this is this looks good.
I'm going to decide that this can go life.
So it's only automatically installed in one system.
And after a manual check, it can be installed on a production system as well.
Now, continuous deployment in this case goes even further and you can more or less say that every change
to the project goes to the continuous integration stage, usually goes to a preproduction stage where
you check again.
And if there all the tests are good, then it means that this package that you now have can go to production
as well.
And if all the previous stages are successful with continuous deployment, will actually push those
changes to production automatically.
So this review step, this manual intervention that somebody looks again at a system and says, oh,
this is good, can go to production, totally disappears.
And more or less every change that is made in the repository will go to production automatically.
And in this case, you will have multiple deployments per day.
So the advantages of continuous integrations are generally related to detecting errors and fixing problems
or bugs as soon as possible.
And when you're integrating multiple times a Gayton with which every change that you made to a repository
is being integrated, it really reduces integration problems.
Or if there are any integration problems, they are generally pretty small and can be easier to be dealt
with than to avoid doing integration for a large period of time and then to do it much later.
This also allows developers to work much faster to create smaller changes to the code base and to have
more confidence that whatever they do, it will be easily detected by the continuous integration server
in this case, Getler, because every time you commit to change, that change will be integrated with
all other changes.
There will be tests that will be executed and hopefully any major bugs will be detected right there.
Addition, when doing continuous delivery and continuous deployment, it's more or less you make sure
that everything you do is actually releasable so you don't make any changes that are not designed to
go life.
Or if you make any changes, you sort of will make sure that those changes are not accessible.
Additionally, if you're doing smaller changes and they go to production quite often, is that it lowers
the risk.
Now, it doesn't mean that there's absolutely no risk and this generally means that.
Changes that introduce problems are easier to detect and are much easier to fix, and this is totally
different from doing like very big releases where you're only deploying once a month or something like
that, where you have a lot of changes and and is more or less well, hopefully everything works because
if it doesn't work, then we have a problem.
And actually, by deploying so frequently, you deliver more value.
So you're building a product because you are building some features that somebody needs.
And if you're delivering that features faster to the market, you have on one side a competitive advantage.
But on the other side, you also get more feedback from your customers.
So so why make the customers wait for one month, give you feedback when they can give you feedback
in a couple of days and then work on that feedback or based on the box or problems they detected, you
can make another iteration and make everything much faster.
Now, in this lecture, I've tried to give you an overview of what continuous integration, continuous
delivery and continuous deployment really mean, but you will see in the next lectures and in this entire
course will be going and demonstrating exactly how this concepts, how this practice of integrating
code and practice of continuously delivering code can be implemented with catalepsy.
And this is the most interesting part.
And I'm sure that when you will be doing it on your own, it will have a much better understanding than
watching the slides and saying, oh, lab OCI is when you're doing this and this and CCDs when you're
doing this, you will have the chance of actually practicing this on your own.