Deploy to production environments with safety checks. Use when releasing code to production. Not for staging deploys or local builds unless specifically requested.
Installs into .claude/skills of the current project.
Are you the author of Deploy Production Majiayu000?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/diegosouzapw-deploy-production-majiayu000)
---
name: deploy-production
description: "Deploy to production environments with safety checks. Use when releasing code to production. Not for staging deploys or local builds unless specifically requested."
disable-model-invocation: true
user-invocable: true
context: fork
agent: Plan
allowed-tools: Read, Bash(docker:*), Bash(kubectl:*)
---
# Deploy to Production
<mission_control>
<objective>Deploy application to production with comprehensive safety checks and emergency rollback capability</objective>
<success_criteria>Deployment succeeds with zero downtime, all health checks pass, rollback procedure documented and tested</success_criteria>
</mission_control>
<safety_gate type="blocking" phase="pre_deployment">
<purpose>Prevent deployment if ANY check fails. These are non-negotiable requirements.</purpose>
<checks>
- <check id="tests_pass">
<command>npm test</command>
<expected>Exit code 0, all tests pass</expected>
<failure_mode>BLOCK deployment</failure_mode>
</check>
- <check id="code_review">
<requirement>Recent commits reviewed and approved</requirement>
<verification>Check PR approval status in git log</verification>
<failure_mode>BLOCK deployment</failure_mode>
</check>
- <check id="migrations_tested">
<requirement>Database migrations tested in staging</requirement>
<verification>Run migrations on staging database</verification>
<failure_mode>BLOCK deployment</failure_mode>
</check>
- <check id="backups_current">
<requirement>Backups current and tested (within 24h)</requirement>
<verification>Check backup timestamp and restore test log</verification>
<failure_mode>BLOCK deployment</failure_mode>
</check>
- <check id="deployment_plan">
<requirement>Deployment plan documented in runbook</requirement>
<verification>Review docs/deployments/YYYY-MM-DD-plan.md</verification>
<failure_mode>BLOCK deployment</failure_mode>
</check>
- <check id="rollback_ready">
<requirement>Rollback procedure prepared and tested</requirement>
<verification>Confirm rollback script exists and was tested</verification>
<failure_mode>BLOCK deployment</failure_mode>
</check>
- <check id="monitoring_configured">
<requirement>Monitoring and alerting configured for new deployment</requirement>
<verification>Verify alerts exist in monitoring system</verification>
<failure_mode>BLOCK deployment</failure_mode>
</check>
- <check id="team_notified">
<requirement>Team notified of deployment window</requirement>
<verification>Check deployment calendar or Slack announcement</verification>
<failure_mode>BLOCK deployment</failure_mode>
</check>
</checks>
<gate_validation>
MANDATORY: Run each check sequentially. If ANY check fails, STOP and resolve before continuing.
DO NOT PROCEED unless ALL items are verified.
</gate_validation>
</safety_gate>
## Deployment Process
<logic_flow>
digraph Deployment {
rankdir=TD;
node [shape=box];
Verify [label="1. Verify Checklist"];
Build [label="2. Build & Test"];
Docker [label="3. Build Docker"];
Push [label="4. Push Registry"];
Deploy [label="5. Apply K8s"];
Check [label="6. Verify Health"];
Success [label="Deployment Success" style=filled fillcolor=lightgreen];
Rollback [label="Rollback Procedure" style=filled fillcolor=lightpink];
Verify -> Build;
Build -> Docker;
Docker -> Push;
Push -> Deploy;
Deploy -> Check;
Check -> Success [label="Health OK"];
Check -> Rollback [label="Errors"];
Rollback -> Verify [label="Fix & Retry"];
}
</logic_flow>
### 1. Pre-Deployment Verification
Complete the checklist above and verify all systems are ready.
### 2. Build Application
```bash
npm run build
npm test
```
### 3. Build Docker Image
```bash
docker build -t myapp:$VERSION .
docker tag myapp:$VERSION myapp:latest
```
### 4. Push to Registry
```bash
docker push myapp:$VERSION
docker push myapp:latest
```
### 5. Deploy to Kubernetes
```bash
kubectl apply -f manifests/production/
kubectl rollout status deployment/myapp
```
### 6. Verify Deployment
- [ ] Health checks passing
- [ ] Logs show no errors
- [ ] Metrics within normal range
- [ ] Smoke tests pass
### 7. Post-Deployment
- [ ] Update documentation
- [ ] Notify team of successful deployment
- [ ] Monitor for 30 minutes
- [ ] Update deployment tracker
## Safety Features
This skill includes:
- **Manual-only invocation** - Cannot be auto-triggered
- **XML-defined safety gates** - Blocking checks with machine-readable validation
- **Emergency rollback** - Automated rollback procedure in XML
- **Verification steps** - Ensures deployment success
## Rollback Procedure
<rollback_procedure>
<purpose>Emergency rollback when deployment fails or health checks fail</purpose>
<trigger_conditions>
- <condition>Health checks fail after 5 minutes</condition>
- <condition>Error rate exceeds 5% for 2 minutes</condition>
- <condition>Manual abort triggered</condition>
- <condition>Database migration failures</condition>
</trigger_conditions>
<steps sequential="true">
<step id="1" action="immediate_rollback">
<command>kubectl rollout undo deployment/myapp</command>
<timeout>30 seconds</timeout>
<expected>Rollback initiated, previous version restored</expected>
</step>
<step id="2" action="verify_rollback">
<command>kubectl rollout status deployment/myapp</command>
<timeout>120 seconds</timeout>
<expected>Rollback complete, deployment healthy</expected>
</step>
<step id="3" action="investigate_root_cause">
<investigation>
- Check logs: `kubectl logs -f deployment/myapp --tail=100`
- Review metrics: Error rates, latency, CPU/memory
- Identify: What changed, why it failed
- Document: Create incident report
</investigation>
</step>
<step id="4" action="prepare_fix">
<actions>
- Fix the issue in code
- Test in staging environment
- Update deployment plan with lessons learned
- Get approval for re-deployment
</actions>
</step>
<step id="5" action="redeploy">
<actions>
- Follow full deployment process again
- All safety gates MUST pass
- Enhanced monitoring for first hour
</actions>
</step>
</steps>
</rollback_procedure>
## Integration
This skill integrates with:
- `ci-pipeline-manager` - CI/CD pipeline integration
- `backend-patterns` - Deployment best practices
---
## Absolute Constraints (Non-Negotiable)
<critical_constraint>
**MANDATORY: ALL safety gates MUST pass before deployment**
- Run each check sequentially
- If ANY check fails, STOP and resolve
- NO exceptions, NO "looks good" rationalization
- Document why gate failed and how it was fixed
**MANDATORY: Rollback procedure MUST be tested before deployment**
- Verify rollback script exists
- Test rollback in staging
- Confirm previous version is stable
- Document rollback success criteria
**MANDATORY: Monitor deployment for 30 minutes after success**
- Health checks must remain passing
- Error rates must stay below threshold
- Logs must show no errors
- Team must be available for immediate response
**MANDATORY: Document ALL deployments**
- Update deployment tracker
- Document any issues or deviations
- Create incident report if rollback occurred
- Share lessons learned with team
**DANGER ZONE: Production deployment is irreversible without rollback**
- Treat every deployment as potentially breaking
- Assume rollback will be needed (hope for best, prepare for worst)
- Never deploy Friday afternoon or before holidays
- Always have team on standby during deployment window
**No exceptions. No short-cuts. Production is not a place for "good enough."**
</critical_constraint>
---
## Genetic Code
This component carries essential Seed System principles for context: fork isolation:
<critical_constraint>
MANDATORY: All components MUST be self-contained (zero .claude/rules dependency)
MANDATORY: Achieve 80-95% autonomy (0-5 AskUserQuestion rounds per session)
MANDATORY: Description MUST use What-When-Not format in third person
MANDATORY: No component references another component by name in description
MANDATORY: Progressive disclosure - references/ for detailed content
MANDATORY: Use XML for control (mission_control, critical_constraint), Markdown for data
No exceptions. Portability invariant must be maintained.
</critical_constraint>
**Delta Standard**: Good Component = Expert Knowledge − What Claude Already Knows
**Recognition Questions**:
- "Would Claude know this without being told?" → Delete (zero delta)
- "Can this work standalone?" → Fix if no (non-self-sufficient)
- "Did I read the actual file, or just see it in grep?" → Verify before claiming
---