Execute deployment workflows with pre-flight checks, environment validation, health verification, and rollback procedures. Use this skill whenever someone asks to deploy, push to staging, release to production, or says things like "deploy to staging", "release this to production", "run the deployment checklist", "is this ready to deploy", "execute the release", or "roll back the deployment". Also trigger when someone mentions deployment readiness, smoke tests after deploy, rollback procedures, or canary/blue-green deployment strategy.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
deploy
description
Execute deployment workflows with pre-flight checks, environment validation, health verification, and rollback procedures. Use this skill whenever someone asks to deploy, push to staging, release to production, or says things like "deploy to staging", "release this to production", "run the deployment checklist", "is this ready to deploy", "execute the release", or "roll back the deployment". Also trigger when someone mentions deployment readiness, smoke tests after deploy, rollback procedures, or canary/blue-green deployment strategy.
model
sonnet
agent
devops-engineer
context
fork
disable-model-invocation
true
argument-hint
staging or production
hooks
[{"event":"PreToolUse","matcher":"Bash","type":"prompt","prompt":"DEPLOYMENT GATE: The user has invoked the /deploy skill. Before executing any Bash command, verify:\n1. Is the current git branch clean? (no uncommitted changes)\n2. Has the user confirmed the target environment (staging/production)?\n3. For production: Has a staging deployment succeeded first?\nIf any check fails, BLOCK the command and explain what must be resolved first.\nDo NOT block read-only commands (git status, curl health checks, docker-compose ps).\n"}]
Deploy
Execute deployments safely with pre-flight validation, step-by-step execution, and rollback procedures. This skill is user-invoked only — deployments are never triggered automatically.
Pre-Flight Checklist
Complete every item before proceeding with deployment.
Code Readiness
All CI checks pass on the deployment branch (tests, lint, build).
Code has been reviewed and approved via pull request.
No open merge conflicts with the target branch.
All dependent PRs have been merged.
Version number or release tag is updated if applicable.
Database
Database migrations are tested in staging.
Migration rollback is tested and documented.
Migrations are backwards-compatible with the current application version.
Large data migrations have been estimated for duration and load impact.
Configuration
Environment variables for the target environment are set and verified.
Secrets and credentials are in the secrets manager (not in code or env files).
Feature flags are configured for the target environment.
Third-party service configurations (API keys, webhook URLs) are updated.
Dependencies
No known critical vulnerabilities in dependencies.
Lock files are up to date and committed.
External service dependencies are healthy (check status pages).
Communication
Team is notified of the deployment window.
Stakeholders are informed of changes being deployed.
On-call engineer is available for the deployment window.
Deployment Procedure
Step 1: Environment Verification
Verify the target environment is healthy before deploying:
# Check current application health
curl -s https://{environment}/health | jq .
# Verify database connectivity
curl -s https://{environment}/health/db | jq .
# Check current deployed version
curl -s https://{environment}/version | jq .
# Verify external service connectivity
curl -s https://{environment}/health/dependencies | jq .
Step 2: Create Deployment Record
# Tag the release
git tag -a v{version} -m "Release v{version}: {description}"
git push origin v{version}
Deploy frequently (after each PR merge or on a schedule).
Run full test suite after deployment.
Use production-like data (anonymized).
Test migrations with realistic data volume.
Production
Deploy during business hours when the team is available (unless zero-downtime is verified).
Use canary or blue-green deployment when available.
Have a rollback plan ready before starting.
Monitor for at least 30 minutes after deployment.
Avoid deploying on Fridays unless the change is critical and low-risk.
Advanced Deployment Strategies
Canary Deployment (ECS)
Roll out to a small subset of traffic before full deployment:
# 1. Deploy canary task definition (new version)
aws ecs create-service --cluster production \
--service-name rails-app-canary \
--task-definition rails-app:NEW_REVISION \
--desired-count 1
# 2. Configure ALB weighted target group (10% to canary)
aws elbv2 modify-rule --rule-arn $RULE_ARN \
--actions '[
{"Type":"forward","ForwardConfig":{
"TargetGroups":[
{"TargetGroupArn":"'$PRIMARY_TG'","Weight":90},
{"TargetGroupArn":"'$CANARY_TG'","Weight":10}
]
}}
]'# 3. Monitor canary for 15 minutes# Check: error rate, latency p95, CPU/memory, business metrics# Compare canary metrics vs primary metrics# 4a. If healthy — shift traffic progressively: 10% → 25% → 50% → 100%# 4b. If unhealthy — abort: set canary weight to 0, delete canary service
Canary Validation Criteria
Error rate delta < 0.5% compared to primary
Latency p95 delta < 50ms compared to primary
No new error types in logs
Business metrics (conversion, transactions) within normal range
Blue-Green Deployment (ECS)
Maintain two identical environments, switch traffic atomically:
# 1. Deploy new version to green (inactive) environment
aws ecs update-service --cluster production \
--service rails-app-green \
--task-definition rails-app:NEW_REVISION
# 2. Wait for green to stabilize
aws ecs wait services-stable --cluster production --services rails-app-green
# 3. Run smoke tests against green
curl -s https://green.api.example.com/health | jq .
# 4. Switch ALB listener to green target group
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
--default-actions '[{"Type":"forward","TargetGroupArn":"'$GREEN_TG'"}]'# 5. Monitor for 15 minutes# 6a. If stable — green is now primary. Update blue for next deployment.# 6b. If issues — switch listener back to blue (instant rollback)
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
--default-actions '[{"Type":"forward","TargetGroupArn":"'$BLUE_TG'"}]'
Blue-Green Prerequisites
Two identical ECS services (blue + green) behind the same ALB
Shared RDS database (migrations must be backward-compatible)
Shared Redis/ElastiCache instance
DNS or ALB listener swap for traffic routing
Web Frontend Deployments
Vercel Deployment (Next.js)
Git-Based (Recommended)
Connect GitHub repository in Vercel dashboard.
Configure environment variables per environment (preview, production).
Every push creates a preview deployment. Merges to main deploy to production.
CLI-Based
# Install Vercel CLI
npm i -g vercel
# Deploy preview (from next/ directory)cd next && vercel
# Deploy to production
vercel --prod
# Rollback to previous deployment
vercel rollback
