Ship infrastructure like you ship your code

AWS Cloud Development Kit, better known as CDK, is changing the way we do infrastructure as code by using a proper programming language to build your infra.

Since we are building infra with dev tools, we should have a CI/CD for our CDK stack code that looks like any other project. If you look online, AWS explains how to do CI/CD with code build/code pipeline, but these probably aren’t the tools you are using in your day-to-day.

In this article, I will present to you the deployment pipeline I’m using to deploy my CDK stack based on GitHub and TravisCI.

Continuous Integration

Continuous integration looks like any code project CI. We validate our code, run the tests, and try to see if the build failed.

This is run in every commit to ensure that we have the shortest feedback loop possible.

So in Travis configuration, it will look like something like below (here, we have a CDK Python stack):

This CI is classic. We lint the code, test it, and export the coverage. We run cdk synth for each stage on each commit to be sure that the config does not break one stage in particular.

As you can see, we also use multiple Travis CI stages to run everything in parallel in order to have the shortest feedback loop possible.

Open Pull Requests to Validate Your Deployment

The best strategy I have found to deploy the code to AWS is to have one branch per stage (dev, pre, pro), so every time a new commit reaches one of these branches, we are deploying the actual stack. Yes, it looks like GitOps!

But we don’t want to blindly deploy our CDK stack on an AWS account. So I have an automatic way of opening pull requests when something is merged to the main branch:

Each time something is merged to the main branch, we have a specific job that runs cdk diff -c stage=<STAGE> and opens a pull request to the destination branch.

For that, we use the script below. As you can see, it runs cdk diff and uses the results to open a pull request using the GitHub CLI:

Now we have to call this script inside Travis, so our .travis.yaml file will look like this:

As you can see, we are now using some env variables to specify our AWS Credentials in addition to our GitHub Token. Please make sure to encrypt them before committing them in your repo.

Continuous Deployment

Now that you have your pull requests open for all your stages, it’s time to deploy the changes to your stack!

On your PR comment, you are able to see the diff, so you will no longer be blind when it’s time to deploy a specific stage.

The next step for the CD is to deploy the stack. Each time we have a change in one of the release branches, we want to run cdk deploy -c stage=<STAGE>.

The complete .travis.yaml file will look like this. As you can see, each stage uses a condition for the deployment to be sure to apply it only to a specific AWS stage:

Conclusion

With this GitOps approach, it is easy to understand what you’re deploying in your stack and all your changes are in Git.

It also helps engineers with less knowledge in CDK to feel confident in the deployment of the infrastructure because no manual steps are required to deploy to a “real” AWS stage. The main advantage is that you are using the same tooling that you are using for the rest of your projects.