So welcome to this section on domain 1 SDLC automation.

I'm just going to introduce you to the concept of CICD, but if you already know
this, you
can just skip ahead.
So what is CICD?
CICD stands for continuous integration and then continuous delivery or deployment.
So let's start with continuous integration.
So the way it works that developers push the code to a code repository often, it
could
be GitHub or CodeCommit or Bitbucket, whatever you want.
And so as we can see, we push the code as often as possible.
And then as soon as the code is pushed, there will be a testing or a build server
that checks
the code as soon as it pushed.
And so the reason we do this is that we want to make sure that the code can be
built and
is tested correctly.
Why do we do this?
Because then the developer, us, will get feedback about the tests and checks that
have passed
and failed.
And so therefore we can improve our code.
And we can find bugs early and fix them bugs very early as well.
So this way we can deliver code faster as it is tested continuously and then deploy
often.
The result of this, when you have continuous integration, is that you have happier
developers
as they're unblocked.
They don't have to run their tests or their builds themselves.
They just push the code to a code repository and then the build server will do the
heavy
job for them of testing the code, building it, and maybe even notifying the
developer
of how it went.
So continuous integration is the first step in CI-CD.
Now we have continuous delivery.
So we want to make sure that whenever a software is built, it can be released
reliably whenever
we need.
And we want to make sure that the deployments happen very often and are quick
because we
want to move away from doing one release every three months to doing five releases
a day.
And that you can only do five releases a day if you have something called
continuous delivery.
So that means that the deployment will be fully automated.
So we could use technologies such as CodeDeploy, Jenkins, Spinnaker, et cetera, et
cetera.
So what does a continuous delivery pipeline look like?
Well, we have our happy developer and it pushes code often.
And then the build server will get the code, build it, and test it.
And then the deployment server, after the build server is done, will get the build
output
and say, okay, I want to deploy this new version to my application server so that
they go from
v1 to v2 at a high level.
So this is the idea behind continuous delivery.
So I said that there was CD meant continuous delivery or continuous deployment.
You need to know the difference between these two things.
Continuous delivery means that you have deploying often using automation, but it
may involve
a manual step.
For example, if you need to approve a deployment, usually when you have a
production deployment,
maybe you want to manually approve that production deployment and therefore you
would use a
manual step and then you would be in the setting of continuous delivery.
Even though there is a manual step in here, the deployment itself is still
automated and
it can be repeated and is safe to do.
So continuous delivery has a lot of advantages to it.
Continuous deployment, on the other hand, is entire automation.
That means that every code change you will do in your source repository will be
deployed
all the way to production.
That means there is no manual interventions of approvals.
This is something usually used by doing a lot of monitoring and then if there's a
bug,
then you just push a new code fix in your repository and then it makes it all the
way
through to the end of the pipeline.
So this is important to understand the difference.
Delivery and deployments are very, very similar, except delivery may involve a
manual step
whereas continuous deployment is automated all the way to pushing to production.
Okay, so now let's go back to AWS.
What is the CI-CD stack looking for in AWS?
These are the steps you can do in your CI-CD.
You have code, build, test, deploy, and provision.
So for code, you would use AWS CodeCommit, and we'll see this in the section, or
GitHub
or a third-party repository.
Then for building and testing, you could use AWS CodeBuild or Jenkins CI or any
third-party
CI servers.
And for deploying and provisioning, Beanstalk or provisioning infrastructure with
CloudFormation,
for example, and for deployment especially, you would use CodeDeploy.
Finally, to orchestrate everything, you would use AWS CodePipeline.
So in this section, we'll see CodeCommit, CodeBuild, CodeDeploy, CodePipeline,
Jenkins,
and we'll even see CodeStar as well as an overview.
This will allow you to understand how to do CI-CD and SDLC automation onto AWS.
So get ready, and I will see you in the next lecture.
Thank you.