- The CICD acronym stands for:
continuous integration, continuous deployment.
And there are a number of different individual steps,
or tasks, that can be part of that sort of pipeline.
AWS code build is actually going to handle
the first half of it.
It is a region scoped resource,
or resources, that manage the continuous integration part
of continuous integration, continuous deployment.
It allows you to perform actions
like compiling your source code.
It can also have a testing phase,
so that after the compilation is done,
you can actually verify that that package
has been created properly.
And it gives you the ability to create those packages.
Now, it does not act as a persistence tier
for those packages.
There's another service in AWS that is dedicated
specifically to that particular part of the process.
But code build has a lot of other flexibility
for custom jobs that might not have anything
to do with packaging or compiling code.
Now let's take a look at some of the features of code build.
It allows you to create preconfigured environments
for specific run times, or applications,
like Java and so on.
It has integration points with Jenkins.
So if you're already using Jenkins,
it's relatively easy to fit that into your CICD process.
It uses a build spec file that is in YAML format.
And this allows you to perform any layer of customization
that is required within the individual steps.
And finally, all artifacts that are created
as part of the code build pipelines,
are encrypted at rest using KMS.
Now let's take a look at an example
of where code build could be used
in a slightly non-traditional way.
Let's say that we would like to use code build
to automate the deployment
of schema changes to an RDS database,
but we'd like to be able to validate
and test from the application first.
So, we start off with a schema change.
and this might be just a, a sequel, file,
or whatever we need to be able to apply
to an existing database, to make the changes.
This can be referred to as part of that build spec file,
which we could even place in an S3 bucket
alongside the schema change itself.
Code build can then be instructed to launch an RDS database
from a predefined snapshot,
which we include as the before database,
the one that's before the schema changes.
And so code build can then restore that snapshot
to a brand new RDS database,
utilizing the AWS CLI, and potentially an S3 bucket,
or an actual RDS snapshot, containing the data.
Now, while that RDS snapshot restore is in progress,
the code build job is going to wait until it completes.
And there are a number of CLI options
in AWS where you can issue a wait
looking for a particular condition to be met.
And that is very likely what this is using under the covers.
Once the RDS database is fully deployed
using the pre change schema,
the code build job can then apply those changes
to the RDS database,
and potentially even use a cloud formation template
to launch a temporary copy of the application environment,
point it to the RDS database,
and perform all of the validation that is required
to make sure that the application is still fully functional.
Once all of that is complete,
we can then perform notifications,
either through SNS or other mechanisms, to the end users.
And, it can then clean up after itself
by removing the RDS database instance
that is no longer needed.