justin/ai-workflow-course
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(course): build out all 27 modules, capstone, scaffold, and conventions

Browse Source 
Scaffold the course repo and author the full curriculum in dependency-chain
order, following the settled build decisions in handoff.md.

- Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5),
  _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config.
- Modules 1-2: reference exemplars (locked for tone/depth/lab style).
- Modules 3-27: full lessons + runnable labs, each following the template,
  respecting the chain, vendor/model-agnostic, with "feel the pain" labs.
- Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22),
  not written from memory; expansion-zone modules carry Verify-before-publish.
- Capstone: the full loop end to end on the running tasks-app example.

Lab code syntax-checked (Python/shell/YAML); every module has the 7 core
template sections.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
This commit is contained in:
Claude (agent)
2026-06-22 12:18:30 -04:00
parent 4bd586bbd0
commit fbec36cb67
117 changed files with 15131 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
modules/18-continuous-delivery-and-deployment/lab/Dockerfile
+24
View File
@@ -0,0 +1,24 @@
# The Module 16 container image for the tasks-app, set to run the HTTP service from serve.py.
#
# This is *what you ship* (Module 16). Continuous delivery/deployment (this module) builds this
# once, tags it with the commit SHA, and runs that exact artifact everywhere.
#
# Note what is NOT here: no secrets, no environment-specific config. Those are injected at run time
# (Module 17), which is why the same image can run in staging and prod unchanged.
FROM python:3.12-slim
WORKDIR /app
# The app is dependency-free (stdlib only), so there is nothing to pip install. Copy the source.
COPY tasks.py cli.py serve.py ./
# Document the port the service listens on.
EXPOSE 8000
# A built-in container health check. The deploy step also checks /health from outside, but this
# lets the runtime itself know whether the container is healthy.
HEALTHCHECK --interval=5s --timeout=3s --retries=3 \
CMD python -c "import urllib.request,sys; sys.exit(0 if urllib.request.urlopen('http://localhost:8000/health').status==200 else 1)"
CMD ["python", "serve.py"]
modules/18-continuous-delivery-and-deployment/lab/cd-starter.yml
+87
View File
@@ -0,0 +1,87 @@
# Starter CD pipeline for the tasks-app — GitHub Actions flavor, extending the Module 14 CI file.
#
# The whole idea: CD is not a new system. It is MORE STAGES on the SAME pipeline, after the checks
# pass. The lint/test gates below are the Module 14 pipeline, unchanged. Everything from the
# `build-and-publish` job down is new in this module.
#
# Where this file goes: .github/workflows/cd.yml (or fold it into your existing ci.yml). On GitLab,
# the same shape is stages in .gitlab-ci.yml with `needs:`/`rules:`; Forgejo/Gitea use Actions-
# compatible YAML. The concept — gated stages from merge to running — is identical everywhere.
#
# VERIFY BEFORE PUBLISH: action versions, the registry login/build-push action names, and the
# manual-approval mechanism all drift. Check current forge docs at build time (see README checklist).
name: CD
on:
push:
branches: [main] # only a MERGE to main triggers a deploy
pull_request: # PRs still run the gates, but never deploy
jobs:
# ---- The Module 14 gates: nothing ships without passing these first. ----------------------------
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install pytest ruff
- run: ruff check . # lint
- run: pytest -q # test
# In a real pipeline a security-scan job (Module 15) would also gate here.
# ---- Build the artifact ONCE and publish it. The unit of deploy is an immutable, SHA-tagged image.
build-and-publish:
needs: check # only runs if the gates passed
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# Log in to your container registry (Module 16's images need a durable home, like a Git remote
# is for commits). Registry/credentials are provider-specific — supply them as secrets,
# never inline (Module 17).
# - uses: docker/login-action@v3
# with:
# registry: ${{ vars.REGISTRY }}
# username: ${{ secrets.REGISTRY_USER }}
# password: ${{ secrets.REGISTRY_TOKEN }}
# Build and push, tagging with the commit SHA (immutable + traceable) and :staging (moving).
# - uses: docker/build-push-action@v6
# with:
# push: true
# tags: |
# ${{ vars.REGISTRY }}/tasks-app:${{ github.sha }}
# ${{ vars.REGISTRY }}/tasks-app:staging
- run: echo "build + push tasks-app:${{ github.sha }} (wire up the registry steps above)"
# ---- Deploy to a NON-prod environment automatically. Safe to do on every merge. ----------------
deploy-staging:
needs: build-and-publish
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
# The five deploy steps live in deploy.sh in this folder. On a real target this would run the
# platform's deploy (kubectl / platform CLI / compose) against the SHA-tagged image, inject
# runtime config + secrets (Module 17), health-check, and roll back on failure.
- run: echo "deploy tasks-app:${{ github.sha }} to STAGING, health-check, roll back if red"
# ---- THIS JOB IS THE DELIVERY-vs-DEPLOYMENT SWITCH. ---------------------------------------------
#
# As written, `environment: production` requires a human to approve before this job runs (set a
# required reviewer on the 'production' environment in the forge). That is CONTINUOUS DELIVERY:
# the artifact is auto-built and staged; a person clicks to ship to prod.
#
# Delete the `environment:` block and this becomes CONTINUOUS DEPLOYMENT: merge -> prod, no human.
# Only remove it once you trust your review + CI + security gates (Modules 10/14/15) more than you
# trust the click. On GitLab the equivalent switch is `when: manual` vs. automatic.
deploy-prod:
needs: deploy-staging
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production # <-- required-reviewer gate = delivery. Remove = deployment.
steps:
- run: echo "deploy tasks-app:${{ github.sha }} to PRODUCTION (gated on human approval)"
modules/18-continuous-delivery-and-deployment/lab/deploy.sh
+95
View File
@@ -0,0 +1,95 @@
#!/usr/bin/env bash
#
# deploy.sh — the deploy step of CD, simulated with a local container run.
#
# The five steps of any deploy, provider-neutral (see the module README):
# 1. build/pull the specific image tag 4. health-check before trusting it
# 2. inject runtime config + secrets 5. cut over if healthy, ROLL BACK if not
# 3. start the new version
#
# The *target* here is your own machine instead of a server, but the logic is the real thing.
#
# Usage:
# ./deploy.sh <tag> # e.g. ./deploy.sh $(git rev-parse --short HEAD)
# BREAK=1 ./deploy.sh <tag># force the new version's health check to fail, to demo rollback
#
# Requires: docker (or `alias docker=podman`), curl.
set -euo pipefail
IMAGE="tasks-app"
CONTAINER="tasks-app"
PORT="8000"
STATE_FILE=".deploy-state" # records the last good tag, for rollback
TAG="${1:-$(git rev-parse --short HEAD)}"
say() { printf '\n=== %s\n' "$*"; }
# --- Step 1: build the artifact for this tag (in real CD this was already built+pushed by CI) -----
say "Building ${IMAGE}:${TAG}"
docker build -t "${IMAGE}:${TAG}" .
# Remember what is currently running so we can roll back to it.
PREVIOUS=""
if [ -f "${STATE_FILE}" ]; then
PREVIOUS="$(cat "${STATE_FILE}")"
fi
# --- Steps 2 + 3: start the new version with runtime config/secrets injected (Module 17) ----------
# Note: APP_VERSION is config supplied at run time, NOT baked into the image. A real deploy would
# also pass secrets here (e.g. --env-file, a mounted secret, or a secrets-manager lookup) — never
# committed, never in the image.
start_version() {
local tag="$1"
docker rm -f "${CONTAINER}" >/dev/null 2>&1 || true
docker run -d --name "${CONTAINER}" \
-p "${PORT}:8000" \
-e "APP_VERSION=${tag}" \
${BREAK:+-e "BREAK=${BREAK}"} \
"${IMAGE}:${tag}" >/dev/null
}
say "Starting ${IMAGE}:${TAG}"
start_version "${TAG}"
# --- Step 4: health-check the new version before trusting it --------------------------------------
healthy() {
for _ in $(seq 1 10); do
if curl -fs "http://localhost:${PORT}/health" >/dev/null 2>&1; then
return 0
fi
sleep 1
done
return 1
}
say "Health-checking http://localhost:${PORT}/health"
if healthy; then
# --- Step 5a: cut over. Record this as the new known-good for the next deploy's rollback target.
echo "${TAG}" > "${STATE_FILE}"
say "DEPLOY OK — ${IMAGE}:${TAG} is live and healthy"
curl -s "http://localhost:${PORT}/health"; echo
exit 0
fi
# --- Step 5b: ROLLBACK. The new version failed its health check. ----------------------------------
say "HEALTH CHECK FAILED for ${IMAGE}:${TAG} — rolling back"
docker rm -f "${CONTAINER}" >/dev/null 2>&1 || true
if [ -z "${PREVIOUS}" ]; then
echo "No previous known-good version to roll back to. Service is DOWN." >&2
echo "(Deploy a healthy version first, then re-run the BREAK=1 deploy to see rollback work.)" >&2
exit 1
fi
# Rollback is trivial because we deploy immutable tags: just run the old one again. No rebuild.
say "Restoring previous good version ${IMAGE}:${PREVIOUS}"
BREAK="" start_version "${PREVIOUS}" # clear BREAK so the good version comes up clean
if healthy; then
say "ROLLED BACK — ${IMAGE}:${PREVIOUS} is live and healthy. The bad deploy reverted itself."
curl -s "http://localhost:${PORT}/health"; echo
exit 1 # exit non-zero: the deploy you asked for did NOT ship, even though service recovered
else
echo "Rollback FAILED — service is DOWN. Investigate ${IMAGE}:${PREVIOUS}." >&2
exit 2
fi
modules/18-continuous-delivery-and-deployment/lab/serve.py
+67
View File
@@ -0,0 +1,67 @@
"""Minimal HTTP face for the tasks-app, so there is something long-running to *deploy*.
Standard library only — no pip install, so the container image stays tiny and the lab has no
dependencies to drift. It reuses the TaskList from tasks.py (Modules 1-2) unchanged.
Run it:
python serve.py # serves on http://localhost:8000
Endpoints:
GET /health -> {"status": "ok", "version": <APP_VERSION>} (200)
GET /tasks -> the current tasks as JSON
Two environment knobs make this realistic for the CD lab (config injected at run time, Module 17):
APP_VERSION what /health reports as the running version (set by deploy.sh to the commit SHA)
BREAK=1 force /health to return 500 — a stand-in for "this build starts but is broken",
used in Part D to trigger an automatic rollback.
"""
import json
import os
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from pathlib import Path
from tasks import Task, TaskList
STATE = Path(__file__).parent / "tasks.json"
PORT = int(os.environ.get("PORT", "8000"))
APP_VERSION = os.environ.get("APP_VERSION", "dev")
BREAK = os.environ.get("BREAK") == "1"
def load() -> TaskList:
if not STATE.exists():
return TaskList()
raw = json.loads(STATE.read_text())
return TaskList(tasks=[Task(**t) for t in raw])
class Handler(BaseHTTPRequestHandler):
def _send(self, code: int, payload: dict) -> None:
body = json.dumps(payload).encode()
self.send_response(code)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
def do_GET(self) -> None:
if self.path == "/health":
# A real health check would also confirm dependencies (db, etc.) are reachable.
if BREAK:
self._send(500, {"status": "unhealthy", "version": APP_VERSION})
else:
self._send(200, {"status": "ok", "version": APP_VERSION})
elif self.path == "/tasks":
tlist = load()
self._send(200, {"tasks": [t.__dict__ for t in tlist.tasks]})
else:
self._send(404, {"error": "not found"})
def log_message(self, *args) -> None: # keep the lab output clean
pass
if __name__ == "__main__":
print(f"serving tasks-app version={APP_VERSION} on http://localhost:{PORT}")
ThreadingHTTPServer(("0.0.0.0", PORT), Handler).serve_forever()