Deployment Procedures

Deployment principles and decision-making for safe production releases. Learn to THINK, not memorize scripts.

⚠️ How to Use This Skill

• Every deployment is unique
• Understand the WHY behind each step
• Adapt procedures to your platform

1. Platform Selection

Decision Tree

What are you deploying?
│
├── Static site / JAMstack
│   └── Vercel, Netlify, Cloudflare Pages
│
├── Simple web app
│   ├── Managed → Railway, Render, Fly.io
│   └── Control → VPS + PM2/Docker
│
├── Microservices
│   └── Container orchestration
│
└── Serverless
    └── Edge functions, Lambda

Each Platform Has Different Procedures

2. Pre-Deployment Principles

The 4 Verification Categories

Pre-Deployment Checklist

• All tests passing
• Code reviewed and approved
• Production build successful
• Environment variables verified
• Database migrations ready (if any)
• Rollback plan documented
• Team notified
• Monitoring ready

3. Deployment Workflow Principles

The 5-Phase Process

1. PREPARE
   └── Verify code, build, env vars

2. BACKUP
   └── Save current state before changing

3. DEPLOY
   └── Execute with monitoring open

4. VERIFY
   └── Health check, logs, key flows

5. CONFIRM or ROLLBACK
   └── All good? Confirm. Issues? Rollback.

Phase Principles

4. Post-Deployment Verification

What to Verify

Verification Window

• First 5 minutes: Active monitoring
• 15 minutes: Confirm stable
• 1 hour: Final verification
• Next day: Review metrics

5. Rollback Principles

When to Rollback

Rollback Strategy by Platform

Rollback Principles

1. Speed over perfection: Rollback first, debug later
2. Don't compound errors: One rollback, not multiple changes
3. Communicate: Tell team what happened
4. Post-mortem: Understand why after stable

6. Zero-Downtime Deployment

Strategies

Selection Principles

7. Emergency Procedures

Service Down Priority

1. Assess: What's the symptom?
2. Quick fix: Restart if unclear
3. Rollback: If restart doesn't help
4. Investigate: After stable

Investigation Order

8. Anti-Patterns

9. Decision Checklist

• Platform-appropriate procedure?
• Backup strategy ready?
• Rollback plan documented?
• Monitoring configured?
• Team notified?
• Time to monitor after?

10. Best Practices

1. Small, frequent deploys over big releases
2. Feature flags for risky changes
3. Automate repetitive steps
4. Document every deployment
5. Review what went wrong after issues
6. Test rollback before you need it

11. Frappe / Bench Deployment

Platform Selection for Frappe

bench start

Production Setup (Single Server)

# 1. Setup production config (creates Supervisor + Nginx configs)
sudo bench setup production <linux_user>

# 2. Generate and enable Nginx config
bench setup nginx
sudo ln -s /etc/nginx/conf.d/frappe-bench.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo service nginx reload

# 3. Enable scheduler
bench enable-scheduler

# 4. Restart everything
sudo supervisorctl restart all

Deployment Workflow (Code Update)

# 1. Backup before deploy
bench --site mysite.localhost backup --with-files

# 2. Pull latest code
bench update --pull --reset

# 3. Or for specific app only
cd apps/my_ehealth && git pull origin main && cd ../..

# 4. Run migrations
bench --site mysite.localhost migrate

# 5. Build assets
bench build --app my_ehealth

# 6. Clear cache
bench --site mysite.localhost clear-cache

# 7. Restart
sudo supervisorctl restart all

Docker Deployment (frappe_docker)

# Clone official Docker setup
git clone https://github.com/frappe/frappe_docker.git
cd frappe_docker

# Production with custom app
export CUSTOM_APP_REPO=https://github.com/org/my_ehealth.git
docker compose -f compose.yaml up -d

Pre-Deployment Checklist (Frappe)

• bench --site mysite.localhost run-tests --app my_ehealth

  passes

• bench build

  succeeds without errors
• Database backup taken (

  bench backup --with-files

  )
• DocType JSON changes committed (no uncommitted schema changes)

• hooks.py

  changes reviewed (scheduler_events, doc_events)
• Custom Fields exported to fixtures
• Environment config (site_config.json) has no secrets in Git
• Redis and MariaDB/PostgreSQL services healthy

Post-Deployment Verification (Frappe)

curl -I https://mysite.com

bench doctor

sudo supervisorctl status

bench migrate

Rollback (Frappe)

# 1. Restore code
cd apps/my_ehealth && git checkout <previous_tag> && cd ../..

# 2. Restore database
bench --site mysite.localhost restore /path/to/backup.sql.gz

# 3. Migrate and rebuild
bench --site mysite.localhost migrate
bench build
sudo supervisorctl restart all

Multi-Tenant Deployment

bench config dns_multitenant on
bench new-site tenant2.example.com
bench --site tenant2.example.com install-app my_ehealth
bench setup nginx
sudo service nginx reload

Healthcare-Specific Deployment Notes

• Ensure TLS 1.2+ is configured in Nginx for all sites handling PHI.
• Set

  session_expiry

  in site_config.json (e.g., "04:00:00" for 4 hours, or shorter for clinical workstations).
• Enable

  deny_multiple_sessions

  if required by compliance policy.
• Verify audit trail (Version DocType) is enabled for all healthcare DocTypes before go-live.
• Test backup restore procedure with PHI data to confirm encryption and integrity.

Remember: Every deployment is a risk. Minimize risk through preparation, not speed.