In Chapter 1: Terraform Environment Configuration, we explored how to create environment-specific infrastructure "blueprints" using Terraform. We learned how folders such as environments/dev and environments/prod organize these configurations, and how terraform.tfvars allows us to customize each environment with specific values.
While this approach provides flexibility and clarity, manually applying these configurations can become repetitive and error-prone—especially as the number of environments or team members grows. To address this, we now turn our attention to automation techniques that streamline deployment and reduce the risk of human error.
Imagine you have these amazing infrastructure blueprints (your Terraform code), but every time you want to build or update your cloud setup, you have to manually type commands into a terminal. What if you forget a step? What if someone else tries to deploy and makes a mistake? This is where CI/CD Pipelines come to the rescue!
Think of a CI/CD Pipeline as your automated construction crew. Instead of you manually supervising every tiny step of building your infrastructure, you tell this crew: "Here's the latest blueprint, go build it!" The crew then automatically handles all the checks, preparations, and actual construction work. In this automation is powered by GitHub Actions. With this setup, infrastructure changes are automatically validated, reviewed, and deployed to AWS—reducing manual effort, minimizing human error, and accelerating delivery.
Let's break down these terms:
validates and plans our infrastructure changes whenever new code is pushed, checking for errors early.apply those planned changes to our cloud infrastructure.Our pipeline, defined in a file named terraform-ci-cd.yml in the .github/workflows folder, has two main jobs, like two shifts of our construction crew:
plan of what changes Terraform will make. It doesn't actually change anything in AWS yet.You can trigger our automated construction crew in two main ways:
deployment-dev branch, the pipeline will automatically start and deploy to the dev environment. This is great for quick testing.prod, you can manually start the pipeline and choose which environment (dev or prod) you want to deploy to. This gives you a clear approval step for critical changes.Let's see the simplified setup for these triggers in our workflow file:
# File: .github/workflows/terraform-ci-cd.yml (Simplified)
name: Terraform CI/CD Pipeline
on:
push:
branches:
- deployment-dev # Automatically runs when code is pushed to this branch
workflow_dispatch:
inputs:
environment: # Allows you to choose 'dev' or 'prod' when you manually run
description: 'Environment to deploy (dev or prod)'
required:true
default: 'dev'
type: choice
options:
- dev
- prod