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.

What Problem Are We Solving?

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.

What is CI/CD and GitHub Actions?

Let's break down these terms:

Our Automated Construction Crew: The CI/CD Pipeline

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:

  1. Terraform Plan (Planning Crew): This job focuses on checking the blueprint for errors, making sure it's well-formatted, and creating a detailed plan of what changes Terraform will make. It doesn't actually change anything in AWS yet.
  2. Terraform Apply (Building Crew): This job takes the approved plan from the "Planning Crew" and actually applies it, meaning it builds or updates the infrastructure in AWS.

How to Use the Pipeline to Deploy Infrastructure

You can trigger our automated construction crew in two main ways:

  1. Pushing Code to a Specific Branch: If you push changes to the deployment-dev branch, the pipeline will automatically start and deploy to the dev environment. This is great for quick testing.
  2. Manual Trigger (Workflow Dispatch): For more controlled deployments, especially to 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