Dev to QA Iteration

This guide explains the recommended workflow for iterating between development and QA environments using SNAPSHOT versions.

Overview

The dev-to-QA workflow in Odin uses SNAPSHOT versions for fast iteration:

1. Development: Deploy SNAPSHOT to dev, make changes
2. QA: Deploy same SNAPSHOT to staging for testing
3. Iteration: Fix issues, redeploy SNAPSHOT
4. Release: Create CONCRETE version for production

Step 1: Start Development

Create a service with a SNAPSHOT version:

service.json

{
  "name": "user-api",
  "version": "1.0.0-SNAPSHOT",
  "team": "backend",
  "components": [
    {
      "name": "api",
      "type": "webservice",
      "version": "1.0.0",
      "depends_on": ["database"]
    },
    {
      "name": "database",
      "type": "postgres",
      "version": "14.5"
    }
  ]
}

Step 2: Deploy to Development

Deploy to your dev environment:

odin deploy service --env dev \
  --file service.json \
  --provisioning provisioning-dev.json

provisioning-dev.json (lightweight resources):

[
  {
    "component_name": "api",
    "deployment_type": "kubernetes-deployment",
    "params": {
      "namespace": "dev",
      "cpu": "100m",
      "memory": "256Mi",
      "replicas": 1,
      "image": "myregistry/user-api:dev"
    }
  },
  {
    "component_name": "database",
    "deployment_type": "rds-postgres",
    "params": {
      "instance_class": "db.t3.micro",
      "storage": "20"
    }
  }
]

Step 3: Develop and Test

Make changes to your application:

1. Update code
2. Build new Docker image
3. Redeploy the SAME SNAPSHOT version

# Build and push new image
docker build -t myregistry/user-api:dev .
docker push myregistry/user-api:dev

# Redeploy (same version)
odin deploy service --env dev \
  --file service.json \
  --provisioning provisioning-dev.json

Fast Iteration

SNAPSHOT versions can be redeployed multiple times without changing the version number. This allows for fast iteration.

Step 4: Pass to QA

Once development is stable, deploy to QA/staging:

odin deploy service --env staging \
  --file service.json \
  --provisioning provisioning-staging.json

provisioning-staging.json (more production-like):

[
  {
    "component_name": "api",
    "deployment_type": "kubernetes-deployment",
    "params": {
      "namespace": "staging",
      "cpu": "500m",
      "memory": "1Gi",
      "replicas": 2,
      "image": "myregistry/user-api:staging"
    }
  },
  {
    "component_name": "database",
    "deployment_type": "rds-postgres",
    "params": {
      "instance_class": "db.t3.small",
      "storage": "50",
      "multi_az": false
    }
  }
]

Step 5: QA Testing

QA team tests the SNAPSHOT version in staging:

# Check status
odin status env staging --service user-api

# Get service details
odin describe env staging --service user-api

Step 6: Bug Fixes and Iteration

If QA finds issues:

1. Fix in code
2. Build new image
3. Redeploy to dev for verification
4. Redeploy to staging for QA retest

# Fix code and rebuild
docker build -t myregistry/user-api:dev .
docker push myregistry/user-api:dev

# Test in dev
odin deploy service --env dev \
  --file service.json \
  --provisioning provisioning-dev.json

# After verification, update staging
docker tag myregistry/user-api:dev myregistry/user-api:staging
docker push myregistry/user-api:staging

odin deploy service --env staging \
  --file service.json \
  --provisioning provisioning-staging.json

Version Stays Same

The version remains 1.0.0-SNAPSHOT throughout this iteration. Only the Docker image changes.

Step 7: Release for Production

Once QA approves, create a CONCRETE version:

1. Update version (remove -SNAPSHOT)
2. Build release image
3. Tag in Git

service.json

{
  "name": "user-api",
  "version": "1.0.0",  // Removed -SNAPSHOT
  "team": "backend",
  "components": [...]
}

# Build production image
docker build -t myregistry/user-api:1.0.0 .
docker push myregistry/user-api:1.0.0

# Tag in Git
git tag v1.0.0
git push origin v1.0.0

Step 8: Deploy to Production

Deploy the CONCRETE version to production:

provisioning-prod.json (production-grade):

[
  {
    "component_name": "api",
    "deployment_type": "kubernetes-deployment",
    "params": {
      "namespace": "production",
      "cpu": "2",
      "memory": "4Gi",
      "replicas": 5,
      "image": "myregistry/user-api:1.0.0"
    }
  },
  {
    "component_name": "database",
    "deployment_type": "rds-postgres",
    "params": {
      "instance_class": "db.r5.large",
      "storage": "200",
      "multi_az": true,
      "backup_retention_days": 14
    }
  }
]

odin deploy service --env production \
  --file service.json \
  --provisioning provisioning-prod.json

Production Confirmation

Odin will ask for confirmation before deploying to production. Type yes to proceed.

Step 9: Start Next Iteration

Begin work on the next version:

{
  "name": "user-api",
  "version": "1.1.0-SNAPSHOT",
  ...
}

Workflow Diagram

┌─────────────┐
│ Development │
│ 1.0.0-SNAP  │
└──────┬──────┘
       │ Deploy
       ▼
┌─────────────┐
│     Dev     │  ←─┐
│ Environment │    │ Iterate
└──────┬──────┘    │
       │ Ready     │
       ▼           │
┌─────────────┐    │
│   Staging   │    │
│ Environment │ ───┘ Bug Fixes
└──────┬──────┘
       │ QA Approved
       ▼
┌─────────────┐
│  Release    │
│ 1.0.0       │
└──────┬──────┘
       │ Deploy
       ▼
┌─────────────┐
│ Production  │
│ Environment │
└─────────────┘

Best Practices

1. Keep Dev and Staging in Sync

Ensure staging reflects production as closely as possible:

# Regular sync from dev to staging
odin deploy service --env staging \
  --file service.json \
  --provisioning provisioning-staging.json

2. Use Image Tags

Tag Docker images consistently:

• dev: Latest development build
• staging: Currently in QA
• 1.0.0: Production releases

3. Automate Image Builds

Use CI/CD to build images on commits:

.github/workflows/build.yml

name: Build
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Build and push
        run: |
          docker build -t myregistry/user-api:dev .
          docker push myregistry/user-api:dev

4. Document Changes

Track changes in each SNAPSHOT deployment:

# Keep a changelog
echo "$(date): Fixed login bug" >> CHANGELOG-SNAPSHOT.md
git commit -am "Fix login bug"

5. Test Before QA

Always test in dev before passing to staging:

# Dev deployment
odin deploy service --env dev \
  --file service.json \
  --provisioning provisioning-dev.json

# Manual testing
curl https://dev.api.example.com/health

# If OK, deploy to staging
odin deploy service --env staging \
  --file service.json \
  --provisioning provisioning-staging.json

Troubleshooting

QA Found a Critical Bug

Roll back staging to previous working version:

# Option 1: Redeploy previous Docker image
# Update provisioning.json with previous image tag
odin deploy service --env staging \
  --file service.json \
  --provisioning provisioning-staging.json

# Option 2: Undeploy and redeploy
odin undeploy service user-api --env staging
# Fix issue
odin deploy service --env staging \
  --file service.json \
  --provisioning provisioning-staging.json

Different Behavior in Staging

Check provisioning differences:

diff provisioning-dev.json provisioning-staging.json

Ensure resource limits and configurations match:

{
  "env_variables": {
    "ENVIRONMENT": "staging",  // Must match actual environment
    "DB_HOST": "staging-db.example.com"
  }
}

Related Guides

• Deploy First Service
• Update a Service
• Deploy to Production
• Rollback Deployment