Deployment Process¶

Progress: Module 4 of 4 - Lesson 3 of 3

Master team deployment practices, continuous integration/deployment, and rollback procedures to safely ship code to production.

Prerequisites¶

Before diving into deployment processes, ensure you have:

Completed GitHub Workflow and Code Reviews lessons
Understanding of your team's infrastructure
Access to deployment tools/systems
Knowledge of your application's architecture
Understanding of testing and quality assurance

Core Concepts¶

Deployment Pipeline¶

The typical deployment pipeline ensures code quality and stability:

Code Commit
    ↓
GitHub → Automated Tests (Unit, Integration)
    ↓
Code Review & Approval
    ↓
Merge to Main
    ↓
Build Artifacts
    ↓
Deploy to Staging
    ↓
Smoke Tests
    ↓
Deploy to Production
    ↓
Monitor & Alert

Deployment Strategies¶

1. Blue-Green Deployment¶

Production (Blue - Current)      Production (Green - New)
├── Load Balancer                ├── Load Balancer
├── Server 1                      ├── Server 1
├── Server 2                      ├── Server 2
└── Server 3                      └── Server 3

Test Green completely, then switch traffic
Instant rollback by switching back to Blue

Advantages: - Instant rollback - Zero downtime - Full testing before switch

Disadvantages: - Requires 2x infrastructure - Database migrations complex

2. Canary Deployment¶

Traffic Split:
- 90% → Current Version
- 10% → New Version

Monitor metrics on new version
Gradually increase: 50/50 → 100% new
Automatic rollback if issues detected

Advantages: - Lower risk - Real traffic testing - Gradual rollout

Disadvantages: - More complex - Monitoring critical

3. Rolling Deployment¶

Phase 1: Deploy to 1 server, verify
Phase 2: Deploy to 2 more servers
Phase 3: Deploy to remaining servers

Stop if issues occur

Advantages: - Simple to implement - Zero downtime

Disadvantages: - Longer deployment time - Multiple versions running

Team Collaboration Best Practices¶

Pre-Deployment Checklist¶

Before any deployment:

Deployment Communication¶

Before Deployment:

@team: Deploying user authentication refactor to production at 2pm.
Expected impact: None (internal refactor)
Rollback time: < 2 minutes if needed
Monitoring: Dashboard at [link]

After Deployment:

Deployment complete. Monitoring metrics:
- Error rate: 0.02% (normal)
- Response time: 95ms (normal)
- Active users: [expected range]

All systems nominal.

Deployment Windows¶

Choose Appropriate Times: - Avoid Friday afternoons - Avoid peak traffic times - Have team available for monitoring - Plan for time zone differences - Schedule maintenance windows

Rollback Procedures¶

Quick Rollback Process:

# 1. Identify issue
# Alert triggered or manual observation

# 2. Decide to rollback
# Team consensus (even if quick)

# 3. Execute rollback
git revert <problematic-commit>
git push origin main

# Or re-deploy previous version:
git checkout <previous-tag>
git push origin main --force

# 4. Monitor
# Watch metrics for 10+ minutes
# Check user reports

# 5. Post-mortem
# What went wrong?
# How to prevent?

Database Migration Safety¶

For Schema Changes:

-- Add new column with default (safe)
ALTER TABLE users ADD COLUMN created_at TIMESTAMP DEFAULT NOW();

-- Good: Deploy code that handles both old and new schema
-- Migrate data
UPDATE users SET created_at = updated_at WHERE created_at IS NULL;

-- Then remove old column in next deployment
ALTER TABLE users DROP COLUMN updated_at;

Pattern: Expand then Contract

1. Add new schema element
2. Deploy code using new element
3. Migrate data
4. Remove old schema element
5. Deploy code removing old reference

Continuous Integration/Continuous Deployment (CI/CD)¶

GitHub Actions Example¶

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      - name: Check coverage
        run: npm run coverage

      - name: Lint code
        run: npm run lint

  deploy-staging:
    needs: test
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy to staging
        run: |
          npm run build
          ./deploy-staging.sh

  smoke-tests:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: Run smoke tests
        run: npm run smoke-tests https://staging.app.com

  deploy-production:
    needs: smoke-tests
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v2
      - name: Deploy to production
        run: |
          npm run build
          ./deploy-production.sh
      - name: Notify team
        run: ./notify-slack.sh "Deployed to production"

Deployment Types¶

Feature Deployment¶

What: New user-facing feature Testing: Full test suite + manual QA Rollback: Simple (revert commit) Announcement: Yes, notify users

Bug Fix Deployment¶

What: Bug in production Testing: Regression test + reproduction test Rollback: Quick (prepare before deploying) Announcement: Only if affects user experience

Infrastructure Change¶

What: Server, database, network changes Testing: Staging environment fully tested Rollback: Complex, may need manual steps Announcement: Coordinate with ops team

Security Patch¶

What: Security vulnerability fix Testing: Security focused tests Rollback: Emergency rollback plan Announcement: Follow security guidelines

Monitoring and Alerts¶

Key Metrics to Monitor¶

Application Metrics:
├── Error Rate (should be < 1%)
├── Response Time (p95, p99)
├── Throughput (requests/second)
├── Failed Deployments
└── Rollback Rate

Infrastructure Metrics:
├── CPU Usage
├── Memory Usage
├── Disk Space
├── Network Latency
└── Database Connection Pool

Business Metrics:
├── Active Users
├── Conversion Rate
├── Revenue
└── User Reported Errors

Alert Configuration¶

Alerts:
  - Error rate > 1%: Page on-call immediately
  - Response time p99 > 1s: Page on-call
  - Database connections maxed: Page on-call
  - Disk space < 10%: Alert engineering
  - Memory leak detected: Alert engineering

Deployment Checklist¶

Pre-Deployment (24 hours before)¶

Deployment Day (During)¶

Post-Deployment (After)¶

Common Deployment Issues¶

Issue: Deployment Takes Too Long¶

Solution: - Parallelize independent tasks - Optimize build process - Use artifact caching - Split large deployments

Issue: Database Migrations Fail¶

Solution: - Always test migrations on staging first - Have rollback SQL ready - Use schema versioning - Keep migrations small - Set timeouts for long migrations

Issue: Features Don't Work in Production¶

Solution: - Use feature flags to test in production - Smoke tests before full rollout - Canary deployments for new features - Monitor error logs closely - Easy rollback available

Issue: Team Doesn't Know Deployment Status¶

Solution: - Automate status notifications - Use deployment tracking dashboard - Slack/email updates - Public status page - Post-deployment updates

AI Prompts for Deployment¶

Planning Safe Deployments¶

Create Deployment Checklist

I'm deploying [feature/fix description] to production.

Changes include:
- [list main changes]

Database changes: [yes/no, describe]
Environment variables: [any new/changed variables]
Dependencies: [any new packages]

Generate a deployment checklist covering:
1. Pre-deployment tasks
2. Backup procedures
3. Deployment steps
4. Verification tests
5. Rollback plan

Plan Database Migration Strategy

I need to deploy a schema change to production.

Current schema:
[describe current structure]

Required changes:
[describe what needs to change]

Help me create a safe migration plan that:
1. Allows zero-downtime deployment
2. Supports rollback if needed
3. Migrates existing data safely
4. Follows expand-then-contract pattern

Provide the step-by-step migration SQL and deployment order.

Coordinate Team Deployment

I'm planning a significant deployment for [date/time].

What's being deployed:
- [feature/changes]

Expected impact:
- [user-facing changes]
- [system changes]

Team timezone differences: [describe]

Help me draft:
1. Pre-deployment announcement
2. Deployment timeline
3. Team responsibilities
4. Communication plan
5. Post-deployment checklist

Troubleshooting Failed Deployments¶

Deployment Failed - Help!

My deployment to EgyGeeks server failed.

GitHub Actions output:
[paste failed step output]

Docker logs on server:
[paste `docker compose logs`]

What was deployed: [describe changes]

Help me:
1. Identify root cause
2. Fix the issue
3. Safely retry deployment
4. Add checks to prevent this in future

Production Errors After Deploy

Deployed successfully but seeing errors in production.

Error messages:
[paste error logs]

Metrics showing:
- Error rate: [percentage]
- Response time: [ms]
- Affected endpoints: [list]

What changed in this deployment:
[describe changes]

Help me:
1. Assess severity (rollback or fix forward?)
2. Identify the problematic change
3. Create immediate mitigation plan
4. Draft user communication if needed

Database Migration Failed

Database migration failed during deployment.

Migration script:
[paste migration SQL]

Error message:
[paste error]

Database state: [partially applied / not applied / unknown]

Help me:
1. Safely rollback the migration
2. Understand what went wrong
3. Fix the migration script
4. Verify database integrity
5. Plan retry strategy

Rollback Procedures¶

Need to Rollback Deployment

Need to rollback recent deployment due to [reason].

Deployed commit: [commit hash]
Previous stable commit: [commit hash]

Changes in deployment:
- Code changes: [describe]
- Database migrations: [yes/no, describe]
- Config changes: [describe]

Help me create rollback plan:
1. What to rollback first
2. How to handle database changes
3. Verification steps after rollback
4. Communication to team/users

Test Rollback Procedure

I want to test our rollback procedure before deployment.

Deployment details:
- What: [feature/fix]
- When: [planned date]
- Changes: [describe]

Help me create:
1. Rollback testing checklist
2. Rollback commands/scripts
3. Expected rollback time
4. Verification tests after rollback
5. Team communication template

Monitoring and Verification¶

Create Post-Deployment Monitoring Plan

Just deployed [feature/fix] to production.

What was changed:
[describe changes]

Current metrics baseline:
- Error rate: [percentage]
- Response time: [ms]
- Active users: [number]

Help me monitor effectively:
1. Which metrics to watch closely
2. Alert thresholds to set
3. How long to actively monitor
4. What normal variation looks like
5. Signs that indicate rollback needed

Verify Deployment Success

Deployment completed, need to verify it worked.

What was deployed:
[describe changes]

Available verification methods:
- API endpoints: [list]
- UI pages: [list]
- Background jobs: [list]

Help me create smoke tests covering:
1. Critical user flows
2. New features/fixes
3. Integration points
4. Database operations
5. External service connections

Learning from Deployments¶

Write Deployment Post-Mortem

We had a deployment issue that required rollback.

What happened:
[describe the incident]

Impact:
- Duration: [time]
- Users affected: [number/percentage]
- Services impacted: [list]

Root cause:
[describe what went wrong]

Help me write a post-mortem that:
1. Timeline of events (blameless)
2. What went well
3. What went wrong
4. Action items to prevent recurrence
5. Lessons learned for team

FAQ¶

Q: How often should we deploy? A: As often as needed. Modern teams deploy multiple times per day.

Q: Should every commit deploy automatically? A: Yes! Continuous deployment encourages small, safe changes.

Q: What if deployment fails? A: Rollback immediately. Don't try to fix in production without reverting first.

Q: Do we need blue-green deployment? A: Not always. Start with rolling deployment, upgrade as needed.

Q: How long should deployments take? A: < 5 minutes ideally. Slower deployments are riskier.

Q: What if we need to deploy on Friday? A: If tests pass and team is available, it's fine. Have rollback ready.

Q: How do we handle emergency patches? A: Fast-track through reviews, deploy, monitor closely.

Module Completion¶

Congratulations! You've completed the entire Team Workflow module and learned:

GitHub Workflow - Professional branching and PR strategies
Code Reviews - How to review effectively and give feedback
Deployment Process - Safe, reliable production deployment

What's Next¶

Now you're ready to:

Contribute to team projects professionally
Lead code reviews that improve quality
Deploy with confidence using proven practices
Mentor junior developers with your knowledge
Architect solutions with team input

Advanced Topics to Explore¶

CI/CD Optimization - Make your pipeline faster
GitOps - Infrastructure as code deployment
Feature Flags - Safer deployments and A/B testing
Monitoring & Observability - Deep insights into production
Incident Management - Handling production issues
Release Management - Versioning and release notes

Further Learning¶

Study your team's actual deployment processes
Observe a production deployment
Participate in code reviews
Help with an incident response
Document your team's best practices

Help & Resources¶

Deployment Issues? - Check team runbooks - Review deployment logs - Ask the platform/DevOps team - Study similar deployments

Want to Learn More? - Explore Kubernetes deployments - Learn infrastructure as code (Terraform) - Study chaos engineering - Explore observability tools

Building Better Processes? - Measure deployment metrics - Get team feedback - Iterate on improvements - Document changes

You've completed the entire Team Workflow Module!

Go back to Module Overview or start exploring advanced topics.