job-forge/.claude/templates/deployment_template.md

# Deployment Guide: [Release Version]

## Release Information
- **Version**: [Version Number]
- **Release Date**: [Date]
- **Release Type**: [Feature/Hotfix/Security/Maintenance]
- **Release Manager**: [Name]

## Release Summary
Brief description of what's being deployed, major features, and business impact.

### ✨ New Features
- [Feature 1]: Description and business value
- [Feature 2]: Description and business value

### 🐛 Bug Fixes
- [Bug Fix 1]: Description of issue resolved
- [Bug Fix 2]: Description of issue resolved

### 🔧 Technical Improvements
- [Improvement 1]: Performance/security/maintenance improvement
- [Improvement 2]: Infrastructure or code quality improvement

## Pre-Deployment Checklist

### ✅ Quality Assurance
- [ ] All automated tests passing (unit, integration, E2E)
- [ ] Manual testing completed and signed off
- [ ] Performance testing completed
- [ ] Security scan passed with no critical issues
- [ ] Cross-browser testing completed
- [ ] Mobile responsiveness verified
- [ ] Accessibility requirements met

### 🔐 Security & Compliance
- [ ] Security review completed
- [ ] Dependency vulnerabilities resolved
- [ ] Environment variables secured
- [ ] Database migration reviewed for data safety
- [ ] Backup procedures verified
- [ ] Compliance requirements met

### 📋 Documentation & Communication
- [ ] Release notes prepared
- [ ] API documentation updated
- [ ] User documentation updated
- [ ] Stakeholders notified of deployment
- [ ] Support team briefed on changes
- [ ] Rollback plan documented

### 🏗️ Infrastructure & Environment
- [ ] Staging environment matches production
- [ ] Database migrations tested on staging
- [ ] Environment variables configured
- [ ] SSL certificates valid and updated
- [ ] Monitoring and alerting configured
- [ ] Backup systems operational

## Environment Configuration

### Environment Variables
```bash
# Required Environment Variables
NODE_ENV=production
DATABASE_URL=postgresql://user:pass@host:port/dbname
REDIS_URL=redis://host:port
JWT_SECRET=your-secure-jwt-secret
API_BASE_URL=https://api.yourdomain.com

# Third-party Services
STRIPE_SECRET_KEY=sk_live_...
SENDGRID_API_KEY=SG...
SENTRY_DSN=https://...

# Optional Configuration
LOG_LEVEL=info
RATE_LIMIT_MAX=1000
SESSION_TIMEOUT=3600
```

### Database Configuration
```sql
-- Database migration checklist
-- [ ] Backup current database
-- [ ] Test migration on staging
-- [ ] Verify data integrity
-- [ ] Update indexes if needed
-- [ ] Check foreign key constraints

-- Example migration
-- Migration: 2024-01-01-add-user-preferences.sql
ALTER TABLE users ADD COLUMN preferences JSONB DEFAULT '{}';
CREATE INDEX idx_users_preferences ON users USING GIN (preferences);
```

## Deployment Procedure

### Step 1: Pre-Deployment Verification
```bash
# Verify current system status
curl -f https://api.yourdomain.com/health
curl -f https://yourdomain.com/health

# Check system resources
docker stats
df -h

# Verify monitoring systems
# Check Sentry, DataDog, or monitoring dashboard
```

### Step 2: Database Migration (if applicable)
```bash
# 1. Create database backup
pg_dump $DATABASE_URL > backup_$(date +%Y%m%d_%H%M%S).sql

# 2. Run migration in staging (verify first)
npm run migrate:staging

# 3. Verify migration succeeded
npm run migrate:status

# 4. Run migration in production (when ready)
npm run migrate:production
```

### Step 3: Application Deployment

#### Option A: Automated Deployment (CI/CD)
```yaml
# GitHub Actions / GitLab CI deployment
deployment_trigger:
  - push_to_main_branch
  - manual_trigger_from_dashboard
  
deployment_steps:
  1. run_automated_tests
  2. build_application
  3. deploy_to_staging
  4. run_smoke_tests
  5. wait_for_approval
  6. deploy_to_production
  7. run_post_deployment_tests
```

#### Option B: Manual Deployment
```bash
# 1. Pull latest code
git checkout main
git pull origin main

# 2. Install dependencies
npm ci --production

# 3. Build application
npm run build

# 4. Deploy using platform-specific commands
# Vercel
vercel --prod

# Heroku
git push heroku main

# Docker
docker build -t app:latest .
docker push registry/app:latest
kubectl set image deployment/app app=registry/app:latest
```

### Step 4: Post-Deployment Verification
```bash
# 1. Health checks
curl -f https://api.yourdomain.com/health
curl -f https://yourdomain.com/health

# 2. Smoke tests
npm run test:smoke:production

# 3. Verify key functionality
curl -X POST https://api.yourdomain.com/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"test123"}'

# 4. Check error rates and performance
# Monitor for first 30 minutes after deployment
```

## Monitoring & Alerting

### Key Metrics to Monitor
```yaml
application_metrics:
  - response_time_p95: < 500ms
  - error_rate: < 1%
  - throughput: requests_per_second
  - database_connections: < 80% of pool

infrastructure_metrics:
  - cpu_usage: < 70%
  - memory_usage: < 80%
  - disk_usage: < 85%
  - network_latency: < 100ms

business_metrics:
  - user_registrations: normal_levels
  - conversion_rates: no_significant_drop
  - payment_processing: functioning_normally
```

### Alert Configuration
```yaml
critical_alerts:
  - error_rate > 5%
  - response_time > 2000ms
  - database_connections > 90%
  - application_crashes

warning_alerts:
  - error_rate > 2%
  - response_time > 1000ms
  - cpu_usage > 80%
  - memory_usage > 85%

notification_channels:
  - slack: #alerts-critical
  - email: devops@company.com
  - pagerduty: production-alerts
```

## Rollback Plan

### When to Rollback
- Critical application errors affecting > 10% of users
- Data corruption or data loss incidents
- Security vulnerabilities exposed
- Performance degradation > 50% from baseline
- Core functionality completely broken

### Rollback Procedure
```bash
# Option 1: Platform rollback (recommended)
# Vercel
vercel rollback [deployment-url]

# Heroku
heroku rollback v[previous-version]

# Kubernetes
kubectl rollout undo deployment/app

# Option 2: Git revert (if platform rollback unavailable)
git revert HEAD
git push origin main

# Option 3: Database rollback (if needed)
# Restore from backup taken before deployment
pg_restore -d $DATABASE_URL backup_[timestamp].sql
```

### Post-Rollback Actions
1. **Immediate**: Verify system stability
2. **Within 1 hour**: Investigate root cause
3. **Within 4 hours**: Fix identified issues
4. **Within 24 hours**: Plan and execute re-deployment

## Communication Plan

### Pre-Deployment Communication
```markdown
**Subject**: Scheduled Deployment - [Application Name] v[Version]

**Team**: [Development Team]
**Date**: [Deployment Date]
**Time**: [Deployment Time with timezone]
**Duration**: [Expected duration]

**Changes**:
- [Brief list of major changes]

**Impact**:
- [Any expected user impact or downtime]

**Support**: [Contact information for deployment team]
```

### Post-Deployment Communication
```markdown
**Subject**: Deployment Complete - [Application Name] v[Version]

**Status**: ✅ Successful / ❌ Failed / ⚠️ Partial

**Completed At**: [Time]
**Duration**: [Actual duration]

**Verification**:
- ✅ Health checks passing
- ✅