Deployment Plan and Operations Runbook
5 weeks · 0 milestones
Produce a deployment plan and operations runbook for a real software system covering: a step-by-step deployment procedure with pre-conditions, execution steps, and post-deployment verification for at least one environment (staging or production), a rollback procedure with decision criteria for when to roll back, an incident response procedure for the 3 most likely failure modes with documented detection, diagnosis, and recovery steps, and an on-call guide documenting the operational state of the system (what healthy looks like, what alerts fire under what conditions). Preferred proof: the runbook for a live system you operate. Accessible alternative: a runbook for a real open-source system you have deployed locally (Railway free tier, Render free tier, or similar) — documented evidence of actual deployment required, not a hypothetical. Proof artifacts: deployment procedure document (design artifact) and runbook with rollback procedure (documentation artifact). Verification: someone who has operated production systems reviews 'would I be able to bring this system back up from a cold start using this runbook alone?' and 'what happens if the rollback itself fails?'
Milestone map
Milestone map
3 milestones
Produce a system architecture diagram and a complete inventory of the deployment components for a real or realistic software system. The system must include at least three distinct components (e.g. a web application, a database, and a background job runner; or a microservice, an API gateway, and a message queue). For each component: identify the runtime environment (container, VM, serverless function, managed service), the configuration sources (environment variables, secrets manager, config files), the dependencies on other components or external services, and the expected steady-state health signals. Free tools: draw.io for the architecture diagram; GitHub or a public git repository for storing the runbook.
Proof required
Submit: (1) an architecture diagram showing all components with their runtime environments and inter-component dependencies labelled (arrows with protocol and direction — e.g. 'HTTPS/443', 'PostgreSQL/5432'); (2) a component inventory table (component name, runtime environment, config sources, dependencies, health signal); (3) a brief scope statement (100–150 words) confirming whether this is a real system you operate or a realistic reference architecture, and why the system has been bounded where it has.
What gets checked
- Architecture diagram labels every connection with the protocol and port — 'arrow from app to DB' without protocol/port is not an engineering diagram
- Component inventory table is complete for all components in the diagram — every box in the diagram has a row in the table; missing rows indicate components not understood well enough to document
- Scope statement addresses the system boundary explicitly — what is inside the runbook scope and what is treated as external (e.g. 'the CDN is treated as external; only the origin servers are in scope')