Module 3: Cloud Deployment & CI/CD

Core references: Semester 9 modules (cloud platform, IaC, Kubernetes, CI/CD, security and observability) and Semester 8 Module 4 scale and reliability -- no new required books. Selective support: Official GitHub Actions and Terraform documentation, the SRE workbook, and the DORA metrics guide, used only when a specific choice in your capstone needs a reference.

This guide is the primary teacher. You already learned the ideas in Semester 9. This module is where they land in one real project -- the capstone you will defend -- instead of a lab sandbox.

---

Scope of This Module

This module is not a second pass on cloud, IaC, or CI/CD. Those were Semester 9. This module is where you take a specific capstone codebase and make it deployable, releasable, and rollback-ready for a single operator (you) on a realistic budget and timeline.

What it covers in depth:

• picking the smallest real cloud platform that still teaches you production-grade deployment
• a three-tier, serverless, or container-based topology that fits your capstone, not a generic reference architecture
• dev, staging, and prod on a realistic monthly budget, including the decision to collapse two of them if needed
• a Terraform (or CDK) root that you can own alone: state backend, module boundaries, and blast radius control
• a secrets and configuration strategy that does not sprawl across 40 files
• a GitHub Actions pipeline for build, test, and deploy using OIDC to cloud instead of long-lived keys
• preview environments or a simple staging cut-over you can actually maintain
• rollback rehearsal with concrete triggers and a timer
• database migrations that ship safely alongside code using the expand-contract pattern
• feature flags used as a deployment tool, not a permanent architecture
• smoke tests as post-deploy evidence, not pre-merge theater
• release notes and a one-page deployment runbook, both written for your future self

What it deliberately does not try to finish here:

• multi-region, multi-cloud, or vendor-matrix architectures
• progressive-delivery tooling (Argo Rollouts, Flagger) beyond concept-level awareness
• full GitOps platforms or service-mesh based deployment flows
• compliance frameworks, DR drills, or enterprise change-management processes (touched in S10 M4)

This is a capstone-integrative module. If your pipeline green-builds but you cannot walk a reviewer through a rollback in 60 seconds, you are not done.

---

Before You Start

Answer these closed-book before starting the main path:

1. What does infrastructure-as-code state actually store, and why does a bad state file feel worse than a bad deploy?
2. Why is OIDC-based cloud authentication preferred over storing an access key in CI?
3. What is the difference between a release and a deployment?
4. Why can a feature flag save a rollback, and why can a feature flag also become the bug?
5. If your prod database is one migration ahead of the rolled-back code, what breaks?

Diagnostic Interpretation

4-5 solid answers

• Start at Cluster 1 immediately. You already have the S9 context you need.

2-3 solid answers

• Proceed, but re-read the S9 M04 CI/CD index and the S9 M02 Terraform module notes before Cluster 2.

0-1 solid answers

• You are not integrating yet; you are re-learning. Go back to S9 Modules 1-4 for one focused day and come back.

---

What This Module Is For

By this point in the degree you have written a lot of YAML and a lot of Terraform, but probably not for one system that you personally deploy, break, roll back, and defend. This module forces that compression.

The deliverable questions you need to answer on capstone defense day are:

• can this system be deployed by someone other than you, from the repo alone?
• what is the monthly cost and where does most of it go?
• what happens if the main branch deploy fails at 3 a.m.?
• what is the smallest change you can roll back without dragging five others with it?
• can you show the last three deploys and the last one rollback in git and in the pipeline?

Every concept in this module exists to help you answer one of those.

---

Concept Map

---

How To Use This Module

Work in order. Clusters 1-2 fix the target, Clusters 3-4 make the change mechanism safe, Cluster 5 makes it legible.

Cluster 1: A Minimal Deployable Capstone

Order	Concept	Type	Focus
1	Choosing "Small Enough" Cloud	PRIMARY	Three platform options, picking rubric, and the "boring default" move
2	The Capstone Deployment Topology	PRIMARY	Three-tier, serverless, and container shapes, and which one fits your capstone
3	Environment Strategy on a Budget	PRIMARY	dev, staging, prod when you pay the bill

Cluster mastery check: Can you name your platform, topology, and environment count in one paragraph with the cost per month attached?

Cluster 2: Capstone IaC

Order	Concept	Type	Focus
4	Terraform for the Capstone: State, Backend, Scope	PRIMARY	One remote state, one root, one blast radius
5	Module Reuse vs Inline	PRIMARY	When a solo maintainer should copy and when to extract
6	Secrets and Config Without Sprawl	PRIMARY	One secret store, typed config, and the "no secrets in repo" rule

Cluster mastery check: Can you terraform apply from a clean laptop with only the secret store URL and a cloud login?

Cluster 3: Capstone Pipeline

Order	Concept	Type	Focus
7	GitHub Actions Workflow for the Capstone	PRIMARY	One workflow, three jobs, real YAML
8	Build-Test-Deploy with OIDC to Cloud	PRIMARY	Short-lived cloud credentials, least privilege, and role mapping
9	Preview Environments or Staging Cut-Overs	PRIMARY	Which one your capstone can actually afford to keep

Cluster mastery check: Can you trace one commit from git push to prod and show the exact step where it could have been stopped?

Cluster 4: Safe Release

Order	Concept	Type	Focus
10	Rollback Rehearsal: First Prod Deploy Fails	PRIMARY	Triggers, timer, and the revert you have already practiced
11	Database Migrations with the Release	PRIMARY	Expand-contract with a sample SQL pair
12	Feature Flags for Capstone Experimentation	SUPPORTING	Flags as deployment safety, not permanent architecture

Cluster mastery check: Can you state your rollback trigger, your rollback timer, and the one migration type you will not ship in a single deploy?

Cluster 5: Evidence of a Deployed System

Order	Concept	Type	Focus
13	Smoke Tests After Each Deploy	PRIMARY	Three checks the pipeline runs against real prod
14	Release Notes and Change Log for Future You	PRIMARY	Notes written to one reader, not a broadcast
15	The Deployment Runbook: A One-Page Plan	PRIMARY	Deploy, observe, roll back, contact -- all on one page

Cluster mastery check: Can you hand a stranger the runbook and the last release note and have them redeploy your capstone?

Then work these practice pages:

Order	Practice path	Focus
1	Topology and IaC Lab	Pick platform, draw topology, write a minimal root module
2	Pipeline Wiring Workshop	Author a GH Actions workflow and wire OIDC to cloud
3	Release and Rollback Clinic	Run one deploy, one forced-rollback, one migration
4	Deployment Katas	Four repeatable drills: YAML, Terraform, rollback, release notes

Use Module Quiz after the concept and practice path. Use Reference and Learning Resources only for targeted reinforcement.

---

Learning Objectives

By the end of this module you should be able to:

1. Pick a cloud platform, topology, and environment count justified by capstone-specific constraints, not fashion.
2. Author a Terraform root with remote state, a single backend, and a clear blast radius.
3. Keep secrets and configuration in one system with typed access and zero values checked into git.
4. Write a GitHub Actions workflow that builds, tests, and deploys, using OIDC for cloud credentials.
5. Stand up either a preview environment per pull request or a working staging cut-over to prod.
6. State a rollback trigger, execute a rollback under a timer, and show the result in git.
7. Ship a database migration using expand-contract so the release is reversible.
8. Use feature flags to decouple deploy from release without leaving flags on indefinitely.
9. Run smoke tests against real prod after every deploy and block promotion on their failure.
10. Write release notes and a one-page runbook that a stranger could use to redeploy your capstone.

---

Outputs

• one written platform decision with three alternatives and a cost estimate
• one topology diagram and one written justification
• one Terraform root with at least one custom module and a documented state backend
• one .github/workflows/*.yml that builds, tests, and deploys via OIDC
• one preview-environment workflow or one staging promotion workflow
• one recorded rollback rehearsal with start time, end time, and trigger used
• one expand-contract migration pair (SQL up + SQL down) actually run on staging
• one feature flag retired within the same semester it was introduced
• one smoke-test suite wired into the pipeline with at least three real checks
• one release notes template and at least three completed release notes
• one single-page deployment runbook, printable, with owner, trigger, and revert steps

---

Completion Standard

You have completed Module 3 when all of these are true:

• the capstone can be deployed from an empty laptop with only cloud login and the secret store URL
• the pipeline fails closed when tests fail and cannot reach prod without a passing staging or preview run
• a rollback has been executed at least once and the runbook matches what actually happened
• one database migration has shipped using expand-contract and been observed in staging before prod
• release notes exist for every merge to main, even if short
• the runbook fits on one page and has been read by at least one peer who was not the author

If any of those are aspirational instead of demonstrated, the module is not complete.

---

Reading Policy

• Concept pages are the main path.
• S9 module notes are the primary escalation when a concept is unclear.
• External URLs (GitHub Actions docs, Terraform docs, SRE workbook, DORA) are linked per concept and should be opened only for the specific answer they give, not as tutorials.
• "See also (integrative)" on each concept page points to the right S9 module first, then one validated external URL.

---

Suggested Weekly Flow

Week 93 of the capstone:

Day	Work
1	Concepts 1-3; write platform decision and topology sketch
2	Concepts 4-6; scaffold Terraform root with remote state and one module
3	Concepts 7-9; first green pipeline run with OIDC
4	Concepts 10-12; forced rollback rehearsal and first expand-contract migration
5	Concepts 13-15; smoke tests, release note, runbook draft
6	Practice pages 1-2; peer review of runbook
7	Practice 3-4, quiz, runbook finalization

---

Reference

For S9 cross-module lookups and the short list of validated external URLs, use Reference.

---

Rich Learning Pages

Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread