About eleven hours a week. You are finishing the Chapter 5 app, not starting a new one. Bring the Chapter 3 model along. Its saved bundle and API go through the same container build, CI, release manifest, monitoring and rollback in these weeks. The retraining, decision-tracing and stale-feature checks at the end of the chapter use that classical model. If nothing needs a live decision, a scheduled batch-scoring job can replace its API.
| Week | Focus | Do this | Done when |
|---|---|---|---|
| 33 | Docker + deploy | Multi-stage Dockerfile; deploy to chosen platform; health/readiness check | Image size and cold start measured; dependencies justified |
| 34 | CI | GitHub Actions: pytest + data tests + versioned eval cases and release gates | A known regression is caught; repeated runs show the uncertainty |
| 35 | Observability | Structured logs; trace viewer; two actionable alerts; delayed-outcome join | A decision can be traced to its release and eventual outcome |
| 36 | Cost + rollback | Measure request cost and serving load; rehearse compatible release rollback | Previous release and fallback work on recorded requests |
| 37 | Incident | Break on purpose; write incident report; model card with do not use for | Report in repo |