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.