- In an AWS CI CD pipeline,
there are a number of services that you can use,
either individually or all in a single end to end process.
We have code commit to store your source code,
there's code build,
which builds deployment artifacts and performs testing,
we have code pipeline,
which can orchestrate the end to end process,
and then we have this service CodeDeploy,
which is designed for the last piece
which is actually deploying the code with a degree
of quality and following good DevOps principles.
CodeDeploy, like the other services is region scoped.
And it's name is exactly what it does,
it is a managed artifact deployment service.
It is designed around the automation of software deployment
to increase the uptime of the application
and reduce the impact on the end users or clients.
CodeDeploy has native integration
with the EC2 auto scaling.
And so even if you have an auto scaling group,
with a number of running EC2 instances
and you need to update the version
of the application on them,
you can do that using CodeDeploy.
It has on-prem capability,
so you can perform these deployments against resources
that are sitting in an on-prem data center.
It allows for different types of deployments,
including a rolling deployment and blue/green deployments.
It also allows for configuration of deployment groups
as well as handling the history
of deployments as well as success and failure rates.
And finally it integrates with the other services
that can be part of a CI CD pipeline in AWS.
Let's take a look at an example
of using CodeDeploy all by itself
for managing the application version of a Lambda function.
So, first thing we need to do
is we create the function itself, the application,
and we are going to associate that
with a deployment group, configuration and versions.
And this will help us to maintain
state within CodeDeploy.
Next, we specify the deployment group
that we want to deploy to
in this particular iteration.
And this is where we can configure things like
traffic routing between multiple deployment groups,
so that we can perform gradual cut overs
from one version of an application to another,
and it allows us to support rollback.
Next, we have the deployment configuration,
this is where we choose the actual algorithm
for the deployment.
Do we do it all at once?
Do we do a Canary deployment?
Or do we do a blue/green deployment instead?
The AppSpec file is where we actually describe
the function versions, the current version
and the version that we want to deploy to
along with other validation operations.
Now we reach the actual deploy step
and this allows us to push that new application revision
to the deployment group using
the method that we've defined
in the deployment configuration,
which could be just a Canary deployment,
meaning we have a very small percentage
of our actual application that is using that new version
of the function until we're sure that it works.
We then check our results
and this is going to use CloudWatch
and other built in AWS monitoring.
And finally, we make the decision,
this is our tollgate,
where we decide was the deployment truly successful
or did we need to trigger a rollback so
that we can go back to the previous version
without any further impact on our end users or clients.