Vengala Vinay

Having 9+ Years of Experience in Software Development

Home » Zero-Downtime Blue-Green Deployment Pipelines for Shopify Applications on OVH

Zero-Downtime Blue-Green Deployment Pipelines for Shopify Applications on OVH

Understanding the Blue-Green Deployment Model

Blue-Green deployment is a strategy that minimizes downtime and risk by running two identical production environments, referred to as “Blue” and “Green.” At any given time, only one environment is live, serving production traffic. The other environment is idle, used for testing and deploying new versions. Once the new version is deployed and thoroughly tested on the idle environment, traffic is switched over, making the previously live environment the new idle one for the next deployment cycle.

OVH Infrastructure Considerations for Shopify

For Shopify applications hosted on OVH, particularly those leveraging their Public Cloud offerings (e.g., instances, load balancers, managed databases), a robust blue-green strategy hinges on efficient resource provisioning and traffic management. We’ll assume a setup involving:

  • OVH Public Cloud Instances (e.g., Ubuntu LTS with Nginx/Apache)
  • OVH Load Balancer (for traffic distribution and SSL termination)
  • Managed PostgreSQL or MySQL database (OVH Public Cloud Database Service)
  • A CI/CD orchestrator (e.g., GitLab CI, GitHub Actions, Jenkins)

Database Schema Migrations: The Critical Path

Database schema changes are the most challenging aspect of zero-downtime deployments. A common pitfall is introducing backward-incompatible changes. The key is to ensure that both the old and new application versions can coexist with the database schema during the transition. This typically involves a multi-step migration process:

  • Step 1: Add new columns/tables (backward-compatible): Deploy code that *only* adds new database elements. The old application version will ignore these, and the new version will utilize them.
  • Step 2: Deploy new application version: Once the schema is updated, deploy the new application code that uses the new schema elements.
  • Step 3: Remove old columns/tables (backward-compatible): After verifying the new version, deploy code that *removes* the old schema elements.

For Shopify, this often means managing changes to your custom application’s database, not Shopify’s core data. We’ll use a hypothetical PHP application with a migration script managed by Phinx.

Setting Up the Environments

We need two identical sets of infrastructure. This can be achieved through Infrastructure as Code (IaC) tools like Terraform or by manually replicating configurations. For simplicity in this example, we’ll focus on the deployment script logic, assuming environments are provisioned.

Environment Naming Convention

Let’s designate our environments:

  • Blue Environment: `app-blue.yourdomain.com`
  • Green Environment: `app-green.yourdomain.com`
  • Production Traffic: Routed via OVH Load Balancer to either Blue or Green.

CI/CD Pipeline Orchestration (GitLab CI Example)

We’ll define a GitLab CI pipeline that automates the blue-green deployment process. This pipeline will be triggered on commits to the `main` branch.

`.gitlab-ci.yml` Configuration

This YAML file defines the stages and jobs for our CI/CD pipeline. It includes steps for database migrations, building the application, deploying to the idle environment, and performing health checks.

stages:
  - setup
  - deploy_blue
  - deploy_green
  - promote

variables:
  APP_NAME: "my-shopify-app"
  OVH_REGION: "GRA" # Example OVH region
  DB_USER: ${DB_USER}
  DB_PASSWORD: ${DB_PASSWORD}
  DB_HOST_BLUE: "db-blue.internal.ovh" # Internal DNS for blue DB
  DB_HOST_GREEN: "db-green.internal.ovh" # Internal DNS for green DB
  APP_PORT: 8080 # Port your app listens on
  HEALTH_CHECK_PATH: "/health"

# Job to prepare database migrations
prepare_migrations:
  stage: setup
  script:
    - echo "Running database migrations..."
    - composer install --no-dev --optimize-autoloader
    - vendor/bin/phinx migrate -e production_blue # Target blue DB for initial migration
    - vendor/bin/phinx migrate -e production_green # Target green DB for initial migration
  only:
    - main

# Job to deploy to the Blue environment
deploy_to_blue:
  stage: deploy_blue
  script:
    - echo "Deploying to Blue environment..."
    - ./scripts/deploy.sh "blue"
  only:
    - main

# Job to deploy to the Green environment
deploy_to_green:
  stage: deploy_green
  script:
    - echo "Deploying to Green environment..."
    - ./scripts/deploy.sh "green"
  only:
    - main

# Job to promote the Green environment to production
promote_to_production:
  stage: promote
  script:
    - echo "Promoting Green to Production..."
    - ./scripts/promote.sh
  when: manual # Requires manual trigger after verification
  only:
    - main

Deployment Script (`scripts/deploy.sh`)

This script handles the actual deployment of the application code to a specific environment (Blue or Green). It assumes SSH access to the target servers and uses `rsync` for efficient file transfer.

#!/bin/bash

ENV=$1 # "blue" or "green"
APP_DIR="/var/www/${APP_NAME}_${ENV}"
SSH_USER="deployer" # Your deployment user on OVH instances
SSH_HOST_BLUE="app-blue.yourdomain.com"
SSH_HOST_GREEN="app-green.yourdomain.com"

if [ "$ENV" == "blue" ]; then
  TARGET_HOST=$SSH_HOST_BLUE
elif [ "$ENV" == "green" ]; then
  TARGET_HOST=$SSH_HOST_GREEN
else
  echo "Invalid environment specified: $ENV"
  exit 1
fi

echo "Deploying to ${ENV} environment on ${TARGET_HOST}..."

# Ensure the application directory exists
ssh ${SSH_USER}@${TARGET_HOST} "mkdir -p ${APP_DIR}"

# Sync application files
rsync -avz --delete \
  --exclude '.git' \
  --exclude 'vendor' \
  --exclude 'node_modules' \
  . ${SSH_USER}@${TARGET_HOST}:${APP_DIR}/

# Execute post-deployment steps on the remote server
ssh ${SSH_USER}@${TARGET_HOST} "
  cd ${APP_DIR} && \
  composer install --no-dev --optimize-autoloader && \
  php artisan cache:clear && \
  php artisan config:clear && \
  php artisan route:clear && \
  # Add any other necessary commands like asset compilation, etc.
  echo 'Deployment to ${ENV} complete.'
"

echo "Deployment to ${ENV} finished."

Promotion Script (`scripts/promote.sh`)

This script is the heart of the blue-green switch. It involves updating the OVH Load Balancer configuration to point traffic to the newly deployed environment (Green) and then performing health checks.

Note: Interacting with OVH Load Balancer APIs requires using their SDK or CLI tools. For this example, we’ll use placeholder commands. You’ll need to replace these with actual OVH API calls.

#!/bin/bash

echo "Starting promotion process..."

# --- Step 1: Update Load Balancer ---
# This is a placeholder. You'll need to use OVH API/CLI to:
# 1. Get the current active backend (Blue or Green).
# 2. Disable the current active backend.
# 3. Enable the new backend (Green).
# 4. Wait for the change to propagate.

echo "Updating OVH Load Balancer to point to Green environment..."
# Example placeholder command (replace with actual OVH API call)
# ovh --region ${OVH_REGION} lb backend update ${LOAD_BALANCER_ID} --backend-id ${GREEN_BACKEND_ID} --status active
# ovh --region ${OVH_REGION} lb backend update ${LOAD_BALANCER_ID} --backend-id ${BLUE_BACKEND_ID} --status inactive

echo "Load Balancer updated. Waiting for propagation..."
sleep 30 # Adjust as needed for LB propagation

# --- Step 2: Health Checks ---
# Perform health checks on the new production environment (Green)
echo "Performing health checks on Green environment..."
HEALTH_CHECK_URL="https://app-green.yourdomain.com${HEALTH_CHECK_PATH}" # Assuming SSL is terminated at LB

# Simple curl-based health check (enhance this for production)
if curl --fail --silent --show-error "$HEALTH_CHECK_URL"; then
  echo "Health check passed for Green environment."

  # --- Step 3: Finalize Promotion (Optional but Recommended) ---
  # If health checks pass, you might want to:
  # 1. Mark the Blue environment as "standby" or "maintenance"
  # 2. Update DNS records if not solely relying on LB
  # 3. Trigger post-promotion tasks

  echo "Promotion to Production successful!"
  # You might want to trigger a job to clean up or prepare the Blue environment for the next cycle.

else
  echo "Health check failed for Green environment. Rolling back..."
  # --- Step 4: Rollback ---
  # If health checks fail, immediately switch traffic back to the Blue environment.
  echo "Switching traffic back to Blue environment..."
  # Example placeholder command (replace with actual OVH API call)
  # ovh --region ${OVH_REGION} lb backend update ${LOAD_BALANCER_ID} --backend-id ${BLUE_BACKEND_ID} --status active
  # ovh --region ${OVH_REGION} lb backend update ${LOAD_BALANCER_ID} --backend-id ${GREEN_BACKEND_ID} --status inactive

  echo "Rollback complete. Please investigate the issue on the Green environment."
  exit 1
fi

exit 0

Database Migration Strategy in Detail

The `prepare_migrations` job in `.gitlab-ci.yml` needs to be carefully configured. We’ll use Phinx with multiple environments defined in its configuration file.

Phinx Configuration (`phinx.yml`)

 [
        'migrations' => '%%PHINX_CONFIG_DIR%%/db/migrations',
        'seeds' => '%%PHINX_CONFIG_DIR%%/db/seeds'
    ],
    'environments' => [
        'default_migration_table' => 'phinxlog',
        'production_blue' => [
            'adapter' => 'mysql', # Or 'pgsql' for PostgreSQL
            'host' => 'db-blue.internal.ovh',
            'name' => 'shopify_app_db',
            'user' => '${DB_USER}',
            'pass' => '${DB_PASSWORD}',
            'port' => 3306, # Or 5432 for PostgreSQL
            'charset' => 'utf8mb4',
        ],
        'production_green' => [
            'adapter' => 'mysql',
            'host' => 'db-green.internal.ovh',
            'name' => 'shopify_app_db',
            'user' => '${DB_USER}',
            'pass' => '${DB_PASSWORD}',
            'port' => 3306,
            'charset' => 'utf8mb4',
        ],
        # Add development, staging environments as needed
    ],
    'version_order' => 'creation'
];

In the CI job, we execute migrations against both environments sequentially:

vendor/bin/phinx migrate -e production_blue
vendor/bin/phinx migrate -e production_green

This ensures that both the Blue and Green databases are in sync with the latest schema before any application code is deployed to either. Remember to structure your migrations to be backward-compatible as outlined earlier.

Health Checks and Verification

A robust health check endpoint (`/health` in our example) is crucial. This endpoint should:

  • Verify database connectivity.
  • Check essential external service dependencies (e.g., Shopify API connection).
  • Return a 200 OK status if healthy, and a non-200 status otherwise.

The `promote.sh` script uses `curl` to check this endpoint. For production, consider more sophisticated checks, potentially involving multiple requests or synthetic transactions.

OVH Load Balancer Configuration

Your OVH Load Balancer needs to be configured with two backend servers (or groups of servers), one for each environment. The load balancer should be set up to distribute traffic to the active backend. The `promote.sh` script will dynamically change which backend is marked as “active” or “primary.”

Key configurations for the OVH Load Balancer:

  • Frontend: Configured with your domain name, SSL certificate (for HTTPS), and listening port (e.g., 443).
  • Backend Pool (Blue): List of IP addresses/hostnames for your Blue environment servers, port (e.g., 8080), health check settings.
  • Backend Pool (Green): List of IP addresses/hostnames for your Green environment servers, port (e.g., 8080), health check settings.
  • Rules: Direct traffic from the frontend to the appropriate backend pool based on your promotion logic.

Security Considerations

When setting up SSH access for deployments, use dedicated deployer users with limited privileges. Ensure SSH keys are managed securely. For database credentials, leverage environment variables or secrets management tools provided by your CI/CD platform (e.g., GitLab CI variables, encrypted secrets).

Rollback Strategy

The `promote.sh` script includes a basic rollback mechanism. If health checks fail after switching traffic to Green, it attempts to switch back to Blue. This relies on the Blue environment still being operational and in a known good state. Thorough testing of the rollback procedure is as important as testing the deployment itself.

Conclusion and Next Steps

Implementing zero-downtime blue-green deployments for Shopify applications on OVH requires careful orchestration of infrastructure, application code, and database migrations. This advanced setup, while complex, provides significant benefits in terms of application availability and deployment safety. Key areas for further refinement include:

  • Automating OVH Load Balancer configuration changes using their API/CLI.
  • Implementing more sophisticated health checks and automated rollback triggers.
  • Leveraging Infrastructure as Code (Terraform) for consistent environment provisioning.
  • Ensuring all database migrations are strictly backward-compatible.
  • Testing the entire pipeline, including rollback scenarios, in a staging environment that mirrors production.