Deploy to Production

<mission_control> Deploy application to production with comprehensive safety checks and emergency rollback capability <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"> Prevent deployment if ANY check fails. These are non-negotiable requirements.

<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

npm run build
npm test

3. Build Docker Image

docker build -t myapp:$VERSION .
docker tag myapp:$VERSION myapp:latest

4. Push to Registry

docker push myapp:$VERSION
docker push myapp:latest

5. Deploy to Kubernetes

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> Emergency rollback when deployment fails or health checks fail <trigger_conditions>

• Health checks fail after 5 minutes
• Error rate exceeds 5% for 2 minutes
• Manual abort triggered
• Database migration failures </trigger_conditions>

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