Skip to content

Multi-Environment Deployment Workflow

Environment Hierarchy

Development → Staging → Production
  (dev)      (staging)   (prod)
  rpi-dev-*  rpi-staging-* rpi-*

Device Naming Convention

  • Development: rpi-dev-1883c4049f6c, rpi-dev-1883c404a12f, ... (testing & development)
  • Staging: rpi-staging-1883c404a130, rpi-staging-002, ... (pre-production validation)
  • Production: rpi-prod-1883c404a12f, rpi-staging-1883c404a130, ... (critical infrastructure)

Deployment Commands

1. Deploy to Development (test changes)

task ansible:deploy-all  # Deploys to all dev devices only
# OR specific device
task ansible:deploy DEVICE=rpi-dev-1883c4049f6c

2. After Testing → Promote to Staging

# Changes validated in dev, ready for staging
task ansible:deploy-all  # Deploys to staging devices
# OR specific device
task ansible:deploy DEVICE=rpi-staging-1883c404a130

3. After Staging Validation → Promote to Production

# Changes validated in staging, ready for production
task ansible:deploy-all  # Deploys to production devices (requires approval)

Health Checks by Environment

Development

task ansible:health  # Immediate results, verbose output

Staging

task ansible:health  # Production-like validation

Production

task ansible:health  # Conservative, monitored

Playbook-Specific Commands

Restart Services

# By environment
task ansible:restart DEVICE=rpi-dev-1883c4049f6c      # Development
task ansible:restart DEVICE=rpi-staging-1883c404a130  # Staging
task ansible:restart DEVICE=rpi-prod-1883c404a12f          # Production

Renew Certificates

# By environment
task ansible:renew-certs  # Runs on all environments that need renewal

Ping Connectivity

# Test specific environment
task ansible:ping-device DEVICE=rpi-dev-1883c4049f6c
task ansible:ping-device DEVICE=rpi-staging-1883c404a130
task ansible:ping-device DEVICE=rpi-prod-1883c404a12f

Environment Settings

Development (development.yml)

  • Strategy: Immediate deployment
  • Backups: Disabled
  • Monitoring: Minimal
  • Health checks: Every 5 minutes (dev iteration)

Staging (staging.yml)

  • Strategy: Validated deployment (requires passing validation)
  • Backups: Enabled
  • Monitoring: Enabled
  • Health checks: Every 5 minutes (pre-prod validation)

Production (production.yml)

  • Strategy: Approval required before deployment
  • Backups: Enabled (30-day retention)
  • Monitoring: Full monitoring enabled
  • Health checks: Every 10 minutes (conservative)
  • Alerts: CPU/Mem/Disk thresholds configured

Manual Changes Flow

  1. Make change on development device
  2. Test and validate in dev environment
  3. Run same change on staging via playbook
  4. Validate in staging (testing, health checks)
  5. Request approval for production deployment
  6. Deploy to production after approval

Automation: Change Promotion Pipeline

Code Change
    ↓
Dev Deployment (rpi-dev-XXX)
    ↓
    [Automated Tests Run]
    ↓
Staging Deployment (rpi-staging-XXX)
    ↓
    [Production-like Validation]
    ↓
Production Deployment (rpi-XXX)
    ↓
    [Monitoring & Alerts Enabled]

Adding New Devices

  1. Development: Add rpi-dev-XXX to development group in hosts.yml
  2. Staging: Add rpi-staging-XXX to staging group in hosts.yml
  3. Production: Add rpi-XXX to production group in hosts.yml

Example: 

development:
  hosts:
    rpi-dev-1883c4049f6c:
      local_host: 192.168.1.50
      tunnel_host: rpi-dev-1883c4049f6c-ssh.tagai.uk
      device_region: development

Emergency Production Override

For urgent fixes in production (bypass staging): 

# Use with extreme caution
ansible-playbook playbooks/site.yml -i inventory/production/hosts.yml \
  --limit production \
  --extra-vars "skip_validation=true"

Note: This should only be used in emergencies and requires senior engineer approval.