Title: Lab 15 — Ship, Watch, and Right-Size- An End-to-End Deployment Pipeline
Course: AIINFRA 101: Applied Infrastructure & Containerization > Section: Week 15 — Automated Model Deployment, Monitoring & Cost Optimization

🛠️ Lab 15 — Ship, Watch, and Right-Size: An End-to-End Deployment Pipeline (50 pts)

Goal: Chain together the tools you've used throughout this course into one automated pipeline that takes a code push to a deployed, monitored, cost-checked model service — at zero infrastructure cost.

Steps

1. Prepare your model service. Reuse (or rebuild) a small FastAPI app that serves a model via a /predict endpoint and a /health endpoint, containerized with a Dockerfile — this should look familiar from earlier weeks of this course. Confirm it runs locally with docker build and docker run.
2. Write the CI stage. Create .github/workflows/pipeline.yml, triggered on: push, with a job that installs dependencies and runs your pytest suite (at least 2–3 tests) as a quality gate the pipeline must stop for if it fails.
3. Containerize and push to a registry. After tests pass, add a job that builds the image and pushes it to GitHub Container Registry (ghcr.io) using the built-in GITHUB_TOKEN.
4. Add a manual-approval gate, then auto-deploy. Create a protected deploy Environment in GitHub (Settings → Environments) requiring a reviewer. Connect your GHCR image to Render's free tier or a Hugging Face Space (Docker SDK) configured to auto-redeploy on new image pushes, gated behind that approval. Confirm a push to main results in a live, updated endpoint only after you approve it.
5. Instrument monitoring. Add a /metrics-style check or a CloudWatch alarm (free tier) on request latency or basic resource usage for your deployed service, plus one simple dashboard or log view showing real (non-flat) data after you generate a few requests. Screenshot it.
6. Add a cost/right-sizing check. Note the compute tier/instance size your service is running on and its actual observed CPU/memory usage under light load (e.g., via docker stats or your host's metrics). Write 3–5 sentences on whether it's right-sized, over-provisioned, or under-provisioned, and what you'd change before committing to any reserved/long-term pricing.
7. Run the rollback exercise. Intentionally push a "broken" change (e.g., an endpoint that returns malformed responses). Let it deploy, then git revert the commit and confirm the revert triggers your pipeline and redeploys the last-known-good version automatically.
8. Document it. In your README, map each stage of your pipeline to the 6-stage architecture from lecture (commit → CI → containerize → CD deploy → monitoring → auto-rollback), noting which stages are fully automated and which still require your manual approval.

Deliverables:

Submit your GitHub repo URL (workflow file(s), Dockerfile, README), your live deployment URL, a screenshot of the approval gate, your monitoring screenshot, your right-sizing write-up, and evidence of the automatic redeploy after your git revert (200–300 word reflection or screenshots).