GitLab Release Strategies

A release strategy is a plan for moving new code to real users with as little risk as possible. Different strategies trade speed, cost, and safety. GitLab environments, manual jobs, and rules support each approach.

Think of opening a new bridge. One city closes the old bridge and opens the new one overnight. Another city opens one lane first and watches the traffic. Each plan fits a different level of risk.

Strategy Overview

Strategy	How It Works	Risk	Extra Cost
Recreate	Stop the old version, start the new version	Short downtime	None
Rolling	Replace servers one by one	Low	Low
Blue-green	Run two full copies and switch traffic	Very low	High
Canary	Send a small share of users to the new version	Very low	Medium

Recreate

  Time →
  v1 ████████████░░░░░░░░░░░░░░
  v2 ░░░░░░░░░░░░░░████████████
                  ↑ downtime gap

The simplest plan fits internal tools and night-time maintenance windows. Users see a brief outage.

Rolling Release

  Servers:   [S1] [S2] [S3] [S4]
  Start:      v1   v1   v1   v1
  Step 1:     v2   v1   v1   v1
  Step 2:     v2   v2   v1   v1
  Step 3:     v2   v2   v2   v1
  Done:       v2   v2   v2   v2

Users stay online during the whole process. A fault appears on one server first, and the team stops the rollout.

Blue-Green Release

              ┌─────────────┐
  Users ────► │ Load        │ ──► BLUE  (v1, live)
              │ balancer    │
              └─────────────┘ ┄┄► GREEN (v2, tested, idle)

  After the switch:
  Users ────► Load balancer ──► GREEN (v2, live)
                              BLUE  (v1, kept for rollback)

The team deploys to the idle copy, tests it, and flips traffic in one step. Rollback means flipping back. The price is double infrastructure during the switch.

Canary Release

  100 users
     ├── 95 users ──► v1 (stable)
     └──  5 users ──► v2 (canary)
                         │
        Metrics healthy? ├─ Yes → raise to 25, 50, 100 percent
                         └─ No  → send everyone back to v1

The canary group tests the change in real conditions. A problem harms only a few users.

Build Stages in GitLab

A typical pipeline moves code through environments, and each stage adds a gate.

stages:
  - build
  - test
  - staging
  - production

deploy-staging:
  stage: staging
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: production
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://www.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

The manual setting adds a play button. A person confirms the release after checking staging. Staging catches mistakes, and the button gives a human final say.

Roll Back Quickly

Open Operate → Environments and select the production environment. The page lists past deployments. Choose an earlier successful deployment and select Re-deploy to environment to restore it.

Teams that script their own steps benefit from a dedicated rollback job.

rollback-production:
  stage: production
  script:
    - ./deploy.sh production "$PREVIOUS_VERSION"
  environment:
    name: production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Feature Flags

A feature flag is an on and off switch inside the code. Teams ship the code switched off and turn the feature on for chosen users. The approach separates deployment from release. A bad feature goes off in seconds without a new deployment.

Choose a Strategy

Situation	Good Fit
Internal tool, quiet hours	Recreate
Web service with several servers	Rolling
Payment or booking system that cannot fail	Blue-green
Large user base and good monitoring	Canary
Risky feature in a steady release cycle	Feature flag

Release Safety Habits

• Test the rollback path before the first real release.
• Deploy small changes often; small changes fail less dramatically.
• Watch error rates and response times after every release.
• Keep database changes backward compatible so that old and new code both run.
• Protect the production environment so that only trusted roles deploy.
• Record each release in a GitLab release entry with notes.