A small monolithic application hosted on GitLab needs to be migrated to a new version with zero downtime. The goal is to rely on a supported GitLab feature rather than custom scripts. The application already uses Auto DevOps for CI/CD, and the progressive deployment strategy offered by Auto DevOps is being considered. Questions: How can progressive deployment be enabled and configured within Auto DevOps? What environment variables or settings are required to control the staged rollout? How can the migration be verified to result in zero downtime?

Answer – Immediate Steps 1. Enable Auto DevOps for the project (Project → Settings → CI/CD → Auto‑DevOps). The pipeline must include the Auto‑DevOps template. 2. Turn on progressive deployment in the same settings page – the toggle “Auto‑DevOps progressive deployment” should read Enabled. 3. Define environments in .gitlab-ci.yml (e.g., staging and production) and tag the runner with the corresponding environment name. 4. Set the strategy variable in the pipeline configuration or as a protected variable: variables: DEPLOYMENT_STRATEGY: "progressive" # Optional: control traffic split PROGRESSIVE_DEPLOYMENT_PERCENT: "10" 5. Run a pipeline. The Auto DevOps job will deploy the new container image to a canary instance first. The job logs will show a stage named Deploy to production (progressive) that creates two deployment records – one for the old revision and one for the new canary. 6. Verify health checks for the canary URL (GitLab exposes the URL in the job artifacts). If the canary passes, the pipeline automatically shifts traffic to the new revision using the load balancer’s traffic‑splitting feature. 7. Monitor metrics during the shift. If any error threshold is exceeded, the pipeline rolls back to the previous stable revision. The rollback is automatic and visible in the deployment history. 8. Clean up after a successful shift – the old deployment is marked finished and resources are released. Verification Checklist Project CI/CD settings show Auto‑DevOps progressive deployment: Enabled. Pipeline logs contain the Deploy to production (progressive) stage with two deployment entries. GitLab UI (Deployments page) shows separate URLs for the canary and production environments during the shift. Load balancer metrics (e.g., NGINX upstream percentages) move from 0 % to 100 % for the new revision without request drops. Missing Diagnostic Detail To ensure the traffic‑splitting works as expected, could you confirm which load balancer or ingress controller your cluster is using (e.g., NGINX Ingress, Traefik, AWS ALB, etc.)? This may affect the exact configuration needed for zero‑downtime rollouts. Explanation – How It Works Auto DevOps progressive deployment is a built‑in canary strategy that relies on the pipeline to create two parallel deployments. The new revision is first exposed on a distinct path or port; the old revision keeps serving traffic. Once the canary passes health checks, the pipeline updates the load balancer to route all requests to the new revision. If the new revision fails, the pipeline automatically reverts to the old deployment, ensuring no downtime. Key assumptions: The project uses a supported runtime (Java, Node.js, Python, etc.) that Auto DevOps can build. The target environment (Kubernetes, Docker, etc.) supports traffic splitting via its load balancer. Feature‑flag variables are set correctly; otherwise the pipeline may default to a rolling deployment that can introduce brief hiccups. Because the feature depends on the underlying load balancer, verify that your environment supports zero‑downtime rollouts before relying solely on this approach.

Auto DevOps Progressive Deployment for Zero Downtime Migration

1 answer

Tasadduq BurneyownerOwner · Founder

26525 reputation · 28 Aug 2021, 06:02 UTC

Permalink

Answer – Immediate Steps

1. Enable Auto DevOps for the project (Project → Settings → CI/CD → Auto‑DevOps). The pipeline must include the Auto‑DevOps template.

2. Turn on progressive deployment in the same settings page – the toggle “Auto‑DevOps progressive deployment” should read Enabled.

3. Define environments in .gitlab-ci.yml (e.g., staging and production) and tag the runner with the corresponding environment name.

4. Set the strategy variable in the pipeline configuration or as a protected variable:

variables:
  DEPLOYMENT_STRATEGY: "progressive"
  # Optional: control traffic split
  PROGRESSIVE_DEPLOYMENT_PERCENT: "10"

5. Run a pipeline. The Auto DevOps job will deploy the new container image to a canary instance first. The job logs will show a stage named Deploy to production (progressive) that creates two deployment records – one for the old revision and one for the new canary.

6. Verify health checks for the canary URL (GitLab exposes the URL in the job artifacts). If the canary passes, the pipeline automatically shifts traffic to the new revision using the load balancer’s traffic‑splitting feature.

7. Monitor metrics during the shift. If any error threshold is exceeded, the pipeline rolls back to the previous stable revision. The rollback is automatic and visible in the deployment history.

8. Clean up after a successful shift – the old deployment is marked finished and resources are released.

Verification Checklist

Project CI/CD settings show Auto‑DevOps progressive deployment: Enabled.
Pipeline logs contain the Deploy to production (progressive) stage with two deployment entries.
GitLab UI (Deployments page) shows separate URLs for the canary and production environments during the shift.
Load balancer metrics (e.g., NGINX upstream percentages) move from 0 % to 100 % for the new revision without request drops.

Missing Diagnostic Detail

To ensure the traffic‑splitting works as expected, could you confirm which load balancer or ingress controller your cluster is using (e.g., NGINX Ingress, Traefik, AWS ALB, etc.)? This may affect the exact configuration needed for zero‑downtime rollouts.

Explanation – How It Works

Auto DevOps progressive deployment is a built‑in canary strategy that relies on the pipeline to create two parallel deployments. The new revision is first exposed on a distinct path or port; the old revision keeps serving traffic. Once the canary passes health checks, the pipeline updates the load balancer to route all requests to the new revision. If the new revision fails, the pipeline automatically reverts to the old deployment, ensuring no downtime.

Key assumptions:

The project uses a supported runtime (Java, Node.js, Python, etc.) that Auto DevOps can build.
The target environment (Kubernetes, Docker, etc.) supports traffic splitting via its load balancer.
Feature‑flag variables are set correctly; otherwise the pipeline may default to a rolling deployment that can introduce brief hiccups.

Because the feature depends on the underlying load balancer, verify that your environment supports zero‑downtime rollouts before relying solely on this approach.

Your perspective belongs here.

Join the conversation

1 question comment

Use comments to ask for clarification. Post a solution as an answer.

Tasadduq BurneyownerOwner · FounderPermalink

26,525 reputation · 28 Aug 2021, 02:23 UTC

While the pipeline handles the traffic split, it is important to note that progressive deployment creates a period where two different versions of the application are active and accessing the same database simultaneously. To maintain zero downtime and prevent crashes, your database migrations must be backward-compatible.

Implementation Requirements

Additive Changes: Only use additive schema changes (e.g., adding a nullable column) rather than renaming or deleting existing columns.
Two-Step Migration: If a column must be renamed, deploy a version that supports both the old and new names first, then remove the old column in a subsequent release after the canary is fully promoted.
Resource Overhead: Ensure your Kubernetes cluster has sufficient resource quotas to host both the stable and canary pods concurrently during the transition.

You can verify the concurrent state by running kubectl get pods during the progressive stage to confirm both versions are healthy before promoting the canary.