Stop 10 · Infrastructure as Code & AutomationTopics · 7/9

CI/CD for Cloud Deployments

In short

Running terraform apply from your laptop works until two people do it at once, or someone forgets to pull. A CI/CD pipeline makes every infrastructure change go through the same checks, every time.

Automating the testing and deployment of both application code and infrastructure changes through a pipeline — running terraform plan/apply as part of a CI/CD workflow, with review gates before applying to production.

The blob character watches cakes move along a conveyor through a mixer, oven and checker.

Think of it like this

The bakery assembly line

Batter goes into the mixer, then the oven, then a quality check, then the box. No cake skips the oven because someone was in a hurry. A burnt one gets pulled before it reaches the shop. That's a deploy pipeline.

Watch it happen

An infra change from PR to prod

Pull request

Lint & test

Plan

Approve

Apply

Verify

1/6You change a Terraform file and open a pull request. Nobody applies from a laptop.

The big ideas

What you need to know

No stored keys

Use OIDC so GitHub Actions or GitLab get temporary cloud credentials. No long-lived access keys in CI secrets.

Plan in the PR

Reviewing a plan is reviewing the real effect. A small code change can still replace a database.

Promote through envs

The same code goes dev, then staging, then prod. Only variables differ between them.

One apply at a time

State locking, like Terraform's S3 lockfile or DynamoDB lock, stops two pipeline runs clashing.

See it in code

Walk through the code

yaml

1name: deploy2on:3  push: { branches: [main] }4permissions:5  id-token: write6  contents: read7jobs:8  terraform:9    runs-on: ubuntu-latest10    steps:11      - uses: actions/checkout@v412      - uses: aws-actions/configure-aws-credentials@v413        with: { role-to-assume: "arn:aws:iam::123456789012:role/gh-deploy", aws-region: ap-south-1 }14      - uses: hashicorp/setup-terraform@v315      - run: terraform init && terraform plan -out=tfplan16      - run: terraform apply tfplan

1/4Runs on every push to main, which in practice means after a PR is merged.

A GitHub Actions workflow. The gh-deploy role must trust GitHub's OIDC provider and only your repo's main branch.

Save yourself the pain

Common mistakes

Oops

Saving an admin access key as a CI secret.

Do this instead

Use OIDC with a role scoped to what the pipeline deploys, and limit it to your repo and branch.

Oops

Running terraform apply without a saved plan in CI.

Do this instead

Apply the exact plan that was reviewed, or a different change could sneak in between plan and apply.

Your mission

Plan on every PR

~45 min

Quick check

Why use OIDC instead of storing AWS access keys in GitHub secrets?

Go deeper

1Set up a basic pipeline that runs terraform plan automatically on a pull request.
2Learn why applying infrastructure changes should go through the same review discipline as application code.
3Understand the value of a manual approval gate before applying changes to production infrastructure.