Matt Rickard

Share this post

Build-as-Code

blog.matt-rickard.com

Discover more from Matt Rickard

Thoughts on engineering, startups, and AI.
Continue reading
Sign in

Build-as-Code

Mar 25, 2022
Share this post

Build-as-Code

blog.matt-rickard.com
Share

Infrastructure-as-code (IaC) is often seen as a deployment tool. Write code to describe your infrastructure – either at a low level like Terraform or Cloudformation, or at a high level like the AWS Cloud Development Kit (CDK). But Infrastructure-as-code is naturally part of the continuous deployment (CD) process, but increasingly is finding its way into continuous integration (CI).

Infrastructure-as-code is becoming build-as-code.

Take this hypothetical scenario – you want to deploy every new commit that's merged into the main branch to a development environment. As part of your CI/CD, you'll run a command that compiles the IaC and deploys it. But it's necessary to connect that code to the newly built artifacts from the build pipeline. Connecting the two can be tricky. Unnecessary re-deployments on artifacts that haven't really changed (you'll need to reference them by checksum). Parameterized templates in your IaC – an unchecked link between the place where the build pipeline uploads and the deployment pipeline downloads.

CDK already has constructs that can point to a Dockerfile or zip file and build and deploy that to a lambda function or endpoint. But first-class build support is the logical next step. That will lead to better caching, better user experience, and an overall easier pipeline from code to deployment.

Share this post

Build-as-Code

blog.matt-rickard.com
Share
Previous
Next
Comments
Top
New
Community

No posts

Ready for more?

© 2023 Matt Rickard
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing