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)

just ansible deploy-all  # Deploys to all dev devices only
# OR specific device
just ansible deploy rpi-dev-1883c4049f6c

2. After Testing → Promote to Staging

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

3. After Staging Validation → Promote to Production

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

Health Checks by Environment

Development

just ansible health  # Immediate results, verbose output

Staging

just ansible health  # Production-like validation

Production

just ansible health  # Conservative, monitored

Playbook-Specific Commands

Restart Services

# By environment
just ansible restart rpi-dev-1883c4049f6c      # Development
just ansible restart rpi-staging-1883c404a130  # Staging
just ansible restart rpi-prod-1883c404a12f          # Production

Renew Certificates

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

Ping Connectivity

# Test specific environment
just ansible ping-device rpi-dev-1883c4049f6c
just ansible ping-device rpi-staging-1883c404a130
just ansible ping-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.