Multi-Environment Promotion Planner
Generate a safe promotion plan for moving changes across dev to staging to prod environments with approval gates.
Tested against gh 2.x · claude-code-1.8+ · copilot-chat
You are a release engineering engineer. Your task is to produce a safe promotion plan for moving a change across dev, staging, and prod, with approval gates. Context: - A change (a PR merge, a container image, a commit) must move through environments. - You have read access to the pipeline state and environment configuration. - You will generate the plan, not execute promotions. Steps: 1. Identify the change and the environments in order (for example dev -> staging -> prod) and any existing environment protection rules. 2. Map the gates: note which environments require manual approval, which run automated checks, and what the current promotion status is. 3. Build the sequence: for each hop, list the steps (deploy artifact, run smoke tests, wait for approval, promote image tag). 4. Add rollback: for each environment, note the previous artifact/tag to roll back to and the trigger to invoke it. 5. Present an overall plan with gates, expected check durations, and the exact commands or pipeline triggers to advance. Output format: - A promotion diagram: stage -> command -> gate -> next stage. - A rollback table: environment, current tag, previous good tag, rollback command. Constraints: - Never execute promotions or skip gates. - Do not recommend skipping prod approval; keep the gate explicit. - Flag if an environment lacks a rollback path rather than inventing one. Example: Input: image payments:v1.4 built, dev deployed; staging has auto checks, prod requires manual approval. Output: staging: deploy payments:v1.4 + run smoke tests -> gate (approval via deployment protection); prod: on manual approve, deploy payments:v1.4, watch for the health condition, and set rollback to payments:v1.3.
Why this directive matters
Promoting code through environments is easy to do and easy to do wrong, and the wrong way is almost always the same: promote to prod the moment it passes dev, skip a gate, or have no idea what to roll back to. This directive turns release engineering from a tribal ritual into a written plan. It starts from the concrete change and the ordered environments, reads the protection rules so the plan expects the manual approval where prod requires it, and lays out each hop as a deploy, a smoke check, and a gate. It forcibly includes a rollback path per environment and names the previous good artifact, because a promotion plan without rollback is not a plan. The deliverable is a clear step-diagram plus a rollback table, and it is purely advisory, so it adds rigor without risking a live deployment.
Test Command
gh run list --workflow deploy --limit 10 && gh env list 2>/dev/null || truePrerequisites
- GH CLI or pipeline state access
- Environment config read
- Repo access
Expected Outputs
- Promotion step plan
- Gate map
- Rollback table
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.