MODULE 10 / 18 · PART 4 · SHIP & SUSTAIN
DevOps, CI/CD & Deployment
Assume the deploy will go wrong; design the detection, the rollback and the blast radius.
THE SHORT ANSWER
What this module changes.
Every change needs an undo button with a measured cost. Ask for the rollback steps, the health signals, and the exact point of no return.
Shipping prompts should assume the deploy will go wrong and ask how you will know and how you will undo it.
Many teams deploy from a laptop to a single VPS, a shared host or a container behind a modest connection. That makes rollback discipline and backward-compatible migrations more important, not less. Design the deploy around the connection you actually have.
THE MODULE PROMPT LIBRARY
20 prompts for devops & deployment.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
What is the rollback plan for this change? Give me the exact steps and the time to recover.
Why it worksEvery change needs an undo button with a measured cost.
Design the deployment strategy for [change]: blue/green, canary, or rolling — and why that one here.
Why it worksTies the strategy to the change's risk profile.
What are the health signals that tell us this deploy is going badly, and how long before we would notice?
Why it worksDetection time is the metric that determines outage length.
Write the CI pipeline for [project]: stages, gates, caching, and the failure modes of the pipeline itself.
Why it worksPipelines fail too; designing for that keeps the team unblocked.
What should be a blocking gate in CI and what should be advisory? Justify each.
Why it worksToo many gates and people bypass them; too few and quality slips.
Design the database migration for [change] so it is backward compatible with the previous application version.
Why it worksBackward-compatible migrations are what make zero-downtime deploys possible.
What is the expand/contract sequence for this schema change? Give me each step and the deploy order.
Why it worksExpand/contract is the safe pattern; spelling it out prevents lockstep deploys.
Write the runbook for deploying [service]: pre-checks, steps, verification, and rollback triggers.
Why it worksA runbook turns a scary deploy into a routine one.
What configuration is different between environments, and how do we prevent drift?
Why it worksConfig drift is a top cause of "works in staging" failures.
Design the feature flag lifecycle for [feature]: creation, rollout stages, metrics, and removal.
Why it worksFlags without a removal plan become permanent complexity.
What is the blast radius of a bad deploy of [service], and how do we limit it before we need to?
Why it worksLimiting blast radius is cheaper than recovering from it.
Write the alerting rules for [service]: what pages, what tickets, and what is deliberately silent.
Why it worksAlert fatigue is a reliability risk; silence is a design choice.
What is our mean time to recovery for [failure mode], and what would halve it?
Why it worksMTTR is the metric that most improves reliability per unit of effort.
Design the infrastructure as code for [component] with the state, the modules, and the drift detection.
Why it worksIaC without drift detection is configuration that rots silently.
What happens during a rolling deploy to in-flight requests? Show me the connection draining and the retry behavior.
Why it worksIn-flight requests are where deploys cause user-visible errors.
Write the smoke test that runs immediately after deploy and proves the service is actually serving traffic.
Why it worksDeploy success is not the same as service health.
What is the cost model for this infrastructure, and where does it scale non-linearly?
Why it worksCost surprises are reliability incidents with a finance flavor.
Design the secrets management for [service]: storage, rotation, access, and audit.
Why it worksRotation is the part everyone forgets until they need it urgently.
What is the disaster recovery plan for [system], and when did we last test it?
Why it worksAn untested DR plan is a hypothesis, not a plan.
Review this deployment for the ways it can fail partially: some instances new, some old, some state migrated.
Why it worksPartial failure is the hardest deploy failure to diagnose.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Write the rollback runbook for your last deploy. Time yourself executing it in staging and fix the step that surprised you.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.