CICD with CDKTF : Part 1

In early 2024, We at Distribution Innovation decided to adopt CDKTF — Cloud Development kit for terraform, as our primary IaC framework. Having used Terraform earlier, the decision was relatively easy for us as we didn’t want to give up on the Terraform competence and code base. The other driver towards the switch was that we wanted to offer our Application Teams more (or should I say “total”) ownership to their application’s infrastructure. As with everywhere, application developers are more used to writing classes and interfaces and not so much HCL which supported the argument for cdktf.

CDKTF is a framework which allows us to write infrastructure using programming languages which we are already familiar with - in our case it being Typescript. Since this framework is for Terraform, we get all the benefits of Terraform without writing/knowing HCL. CDKTF internally synthesizes our IaC code written in programming languages into json format which terraform uses further. You can read more about cdktf at Hashicorp’s official website here.

Though we did evaluate other programming language IAC frameworks, like Pulumi — a developer centric iac tool, given the terraform heritage we decided to use cdktf, and so far we haven’t had any regrets.

Every IaC setup needs a capable CICD solution to ensure changes are integrated to the applications in an automated manner. In the first part of this multi-part series covering CICD solution for cdktf we will be evaluating the official Hashicorp’s cdktf Github action, the challenges we faced and it’s restrictions like unable to handle multiple/dynamic stacks.

CDKTF CICD using Hashicorp’s official Github action:

At DI, we have a very standard way of organizing Teams — One Team per Business area and each Team working on multiple bussines applications. Something like this -

Finance - Team 1
    -- Paymentservice - App 1
    -- Application 2
    -- Application 3

Delivery - Team 2
    -- Packerapp - App 1
    -- App 2
    -- App 3

Every team has their own Github repo hosting all their projects’ IAC where one project is independent of others. The CICD solution should be flexible enough to detect changes, plan and apply only the cdktf project(s) which had changes. This also means a few things for us -

1. Inside each project, there can be multiple stacks* (for different envs — dev/stg/prod).
2. There could be a possibility that for some reasons we don’t want to deploy all the environments.
3. CICD should detect the changed project, run cdktf synth and then take all the stack names generated dynamically and run plan on them one-by-one.
4. We avoid DRY, so that our common libraries don’t bootleneck the team’s use of new or non-standard implementations of infrastructure — we could have a whole blog about nay or yay to DRY in a IAC context.

* a stack is a cdktf’s logical container which contains infrastructure definition. It contains one or more terraform resources to be provisioned and has it’s own state file to separate it from other infrastructure resources.

When we started looking at the Hashicorp’s cdktf github action’s github repo, they’ve made it very clear that it works only for one stack -

The problem elevates further because even the single stack name should be provided statically i.e. it does not support placing a variable in the stack name which gets fed dynamically generated stack names.

Post output of Terraform plan as a comment on pull-request:

At this point it was a deal breaker for us. But still we thought to give it a spin to learn more about the “commentOnPR” feature provided by this action which basically puts the output of terraform plan command as a comment in the PR.

And it generated a clean PR comment containing the details -

Conclusion: For very smaller CDKTF projects where there are just a few stack names, the Github action provided by Hashicorp could make sense, but for Enterprises with multiple application projects and dynamically generated stack names, this will not work. We also tried using Atlantis which seemed work but even Atlantis wasn’t so flexible and it required some manual commands like “atlantis plan” on PRs to show the output of a terraform plan instead of doing it automatically.

In the next part, we will cover how we got over this limitation and used cdktf-cli to develop our CICD workflow which meets all our requirements.