Chapter 6: Production Deployment & Release Management¶
From Staging to Production – Safely and Reliably
Part of: The DevOps Engineer's Guide to Effective AI Usage
Table of Contents¶
- Executive Summary – Why Production Is Different
- Part 1: Production vs. Non-Production – Critical Differences
- Part 2: Production Deployment Strategies
- Part 3: Release Management – Versioning & Rollback
- Part 4: Production Readiness Checklist
- Part 5: Production Incident Response
- Part 6: VSCode Integration for Production Workflows
- Part 7: Iteration Points – Your Feedback Needed
- Appendix: Production Templates & Checklists
1. Executive Summary – Why Production Is Different ¶
The Hard Truth About Production¶
┌─────────────────────────────────────────────────────────────┐
│ PRODUCTION VS. NON-PRODUCTION │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Non-Production (Dev/Staging)] │
│ • Speed is prioritized │
│ • Failures are learning opportunities │
│ • Rollback is optional │
│ • Human oversight is minimal │
│ • AI Agents can have more autonomy │
│ │
│ [Production] │
│ • Stability is prioritized │
│ • Failures cost money and reputation │
│ • Rollback must be fast and reliable │
│ • Human oversight is required │
│ • AI Agents need strict boundaries │
│ │
│ [Key Insight] │
│ Chapters 3-5 built the structure │
│ Chapter 6 applies it to production │
│ Chapter 10 adds AI Agents (with production safeguards) │
│ │
└─────────────────────────────────────────────────────────────┘
Why This Chapter Exists¶
Chapter 3 taught you: Structured IaC (InfraCtl)
Chapter 4 taught you: Structured Deployment (Ansible)
Chapter 5 taught you: Structured CI/CD (Pipelines + Runners)
Chapter 6 teaches you: How to deploy to PRODUCTION safely, with release management, rollback, and incident response
Chapter 10 will teach you: AI Agents that operate within ALL these production safeguards
The Core Thesis¶
"Production deployment requires more than structured pipelines. It requires release management, rollback procedures, incident response, and production readiness validation. This chapter provides the production deployment framework that Chapter 10 AI Agents will operate within."
What You'll Learn¶
| Section | What You'll Gain | Why It Matters |
|---|---|---|
| Part 1: Production Differences | Understand why production is different | Avoid costly mistakes |
| Part 2: Deployment Strategies | Choose the right strategy for your risk | Minimize downtime |
| Part 3: Release Management | Versioning, changelog, rollback | Traceability and recovery |
| Part 4: Production Readiness | Checklist before deploying | Prevent incidents |
| Part 5: Incident Response | What to do when things go wrong | Minimize impact |
| Part 6: VSCode Integration | Integrate production workflows | Daily productivity |
2. Part 1: Production vs. Non-Production – Critical Differences ¶
2.1 The Production Mindset¶
┌─────────────────────────────────────────────────────────────┐
│ PRODUCTION MINDSET │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Principle 1: Stability Over Speed] │
│ • Dev: Deploy 10 times/day ✓ │
│ • Prod: Deploy 1 time/week with confidence ✓ │
│ • Trade-off: Speed for stability │
│ │
│ [Principle 2: Human Oversight] │
│ • Dev: Auto-deploy on commit ✓ │
│ • Prod: Human approval required ✓ │
│ • Trade-off: Convenience for safety │
│ │
│ [Principle 3: Rollback Readiness] │
│ • Dev: Fix forward is fine ✓ │
│ • Prod: Must rollback in <5 minutes ✓ │
│ • Trade-off: Complexity for recovery │
│ │
│ [Principle 4: Monitoring First] │
│ • Dev: Monitor after deploy ✓ │
│ • Prod: Monitor before, during, after ✓ │
│ • Trade-off: Effort for visibility │
│ │
│ [Principle 5: Documentation Required] │
│ • Dev: Code is documentation ✓ │
│ • Prod: Runbooks, playbooks, contacts ✓ │
│ • Trade-off: Time for operational readiness │
│ │
└─────────────────────────────────────────────────────────────┘
2.2 Production Boundaries (For Future AI Agents)¶
┌─────────────────────────────────────────────────────────────┐
│ PRODUCTION BOUNDARIES FOR AI AGENTS (Chapter 10) │
├─────────────────────────────────────────────────────────────┤
│ │
│ [AI Agents CAN in Production] │
│ ✓ Monitor deployment health │
│ ✓ Alert on anomalies │
│ ✓ Suggest rollback if health checks fail │
│ ✓ Document deployment outcomes │
│ ✓ Analyze post-deployment metrics │
│ │
│ [AI Agents CANNOT in Production] │
│ ✗ Deploy without human approval │
│ ✗ Bypass approval gates │
│ ✗ Access production secrets directly │
│ ✗ Modify production configuration without review │
│ ✗ Disable monitoring or alerting │
│ │
│ [Human MUST in Production] │
│ □ Approve all deployments │
│ □ Review AI Agent recommendations │
│ □ Execute rollback decisions │
│ □ Respond to incidents │
│ □ Conduct post-incident reviews │
│ │
└─────────────────────────────────────────────────────────────┘
2.3 Environment Comparison¶
| Aspect | Development | Staging | Production |
|---|---|---|---|
| Deployment Frequency | Multiple/day | Daily | Weekly/Bi-weekly |
| Approval Required | No | No (auto) | Yes (human) |
| Rollback Time Target | <30 min | <15 min | <5 min |
| Monitoring | Basic | Enhanced | Comprehensive |
| On-Call | No | Optional | Required |
| AI Agent Autonomy | High | Medium | Low (approval required) |
| Change Window | Anytime | Business hours | Approved windows |
| Incident Response | Next business day | Same day | Immediate |
3. Part 2: Production Deployment Strategies ¶
3.1 Deployment Strategy Selection¶
┌─────────────────────────────────────────────────────────────┐
│ DEPLOYMENT STRATEGY MATRIX │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Strategy: Blue-Green] │
│ • Risk: LOW (instant rollback) │
│ • Complexity: MEDIUM (2x infrastructure) │
│ • Downtime: ZERO │
│ • Best for: Critical services, zero-downtime required │
│ • AI Agent Role: Monitor both environments, recommend │
│ │
│ [Strategy: Canary] │
│ • Risk: LOW-MEDIUM (gradual rollout) │
│ • Complexity: MEDIUM (traffic routing) │
│ • Downtime: ZERO │
│ • Best for: User-facing services, want early feedback │
│ • AI Agent Role: Analyze canary metrics, recommend │
│ │
│ [Strategy: Rolling] │
│ • Risk: MEDIUM (partial availability during deploy) │
│ • Complexity: LOW (built into orchestrators) │
│ • Downtime: MINIMAL │
│ • Best for: Stateless services, Kubernetes │
│ • AI Agent Role: Monitor rollout progress, alert │
│ │
│ [Strategy: Recreate] │
│ • Risk: HIGH (downtime during deploy) │
│ • Complexity: LOW (simple) │
│ • Downtime: YES (full downtime) │
│ • Best for: Non-critical services, maintenance windows │
│ • AI Agent Role: Not recommended for production │
│ │
│ [Recommendation] │
│ • Production: Blue-Green or Canary │
│ • Staging: Rolling │
│ • Dev: Recreate (simplest) │
│ │
└─────────────────────────────────────────────────────────────┘
3.2 Blue-Green Deployment (Recommended for Production)¶
┌─────────────────────────────────────────────────────────────┐
│ BLUE-GREEN DEPLOYMENT FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Before Deployment] │
│ • Blue: Current production (serving traffic) │
│ • Green: Idle (ready for deployment) │
│ │
│ [Step 1: Deploy to Green] │
│ • Deploy new version to Green environment │
│ • Run smoke tests on Green │
│ • Green is NOT serving traffic yet │
│ │
│ [Step 2: Validate Green] │
│ • Run integration tests │
│ • Run performance tests │
│ • Run security scans │
│ • Human approval checkpoint │
│ │
│ [Step 3: Switch Traffic] │
│ • Update load balancer to Green │
│ • Traffic shifts instantly (zero downtime) │
│ • Blue becomes idle │
│ │
│ [Step 4: Monitor] │
│ • Monitor Green for 30 minutes │
│ • If issues: Switch back to Blue (instant rollback) │
│ • If stable: Keep Green, decommission Blue │
│ │
│ [Rollback Procedure] │
│ • Detect issue on Green │
│ • Switch load balancer back to Blue │
│ • Rollback time: <1 minute │
│ • Investigate Green, fix, redeploy │
│ │
└─────────────────────────────────────────────────────────────┘
3.3 Canary Deployment (Alternative for Production)¶
┌─────────────────────────────────────────────────────────────┐
│ CANARY DEPLOYMENT FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Step 1: Deploy Canary] │
│ • Deploy new version to 5% of instances │
│ • Route 5% of traffic to canary │
│ • 95% traffic stays on stable version │
│ │
│ [Step 2: Monitor Canary] │
│ • Monitor error rates │
│ • Monitor latency │
│ • Monitor business metrics │
│ • Compare canary vs. stable │
│ │
│ [Step 3: Gradual Rollout] │
│ • If canary healthy: increase to 25% │
│ • Monitor again │
│ • If healthy: increase to 50% │
│ • Monitor again │
│ • If healthy: increase to 100% │
│ │
│ [Step 4: Complete or Rollback] │
│ • If all healthy: deployment complete │
│ • If issues at any stage: rollback canary │
│ • Rollback time: <5 minutes │
│ │
│ [AI Agent Role (Chapter 10)] │
│ • Monitor canary metrics continuously │
│ • Detect anomalies faster than rules │
│ • Recommend: continue, pause, or rollback │
│ • Human makes final decision │
│ │
└─────────────────────────────────────────────────────────────┘
3.4 Deployment Configuration Template¶
File: config/environments/production-deployment.yml
# Production Deployment Configuration
environment: production
deployment_strategy: blue-green
approval:
required: true
approvers:
- team-lead
- on-call-engineer
timeout: 30m
escalation_on_timeout: engineering-lead
validation:
pre_deployment:
- smoke_tests: required
- integration_tests: required
- security_scan: required
- performance_baseline: required
post_deployment:
- health_checks: required
- smoke_tests: required
- monitoring_verification: required
- business_metrics: required
rollback:
automatic: true
triggers:
- health_check_failures: 3
- error_rate_increase: 10%
- latency_increase: 50%
timeout: 5m # Must complete within 5 minutes
notification:
- slack
- pagerduty
- email
monitoring:
duration: 30m # Monitor for 30 minutes post-deploy
metrics:
- error_rate
- latency_p95
- latency_p99
- throughput
- cpu_utilization
- memory_utilization
alerts:
- threshold: error_rate > 1%
action: alert_oncall
- threshold: latency_p99 > 500ms
action: alert_oncall
change_window:
allowed_days: [tuesday, wednesday, thursday]
allowed_hours: [10:00-16:00] # Business hours only
blackout_periods:
- holidays
- end_of_month
- major_events
4. Part 3: Release Management – Versioning & Rollback ¶
4.1 Semantic Versioning for Production¶
┌─────────────────────────────────────────────────────────────┐
│ SEMANTIC VERSIONING FOR PRODUCTION │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Version Format] │
│ MAJOR.MINOR.PATCH │
│ Example: v2.5.3 │
│ │
│ [Version Types] │
│ • MAJOR (2.0.0 → 3.0.0): Breaking changes │
│ - Requires: Engineering lead approval │
│ - Requires: Customer communication │
│ - Requires: Extended monitoring │
│ │
│ • MINOR (2.4.0 → 2.5.0): New features, backward compat. │
│ - Requires: Team lead approval │
│ - Requires: Standard monitoring │
│ │
│ • PATCH (2.5.2 → 2.5.3): Bug fixes, backward compat. │
│ - Requires: On-call engineer approval │
│ - Requires: Basic monitoring │
│ │
│ [AI Agent Rules by Version (Chapter 10)] │
│ • PATCH: AI can recommend, human approves │
│ • MINOR: AI can recommend, human approves │
│ • MAJOR: Human must review (AI provides analysis) │
│ │
└─────────────────────────────────────────────────────────────┘
4.2 Release Workflow¶
┌─────────────────────────────────────────────────────────────┐
│ PRODUCTION RELEASE WORKFLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Step 1: Version Bump] │
│ • Determine version type (MAJOR/MINOR/PATCH) │
│ • Update version in code │
│ • Create release branch │
│ • AI: Suggest version based on commits │
│ │
│ [Step 2: Release Notes] │
│ • Generate changelog from commits │
│ • Document breaking changes │
│ • Document migration steps │
│ • AI: Generate changelog, human reviews │
│ │
│ [Step 3: Pre-Release Validation] │
│ • All tests pass in staging │
│ • Security scan passes │
│ • Performance baseline met │
│ • Production readiness checklist complete │
│ │
│ [Step 4: Approval] │
│ • Required approvers sign off │
│ • Change window verified │
│ • On-call engineer confirmed │
│ • Rollback procedure reviewed │
│ │
│ [Step 5: Deploy] │
│ • Execute deployment strategy (blue-green/canary) │
│ • Monitor continuously │
│ • AI: Monitor and alert on anomalies │
│ │
│ [Step 6: Post-Deployment Validation] │
│ • Health checks pass for 30 minutes │
│ • Business metrics stable │
│ • No increase in support tickets │
│ • AI: Analyze metrics, recommend continue/rollback │
│ │
│ [Step 7: Tag & Document] │
│ • Create git tag │
│ • Update release documentation │
│ • Notify stakeholders │
│ • AI: Document deployment outcome │
│ │
└─────────────────────────────────────────────────────────────┘
4.3 Rollback Procedures¶
# Production Rollback Procedure
## Automatic Rollback Triggers:
- Health check failures: 3 consecutive
- Error rate increase: >10% from baseline
- Latency increase: >50% from baseline
- Security incident detected
- Business metric degradation: >5%
## Rollback Decision Tree:
## Rollback Execution:
### Blue-Green Rollback:
```bash
# Switch traffic back to Blue
./scripts/switch-traffic.sh --environment blue
# Verify Blue is healthy
./scripts/health-check.sh --environment blue
# Document rollback
./scripts/document-incident.sh --type rollback --version v2.5.4
Canary Rollback:¶
# Stop canary rollout
./scripts/canary-stop.sh
# Route all traffic back to stable
./scripts/route-traffic.sh --target stable --percentage 100
# Terminate canary instances
./scripts/terminate-canary.sh
# Document rollback
./scripts/document-incident.sh --type rollback --version v2.5.4
Post-Rollback:¶
- Notify all stakeholders
- Create incident ticket
- Schedule post-incident review
- Document lessons learned
- Update runbooks if needed
### 4.4 Changelog Template ```markdown # Changelog ## [2.5.4] - 2024-01-15 ### Added - New feature: User profile export (#123) - New endpoint: /api/v1/users/export ### Changed - Improved database query performance (#124) - Updated dependencies to latest versions ### Fixed - Bug: Login timeout on high load (#125) - Bug: Incorrect error messages in API (#126) ### Security - Patched CVE-2024-1234 in dependency X - Added rate limiting to authentication endpoints ### Deployment Notes - Database migration required: YES - Backward compatible: YES - Rollback procedure: Standard (see runbook) ### Approvals - Engineering Lead: @name (2024-01-15) - Security Lead: @name (2024-01-15) - On-Call: @name (2024-01-15)
5. Part 4: Production Readiness Checklist ¶
5.1 Production Readiness Checklist¶
# Production Readiness Checklist
## Code & Configuration:
□ All tests pass (unit, integration, e2e)
□ Security scan passes (no critical/high vulnerabilities)
□ Code review completed and approved
□ Configuration validated for production
□ Secrets managed via vault (not hardcoded)
□ Feature flags configured for production
## Infrastructure:
□ Infrastructure defined as code (Chapters 3-5)
□ Production environment matches staging
□ Capacity planning completed
□ Auto-scaling configured (if applicable)
□ Backup procedures verified
□ Disaster recovery tested
## Deployment:
□ Deployment strategy defined (blue-green/canary)
□ Rollback procedure documented and tested
□ Deployment runbook complete
□ Change window approved
□ Approvers confirmed
## Monitoring & Alerting:
□ Monitoring dashboards created
□ Alert thresholds configured
□ On-call rotation scheduled
□ Escalation procedures defined
□ PagerDuty/alerting tested
## Documentation:
□ Runbooks complete and up-to-date
□ Architecture diagrams current
□ Contact list updated
□ Incident response procedure documented
□ Customer communication template ready
## Security & Compliance:
□ Security review completed
□ Compliance requirements met (HIPAA/SOC2/PCI)
□ Access controls verified
□ Audit logging enabled
□ Data encryption verified
## AI Agent Readiness (Chapter 10):
□ AI Agent boundaries defined
□ AI Agent approval workflows configured
□ AI Agent monitoring enabled
□ AI Agent emergency stop tested
□ Human oversight procedures defined
## Sign-Off:
□ Engineering Lead: ________________ Date: ________
□ Security Lead: ________________ Date: ________
□ Operations Lead: ________________ Date: ________
□ Product Owner: ________________ Date: ________
5.2 Production Readiness Score¶
┌─────────────────────────────────────────────────────────────┐
│ PRODUCTION READINESS SCORE │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Scoring] │
│ • 90-100%: Ready for production deploy │
│ • 70-89%: Ready with minor improvements │
│ • 50-69%: Not ready, address gaps │
│ • <50%: Do not deploy, significant work needed │
│ │
│ [Critical Items (Must Pass)] │
│ □ All tests pass │
│ □ Security scan passes │
│ □ Rollback procedure tested │
│ □ On-call scheduled │
│ □ Monitoring enabled │
│ │
│ [If Any Critical Item Fails] │
│ → DO NOT DEPLOY │
│ → Fix critical items first │
│ → Re-assess readiness │
│ │
└─────────────────────────────────────────────────────────────┘
5.3 Pre-Deployment Verification Script¶
File: scripts/verify-production-readiness.sh
#!/bin/bash
# Production Readiness Verification Script
set -euo pipefail
ENVIRONMENT="production"
VERSION="${1:-}"
if [ -z "$VERSION" ]; then
echo "ERROR: Version required"
echo "Usage: $0 <version>"
exit 1
fi
echo "========================================"
echo "Production Readiness Verification"
echo "Environment: $ENVIRONMENT"
echo "Version: $VERSION"
echo "========================================"
# Critical Checks
CRITICAL_PASSED=true
echo ""
echo "[CRITICAL CHECKS]"
# Test 1: All tests pass
echo -n "Checking tests... "
if ./scripts/run-tests.sh --environment staging --all; then
echo "✓ PASS"
else
echo "✗ FAIL"
CRITICAL_PASSED=false
fi
# Test 2: Security scan passes
echo -n "Checking security scan... "
if ./scripts/security-scan.sh --environment staging --fail-on high; then
echo "✓ PASS"
else
echo "✗ FAIL"
CRITICAL_PASSED=false
fi
# Test 3: Rollback tested
echo -n "Checking rollback procedure... "
if [ -f "runbooks/rollback-$ENVIRONMENT.md" ]; then
echo "✓ PASS"
else
echo "✗ FAIL"
CRITICAL_PASSED=false
fi
# Test 4: On-call scheduled
echo -n "Checking on-call schedule... "
if ./scripts/check-oncall.sh --environment $ENVIRONMENT; then
echo "✓ PASS"
else
echo "✗ FAIL"
CRITICAL_PASSED=false
fi
# Test 5: Monitoring enabled
echo -n "Checking monitoring... "
if ./scripts/check-monitoring.sh --environment $ENVIRONMENT; then
echo "✓ PASS"
else
echo "✗ FAIL"
CRITICAL_PASSED=false
fi
echo ""
echo "========================================"
if [ "$CRITICAL_PASSED" = true ]; then
echo "RESULT: READY FOR PRODUCTION"
echo "========================================"
exit 0
else
echo "RESULT: NOT READY FOR PRODUCTION"
echo "========================================"
echo "Critical checks failed. Do not deploy."
exit 1
fi
6. Part 5: Production Incident Response ¶
6.1 Incident Severity Levels¶
┌─────────────────────────────────────────────────────────────┐
│ INCIDENT SEVERITY LEVELS │
├─────────────────────────────────────────────────────────────┤
│ │
│ [SEV-1: Critical] │
│ • Impact: Production down, customers affected │
│ • Response Time: <15 minutes │
│ • Escalation: Immediate to engineering lead + CTO │
│ • Examples: Complete outage, data loss, security breach │
│ │
│ [SEV-2: High] │
│ • Impact: Major functionality impaired │
│ • Response Time: <30 minutes │
│ • Escalation: To engineering lead │
│ • Examples: Partial outage, performance degradation │
│ │
│ [SEV-3: Medium] │
│ • Impact: Minor functionality impaired │
│ • Response Time: <2 hours │
│ • Escalation: To team lead │
│ • Examples: Non-critical bug, UI issues │
│ │
│ [SEV-4: Low] │
│ • Impact: Minimal, workaround available │
│ • Response Time: <24 hours │
│ • Escalation: No escalation needed │
│ • Examples: Cosmetic issues, documentation gaps │
│ │
└─────────────────────────────────────────────────────────────┘
6.2 Incident Response Workflow¶
┌─────────────────────────────────────────────────────────────┐
│ INCIDENT RESPONSE WORKFLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Step 1: Detect] │
│ • Monitoring alerts │
│ • Customer reports │
│ • AI Agent detection (Chapter 10) │
│ │
│ [Step 2: Triage] │
│ • Determine severity (SEV-1/2/3/4) │
│ • Assign incident commander │
│ • Create incident channel │
│ │
│ [Step 3: Respond] │
│ • Investigate root cause │
│ • Implement fix or rollback │
│ • Communicate to stakeholders │
│ │
│ [Step 4: Resolve] │
│ • Verify fix works │
│ • Monitor for recurrence │
│ • Close incident │
│ │
│ [Step 5: Review] │
│ • Post-incident review within 48 hours │
│ • Document lessons learned │
│ • Update runbooks │
│ • Implement preventive measures │
│ │
└─────────────────────────────────────────────────────────────┘
6.3 Incident Response Template¶
# Incident Report Template
## Incident Details:
- Incident ID: INC-YYYY-NNNN
- Severity: SEV-1/2/3/4
- Start Time: YYYY-MM-DD HH:MM UTC
- End Time: YYYY-MM-DD HH:MM UTC
- Duration: X hours Y minutes
- Services Affected: [list]
- Customers Affected: [estimate]
## Timeline:
| Time (UTC) | Event |
|------------|-------|
| HH:MM | Incident detected |
| HH:MM | Incident commander assigned |
| HH:MM | Root cause identified |
| HH:MM | Fix implemented |
| HH:MM | Incident resolved |
## Root Cause:
[Detailed description of what caused the incident]
## Impact:
[Description of customer and business impact]
## Resolution:
[Description of how the incident was resolved]
## Lessons Learned:
### What Went Well:
- [Item 1]
- [Item 2]
### What Went Poorly:
- [Item 1]
- [Item 2]
## Action Items:
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [Action 1] | @name | YYYY-MM-DD | Open |
| [Action 2] | @name | YYYY-MM-DD | Open |
## Sign-Off:
□ Incident Commander: ________________ Date: ________
□ Engineering Lead: ________________ Date: ________
□ Post-Incident Review Date: ________
6.4 Communication Templates¶
# Incident Communication Templates
## Initial Notification (Internal):
Service: [service name] Impact: [description] Started: [time] Investigating: [team] Next Update: [time]
Join incident channel: #[channel-name]
## Customer Notification (External):
Impact: [description] Started: [time] Status: Investigating Next Update: [time]
We apologize for the inconvenience and are working to resolve this as quickly as possible.
Status Page: [link]
## Resolution Notification:
The issue has been resolved as of [time]. Duration: [X hours Y minutes] Root Cause: [brief description] Prevention: [what we're doing to prevent recurrence]
Thank you for your patience.
7. Part 6: VSCode Integration for Production Workflows ¶
7.1 Continue.dev Configuration for Production¶
File: ~/.continue/config.json
{
"models": [
{
"title": "🔵 Qwen-2.5-Coder (Production Code)",
"provider": "openai",
"model": "qwen-2.5-coder",
"apiKey": "${QWEN_API_KEY}",
"apiBase": "https://dashscope.aliyuncs.com/compatible-mode/v1",
"default": true
},
{
"title": "🟢 DeepSeek-V3 (Production Logic)",
"provider": "openai",
"model": "deepseek-chat",
"apiKey": "${DEEPSEEK_API_KEY}",
"apiBase": "https://api.deepseek.com/v1"
},
{
"title": "🟠 Claude-3.5-Sonnet (Production Safety)",
"provider": "anthropic",
"model": "claude-3-5-sonnet-20241022",
"apiKey": "${ANTHROPIC_API_KEY}"
}
],
"customCommands": [
{
"name": "prod-deploy",
"prompt": "Generate production deployment configuration for {{{ input }}}. CRITICAL: 1) Follow production deployment strategy from Chapter 6, 2) Include approval gates, 3) Include rollback procedures, 4) Include monitoring requirements. Follow production readiness from Chapter 6.",
"description": "Generate production deployment configuration"
},
{
"name": "prod-readiness",
"prompt": "Generate production readiness checklist for {{{ input }}}. Include: 1) Code & configuration checks, 2) Infrastructure checks, 3) Deployment checks, 4) Monitoring checks, 5) Documentation checks, 6) Security & compliance checks. Follow Chapter 6 checklist.",
"description": "Generate production readiness checklist"
},
{
"name": "prod-rollback",
"prompt": "Generate production rollback procedure for {{{ input }}}. Include: 1) Rollback triggers, 2) Rollback steps, 3) Verification steps, 4) Communication templates. Follow Chapter 6 rollback procedures.",
"description": "Generate production rollback procedure"
},
{
"name": "prod-incident",
"prompt": "Generate incident response procedure for {{{ input }}}. Include: 1) Severity classification, 2) Response workflow, 3) Communication templates, 4) Post-incident review. Follow Chapter 6 incident response.",
"description": "Generate incident response procedure"
},
{
"name": "prod-release",
"prompt": "Generate release notes for {{{ input }}}. Include: 1) Version type (MAJOR/MINOR/PATCH), 2) Changelog, 3) Deployment notes, 4) Approval section. Follow Chapter 6 release management.",
"description": "Generate release notes"
}
]
}
7.2 VSCode Snippets for Production¶
File: ~/.vscode/snippets/production.json
{
"Production Deployment Config": {
"prefix": "prod-deploy",
"body": [
"environment: production",
"",
"deployment_strategy: ${1:blue-green}",
"",
"approval:",
" required: true",
" approvers:",
" - ${2:team-lead}",
" - ${3:on-call-engineer}",
"",
"rollback:",
" automatic: true",
" triggers:",
" - health_check_failures: 3",
" - error_rate_increase: 10%",
" timeout: 5m"
],
"description": "Production deployment configuration template"
},
"Incident Report": {
"prefix": "incident-report",
"body": [
"# Incident Report",
"",
"## Incident Details:",
"- Incident ID: INC-${1:YYYY-NNNN}",
"- Severity: SEV-${2:1/2/3/4}",
"- Start Time: ${3:YYYY-MM-DD HH:MM UTC}",
"- End Time: ${4:YYYY-MM-DD HH:MM UTC}",
"- Services Affected: ${5:[list]}",
"",
"## Timeline:",
"| Time (UTC) | Event |",
"|------------|-------|",
"| ${6:HH:MM} | ${7:Incident detected} |",
"",
"## Root Cause:",
"${8:[Description]}",
"",
"## Action Items:",
"| Action | Owner | Due Date | Status |",
"|--------|-------|----------|--------|",
"| ${9:[Action]} | @${10:name} | ${11:YYYY-MM-DD} | Open |"
],
"description": "Incident report template"
},
"Release Notes": {
"prefix": "release-notes",
"body": [
"## [${1:2.5.4}] - ${2:2024-01-15}",
"",
"### Added",
"- ${3:New feature}",
"",
"### Changed",
"- ${4:Improvement}",
"",
"### Fixed",
"- ${5:Bug fix}",
"",
"### Deployment Notes",
"- Database migration required: ${6:YES/NO}",
"- Backward compatible: ${7:YES/NO}",
"",
"### Approvals",
"- Engineering Lead: @${8:name} (${9:2024-01-15})"
],
"description": "Release notes template"
}
}
8. Part 7: Iteration Points – Your Feedback Needed ¶
8.1 This Chapter's Core Message¶
"Production deployment requires more than structured pipelines. It requires release management, rollback procedures, incident response, and production readiness validation. This chapter provides the production deployment framework that Chapter 10 AI Agents will operate within."
8.2 Questions for Your Feedback¶
□ Question 1: Does the production vs. non-production distinction come through clearly?
- Is this the right framing for your experience?
- What would make it clearer?
□ Question 2: Are the deployment strategies practical?
- Do you use blue-green, canary, or rolling?
- What would you add or change?
□ Question 3: Is the production readiness checklist comprehensive?
- What items are missing?
- What items are unnecessary?
□ Question 4: Is the incident response section useful?
- Does it match your incident response process?
- What would you add?
□ Question 5: Is the VSCode integration practical?
- Do the custom commands make sense?
- What workflows would save you time?
□ Question 6: Should any content move to Chapter 7 (Governance)?
- Is there overlap with governance?
- What should be separated?
□ Question 7: What's missing?
- What topics should be added?
- What should be removed or condensed?
9. Appendix: Production Templates & Checklists ¶
9.1 Production Deployment Checklist¶
# Production Deployment Checklist
## Pre-Deployment:
□ Version determined (MAJOR/MINOR/PATCH)
□ Changelog generated and reviewed
□ All tests pass (unit, integration, e2e)
□ Security scan passes
□ Performance baseline met
□ Production readiness checklist complete
□ Approvers confirmed
□ Change window verified
□ On-call engineer scheduled
□ Rollback procedure reviewed
## Deployment:
□ Deployment strategy executed (blue-green/canary)
□ Monitoring dashboards open
□ Incident channel created
□ Stakeholders notified
□ AI Agent monitoring enabled (Chapter 10)
## Post-Deployment:
□ Health checks pass for 30 minutes
□ Business metrics stable
□ No increase in support tickets
□ Monitoring alerts verified
□ Documentation updated
□ Release tagged in git
□ Stakeholders notified of completion
## Sign-Off:
□ Deployment Lead: ________________ Date: ________
□ On-Call Engineer: ________________ Date: ________
□ Product Owner: ________________ Date: ________
9.2 The Chapter 6 Checklist¶
# Chapter 6: Production Deployment - Checklist
## Before Production Deployment:
□ Understand production vs. non-production differences (Section 2)
□ Deployment strategy selected (Section 3)
□ Release management process defined (Section 4)
□ Production readiness checklist complete (Section 5)
□ Incident response procedure defined (Section 6)
## During Production Deployment:
□ Use production deployment templates (Appendix 9.1)
□ Follow approval workflows
□ Monitor continuously
□ Be ready to rollback
□ Document all decisions
## After Production Deployment:
□ Verify deployment success
□ Monitor for 30 minutes minimum
□ Update documentation
□ Conduct post-deployment review
□ Capture lessons learned
## Key Principle:
"Production requires more than structure. It requires readiness, rollback, and response."
Chapter Summary¶
The Core Message¶
┌─────────────────────────────────────────────────────────────┐
│ CHAPTER 6 IN ONE SENTENCE │
├─────────────────────────────────────────────────────────────┤
│ │
│ "Production deployment requires more than structured │
│ pipelines. It requires release management, rollback │
│ procedures, incident response, and production readiness │
│ validation. This chapter provides the production │
│ deployment framework that Chapter 10 AI Agents will │
│ operate within." │
│ │
└─────────────────────────────────────────────────────────────┘
Key Takeaways¶
✅ Production is different from non-production (stability over speed)
✅ Deployment strategies: Blue-green (recommended), Canary, Rolling
✅ Release management: SemVer, changelog, rollback
✅ Production readiness checklist: Must pass before deploy
✅ Incident response: Severity levels, workflow, communication
✅ VSCode integration: Production deployment templates
✅ Chapter 10: AI Agents operate within these production safeguards
Connection to Other Chapters¶
| Chapter | Connection |
|---|---|
| Chapter 3 | InfraCtl structure → Production IaC |
| Chapter 4 | Ansible structure → Production deployment |
| Chapter 5 | CI/CD structure → Production pipelines |
| Chapter 6 | Production deployment framework |
| Chapter 7 | Governance → Production governance |
| Chapter 8 | Monitoring → Production monitoring |
| Chapter 9 | Continuous Improvement → Production learning |
| Chapter 10 | AI Agents → Operate within Chapter 6 safeguards |
Book Progress¶
✅ Chapter 1: AI Foundations (Symbolic + Data-Driven)
✅ Chapter 2: VSCode AI Integration
✅ Chapter 3: Structured IaC (InfraCtl)
✅ Chapter 4: Structured Deployment (Ansible)
✅ Chapter 5: Structured CI/CD (Pipelines + Runners)
✅ Chapter 6: Production Deployment & Release Management
Next:
□ Chapter 7: Governance, Safety & Compliance
□ Chapter 8: Monitoring, Observability & Alerting
□ Chapter 9: Continuous Improvement & Learning
□ Chapter 10: AI Agents (Culmination)
□ Index: Quick Reference & Publishing
Document Version: 0.1 (Draft for Iteration) Part of: The DevOps Engineer's Guide to Effective AI Usage Last Updated: [Current Date] Prepared By: [Your Name]
This is a DRAFT for iteration. Please provide feedback on Section 8.2 questions. After your review, I'll proceed to Chapter 7 (Governance, Safety & Compliance). The core message is: Production requires readiness, rollback, and response – AI Agents (Chapter 10) will operate within these safeguards.