name: deployment-procedures
description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
allowed-tools: Read, Glob, Grep, Bash
Deployment Procedures
Deployment principles and decision-making for safe production releases.
Learn to THINK, not memorize scripts.
⚠️ How to Use This Skill
This skill teaches deployment principles, not bash scripts to copy.
- Every deployment is unique
- Understand the WHY behind each step
- Adapt procedures to your platform
1. Platform Selection
Decision Tree
What are you deploying?
│
├── Static site / JAMstack
│ └── Vercel, Netlify, Cloudflare Pages
│
├── Simple web app
│ ├── Managed → Railway, Render, Fly.io
│ └── Control → VPS + PM2/Docker
│
├── Microservices
│ └── Container orchestration
│
└── Serverless
└── Edge functions, Lambda
Each Platform Has Different Procedures
| Platform |
Deployment Method |
| Vercel/Netlify |
Git push, auto-deploy |
| Railway/Render |
Git push or CLI |
| VPS + PM2 |
SSH + manual steps |
| Docker |
Image push + orchestration |
| Kubernetes |
kubectl apply |
2. Pre-Deployment Principles
The 4 Verification Categories
| Category |
What to Check |
| Code Quality |
Tests passing, linting clean, reviewed |
| Build |
Production build works, no warnings |
| Environment |
Env vars set, secrets current |
| Safety |
Backup done, rollback plan ready |
Pre-Deployment Checklist
3. Deployment Workflow Principles
The 5-Phase Process
1. PREPARE
└── Verify code, build, env vars
2. BACKUP
└── Save current state before changing
3. DEPLOY
└── Execute with monitoring open
4. VERIFY
└── Health check, logs, key flows
5. CONFIRM or ROLLBACK
└── All good? Confirm. Issues? Rollback.
Phase Principles
| Phase |
Principle |
| Prepare |
Never deploy untested code |
| Backup |
Can't rollback without backup |
| Deploy |
Watch it happen, don't walk away |
| Verify |
Trust but verify |
| Confirm |
Have rollback trigger ready |
4. Post-Deployment Verification
What to Verify
| Check |
Why |
| Health endpoint |
Service is running |
| Error logs |
No new errors |
| Key user flows |
Critical features work |
| Performance |
Response times acceptable |
Verification Window
- First 5 minutes: Active monitoring
- 15 minutes: Confirm stable
- 1 hour: Final verification
- Next day: Review metrics
5. Rollback Principles
When to Rollback
| Symptom |
Action |
| Service down |
Rollback immediately |
| Critical errors |
Rollback |
| Performance >50% degraded |
Consider rollback |
| Minor issues |
Fix forward if quick |
Rollback Strategy by Platform
| Platform |
Rollback Method |
| Vercel/Netlify |
Redeploy previous commit |
| Railway/Render |
Rollback in dashboard |
| VPS + PM2 |
Restore backup, restart |
| Docker |
Previous image tag |
| K8s |
kubectl rollout undo |
Rollback Principles
- Speed over perfection: Rollback first, debug later
- Don't compound errors: One rollback, not multiple changes
- Communicate: Tell team what happened
- Post-mortem: Understand why after stable
6. Zero-Downtime Deployment
Strategies
| Strategy |
How It Works |
| Rolling |
Replace instances one by one |
| Blue-Green |
Switch traffic between environments |
| Canary |
Gradual traffic shift |
Selection Principles
| Scenario |
Strategy |
| Standard release |
Rolling |
| High-risk change |
Blue-green (easy rollback) |
| Need validation |
Canary (test with real traffic) |
7. Emergency Procedures
Service Down Priority
- Assess: What's the symptom?
- Quick fix: Restart if unclear
- Rollback: If restart doesn't help
- Investigate: After stable
Investigation Order
| Check |
Common Issues |
| Logs |
Errors, exceptions |
| Resources |
Disk full, memory |
| Network |
DNS, firewall |
| Dependencies |
Database, APIs |
8. Anti-Patterns
| ❌ Don't |
✅ Do |
| Deploy on Friday |
Deploy early in week |
| Rush deployment |
Follow the process |
| Skip staging |
Always test first |
| Deploy without backup |
Backup before deploy |
| Walk away after deploy |
Monitor for 15+ min |
| Multiple changes at once |
One change at a time |
9. Decision Checklist
Before deploying:
10. Environment Separation (MANDATORY)
[!CAUTION]
.env.local MUST NEVER contain production credentials. Every environment (dev, staging, prod)
MUST have its own isolated configuration.
Rules
| Environment |
File |
Allowed Content |
| Development |
.env.local |
Local/dev URLs only. Mock keys or dev API keys |
| Staging |
.env.staging |
Staging URLs, staging API keys |
| Production |
.env.production |
Production URLs, live API keys |
Environment Strategy Template (for TDD)
Include this section in every TDD document:
## Environment Strategy
| Service | Dev | Staging | Prod |
|---------|-----|---------|------|
| Database | Local SQLite / Supabase dev | Supabase staging | Supabase prod |
| Auth | Dev keys | Staging keys | Prod keys |
| API URL | http://localhost:3000 | https://staging.app.com | https://app.com |
| Payment | Stripe test mode | Stripe test mode | Stripe live mode |
### Separation Rules
- `.env.local` = dev ONLY. Never prod credentials.
- Deployment platform (Vercel/Railway) manages prod env vars.
- CI/CD uses staging vars for preview deploys.
Pre-Deploy Environment Discovery Gate
Before ANY deployment, ask the user:
⚠️ ENVIRONMENT DISCOVERY — {project name}
[ ] How many environments? (dev / staging / prod)
[ ] Where is each deployed? (Vercel, Railway, VPS, etc.)
[ ] Are env vars configured on the deployment platform?
[ ] Is .env.local pointing to DEV (not prod)?
[ ] Database migrations ready for target environment?
Historical Lesson: Project ran for 10 sprints with .env.local pointing to production Supabase.
Every developer was reading/writing production data during development—discovered only at Sprint 10.
Fix: mandatory environment separation in TDD and pre-deploy check.
11. Best Practices
- Small, frequent deploys over big releases
- Feature flags for risky changes
- Automate repetitive steps
- Document every deployment
- Review what went wrong after issues
- Test rollback before you need it
Remember: Every deployment is a risk. Minimize risk through preparation, not speed.
By