Configuring CI/CD For Your CDK Application, With CDK
And how to keep it under one roof, or not.
As your project gains traction, it will likely exceed what is reasonable for manual CLI deployments. At this point, you’ll need to decide how to automate your deployments. Since CDK is a CloudFormation (or Terraform) synthesizer, setting up a process to accomplish this is fairly open-ended. All you really need is a compute space capable of running CLI commands.
CDK Pipelines Construct
CDK Pipelines is an opinionated construct library. - the docs
I’m starting with this because it is what I personally have the most experience with, and is built by the CDK team. Bias aside, it has saved me from bad deployments a number of times and I do recommend it. But admittedly, it can be finicky sometimes.
Pros
It’s included in the CDK library.
There is no need to install additional dependencies.
It’s maintained by the same team that maintains the rest of the library.
Typical third-party library concerns aren’t relevant due to this being internal to the library.
It is moderately easy to set up.
The most basic usage involves simply wrapping the necessary constructs around the stack you wish to deploy.
It is native to AWS.
In the end, it deploys CodeSuite services to perform the process.
There is no need to cross lines between companies like you might with Github, CirceCI, or other CI/CD platforms.
Cons
It’s slow to run.
Compared to other processes, the time it takes for a commit to happen, the process to run, and the changes to get propagated is long.
The
Self Mutatestep is a lynchpin and a black box.It is very frustrating to debug if something does go wrong on this step. There are common reasons that can be found via traditional things like “googling”. But when this step breaks, it’s usually not pleasant.
Redeeming quality, you can disable it. I have not attempted a setup with it disabled. As 99.999% of the time, the step works no problem. But oh boy, that .001% of the time can be a doozy.
It can be overkill for some uses.
If you’re deploying a lambda or two, the setup for the
Pipelinesconstruct is small. But its output is significant by comparison.As I mentioned at the start, this is a tradeoff. If the project is destined to be much more than a lambda or two, this might only matter temporarily. But if the purpose is small, you may want to try an alternative process.
Example
Github Actions
Going down this route can be an easy next step after outgrowing manual deployments. You can take whatever you were already doing, stick it in a YAML file, and call it a day. But you’re essentially stepping back into older forms of IaC. If you’re versed in those tradeoffs, you’ll probably manage fine. If not, this might not be the route for your project.
Pros
Easy-as-pie setup
Getting GitHub Actions running is as simple as adding a YAML file to your repo. In development, it’s hard to get much simpler than that.
Coexists with your code in Github
An underrated point. Dramatically simplifies the reasoning process through what’s happening, when you can see the changes directly next to what’s happening.
Template files
For most use cases, these are simpler to reason through than a coding language. And nowadays, they have quite a bit of extensibility, meaning they can grow as the project grows.
Cons
Template files
But not nearly as much as a coding language. Supporting the process with an interpreter or compiler vastly outperforms template files in terms of extensibility.
External System
It’s more challenging to integrate with other AWS services.
Incur networking charges for moving information in and out of the AWS cloud. Along with other networking challenges you may face when dealing with VPCs.
Security and Compliance are made more difficult.
Credentials to be managed
External attack surface
Less control over the build environment
Example
Roll your own CodePipeline
For a smooth, refreshing blend of the previous two approaches. You can develop an in-house pipeline using the CodeSuite L3 constructs directly. This approach allows you to maintain everything in your AWS accounts while providing a smooth transition. The caveat with this one is, “With great power comes great responsibility”.
Pros
Contained within AWS
Allows you to use template files if you’d like. But does not require them.
As you can see in the example below, you can build the buildspec in your language of choice. Or you can use the fromAsset or fromSourceFile APIs to pull a templated Buildspec from within the repo.
Can produce simple setups that run quickly.
The keyword here is can. Akin to Github Actions, you can start out by wrapping your manual process with a bash script and having CodeBuild run that. But whether or not it stays simple and fast is up to you.
Can handle performing tasks that the Pipeline constructs cannot
… very specifically it is not built to use CodeDeploy to deploy applications to instances, or deploy your custom-built ECR images to an ECS cluster directly
Cons
You are responsible for a large amount of the process.
AWS provides quite a few things, like build images, visualizations, and such. But most of the “important” details you will have to sort yourself. If you have strict compliance or regulations you have to adhere to, this might be a boon. If you don’t, this might be a burden.
Can hide complexity
It is possible to have a Source and a Build step and just stick everything in a bash file that the build step runs. Essentially allowing you to tuck away the meat of what’s going on.
Example
Conclusion
One of the best reasons for going with CDK is its open-endedness and that doesn’t stop once you deploy. You can take your CDK code and deploy it where you like and how you like it. Adapting it to fit your needs.