We close Part V by bringing together everything we've learned into a complete automated workflow: a CI/CD pipeline for Terraform. We've seen the individual pieces (plan review in subchapter 12.5, testing in Chapter 21); now we join them in an automatic "assembly line" that goes from writing code to deployment. We'll do this with GitHub Actions, one of the most popular CI/CD tools.

A pipeline is an automatic sequence of steps that runs when you change the code. Remember the two concepts:

• CI (Continuous Integration): automatically checking that the code is correct (we saw this in subchapter 21.1: fmt, validate, security...).
• CD (Continuous Delivery/Deployment): automatically taking the approved code to its destination (in our case, applying the infrastructure).

Analogy: a pipeline is like a factory assembly line. The product (your code) moves through stations: at one it's inspected, at another it's tested, at another it's assembled, and at the end it comes out finished. Each station does its part automatically, and if something fails at one, the line stops before the defect moves forward.

GitHub Actions is the CI/CD system integrated into GitHub. It lets you define pipelines in a file inside your repository, and they run automatically on events like opening a Pull Request or merging to the main branch. There are equivalent alternatives (GitLab CI, Jenkins, CircleCI...), but GitHub Actions is very popular and easy to start with; the concepts are the same in all of them.

The pipeline is defined in a YAML file inside .github/workflows/:

A basic Terraform pipeline has three stages, covering everything we've seen:

"Lint" means reviewing the code for problems. Here, the cheap checks from Chapter 21 are run: terraform fmt -check, terraform validate, and security analysis (Checkov/tfsec). If anything fails, the pipeline stops: there's no point in continuing with badly formatted, invalid, or insecure code.

terraform plan is run (subchapter 11.4) and its result is published in the Pull Request for a teammate to review (exactly the flow from subchapter 12.5). This is the key security stage: nothing is applied until you can see and approve what will change.

Once the PR is approved and merged to the main branch, the pipeline runs terraform apply automatically, applying the reviewed changes. Since the plan was already reviewed, this apply is safe and controlled.

A simplified pipeline in GitHub Actions would look like this (you don't need to memorize the syntax, just understand the structure):

Notice the triggers (on):

• On a Pull Request (pull_request): lint and plan are run (reviewed, not applied).
• When merging to main (push to main): apply is run (already reviewed).

This implements exactly the team flow from subchapter 12.5, but automated.

Remember the principle from subchapter 12.5: in a team, nobody applies Terraform by hand. The pipeline enforces this automatically:

• Changes always go through the checks (they can't be skipped).
• The plan is always reviewed before applying.
• The apply is executed by the system, in a consistent and recorded way, not by a person from their machine (with their particular configuration and risk of error).

For the pipeline to apply changes in AWS, it needs credentials. ⚠️ Never write them in the pipeline file (it would be like leaving the keys in the door). Use GitHub Actions secrets (a secure vault) or, even better, a secure connection without permanent keys (OIDC), applying the least privilege principle (Chapter 7): the pipeline should only have permissions for what it needs to manage. We'll go deeper into credential security in Chapter 23.

• A CI/CD pipeline is an automatic sequence of steps that runs when the code changes: CI checks that it's correct, CD deploys it. Like an assembly line.
• GitHub Actions defines pipelines in a YAML file in .github/workflows/; there are equivalent alternatives (GitLab CI, Jenkins...), with the same concepts.
• The basic Terraform pipeline has three stages: Lint (fmt, validate, security), Plan (published in the PR and reviewed), and Apply (after approval and merge).
• The triggers: in a PR you do lint + plan (review); when merging to main you do the apply (already reviewed). It's the flow from subchapter 12.5, automated.
• The big advantage: nobody applies from their laptop; everything goes through the automatic chain, in a consistent, safe, and traceable way.
• ⚠️ The pipeline credentials go in secrets (never in the file) and with least privilege.

In the next subchapter, we'll look at a tool specialized for this Terraform workflow: Atlantis, which takes infrastructure GitOps to another level.