GitLab CI en production : environments, review apps et feature flags

Tu sais écrire des pipelines, optimiser avec des DAG, et scanner la sécurité. Il reste la partie la plus critique : mettre en production. Le Continuous Deployment, c’est chaque commit sur main qui arrive en production — automatiquement ou avec un clic. GitLab a les outils pour y arriver : environments, review apps, stratégies de déploiement et feature flags.

Environments GitLab

Un environment dans GitLab représente un lieu de déploiement : staging, production, review. C’est un objet first-class avec un historique de déploiements, une URL cliquable et des actions de rollback.

deploy-staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com

deploy-production:
  stage: deploy
  script:
    - ./deploy.sh production
  environment:
    name: production
    deployment_tier: production
    url: https://example.com
  when: manual

GitLab distingue les tiers (production, staging, testing, development) qui affectent l’ordre d’affichage et les protections. Dans Settings > CI/CD > Protected environments, tu peux restreindre qui peut déployer et exiger des approbations : par exemple, production nécessite 2 approbations du groupe “Senior DevOps”.

Environments dynamiques

Pour les review apps, tu crées des environments à la volée avec des variables CI :

deploy-review:
  stage: deploy
  script:
    - ./deploy.sh review-$CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: stop-review
    auto_stop_in: 3 days
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

stop-review:
  stage: deploy
  script:
    - ./teardown.sh review-$CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual

L’environment review/feature-login est créé quand tu ouvres une MR, et détruit manuellement ou automatiquement après 3 jours grâce à auto_stop_in.

Review Apps : tester avant de merger

Les review apps sont des déploiements éphémères par MR. Chaque merge request a son propre environnement accessible par une URL unique. Le reviewer teste l’app en live au lieu de juste lire le code, le product owner voit la feature avant le merge, et les tests E2E tournent sur un vrai déploiement.

L’architecture est simple et élégante : main → production, develop → staging, chaque branche feature → review/nom-de-branche avec sa propre URL.

💡 Sur Kubernetes, tu crées un namespace par review app avec un Deployment, un Service et un Ingress dynamiques. Sur un VPS, un simple Docker Compose par branche avec un port unique suffit. L’important c’est le pattern : créer automatiquement à l’ouverture de la MR, détruire à la fermeture.

🔥 Les review apps raccourcissent drastiquement le feedback loop. Au lieu de “merge → deploy staging → tester → trouver un bug → fix → re-merge”, c’est “ouvrir MR → review app prête → tester → fix dans la même MR”.

Stratégies de déploiement

Rolling update

Le plus courant. Les nouvelles instances remplacent progressivement les anciennes :

deploy-production:
  stage: deploy
  script:
    - kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - kubectl rollout status deployment/app --timeout=5m
  environment:
    name: production

Blue-Green et Canary

Blue-Green : deux environnements identiques. Tu déploies sur “green”, tu vérifies la santé, puis tu bascules le trafic en patchant le Service Kubernetes. Si quelque chose casse, tu rebascules en un clic. Rollback instantané, mais double de ressources.

Canary : tu déploies la nouvelle version sur 10% du trafic, tu observes les métriques (error rate, latence), puis tu promeus progressivement à 100%. GitLab supporte ce pattern avec des jobs manuels : deploy-canary (10%) → promote-canary (100%) ou rollback-canary.

🎯 En pratique : commence par rolling update, passe à blue-green quand le downtime zero est critique, et canary quand tu veux valider sur du vrai trafic avant un rollout complet.

Feature flags

GitLab intègre un système de feature flags basé sur le protocole Unleash (open source). Tu actives ou désactives des features sans redéployer.

from UnleashClient import UnleashClient

client = UnleashClient(
    url=f"{GITLAB_URL}/api/v4/feature_flags/unleash/{PROJECT_ID}",
    app_name="myapp",
    instance_id=GITLAB_FEATURE_FLAGS_INSTANCE_ID,
)
client.initialize_client()

if client.is_enabled("new_checkout_flow"):
    return render_new_checkout()
else:
    return render_old_checkout()

Les stratégies de rollout disponibles : all users (on/off global), percent of users (sticky — le même user voit toujours la même version), user IDs (ciblé), ou user list (groupe prédéfini). Tu configures différentes stratégies par environment : 100% en staging pour tester, 25% en production pour un rollout progressif.

💡 Les feature flags sont complémentaires aux stratégies de déploiement. Le deploy met le code en production, le feature flag contrôle son activation. Tu peux déployer du code derrière un flag désactivé, puis l’activer sans nouveau déploiement.

Pipeline multi-environnement complet

Le pattern standard en entreprise — promotion entre environnements :

stages: [build, test, deploy-staging, deploy-production]

build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

deploy-staging:
  stage: deploy-staging
  script:
    - helm upgrade --install app ./helm --namespace staging
      --set image.tag=$CI_COMMIT_SHORT_SHA
  environment:
    name: staging
    url: https://staging.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

smoke-test:
  stage: deploy-staging
  needs: [deploy-staging]
  script:
    - ./scripts/smoke-test.sh https://staging.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-production:
  stage: deploy-production
  script:
    - helm upgrade --install app ./helm --namespace production
      --set image.tag=$CI_COMMIT_SHORT_SHA --set replicas=3
  environment:
    name: production
    url: https://example.com
  when: manual
  allow_failure: false
  needs: [smoke-test]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Le flow : push sur main → build → deploy staging automatique → smoke tests → deploy production manuel (bloquant avec allow_failure: false). Le rollback se fait via l’UI (Operations > Environments > Re-deploy sur un ancien déploiement) ou via helm rollback / kubectl rollout undo dans un job manuel.

⚠️ Auto DevOps : GitLab propose une solution zero-config qui détecte le langage, build l’image, scanne, et déploie automatiquement. Utile pour du prototypage, mais trop magique pour la production — la plupart des équipes écrivent leurs propres pipelines pour garder le contrôle.

Pièges et bonnes pratiques

🎯 Protected environments obligatoires : production doit être protégée. Sans ça, n’importe quel développeur peut déployer.

🎯 Smoke tests entre staging et prod : ne déploie jamais en production sans validation automatique sur staging. Un simple health check + test de la page d’accueil suffit.

🎯 auto_stop_in sur les review apps : sans ça, tes review apps s’accumulent et consomment des ressources indéfiniment.

🎯 Rollback testé : si tu n’as jamais testé ton rollback, tu n’as pas de rollback. Simule un rollback en staging régulièrement.

🎯 Monitoring post-deploy : surveille le error rate et la latence dans les 5 minutes après un déploiement. Un job verify-deployment qui query Prometheus et annule le pipeline si le error rate dépasse un seuil, c’est un game changer.

C’est le dernier cours de la série GitLab CI/CD. Tu as maintenant une vision complète : de l’architecture aux runners, des templates avancés à la sécurité, jusqu’au déploiement en production. En six cours, tu as couvert tout ce qu’il faut pour gérer des pipelines professionnels. Le meilleur pipeline est celui que tu comprends et que tu peux maintenir — commence simple, itère, automatise progressivement. La suite logique ? Le GitOps, où l’infrastructure et les déploiements sont pilotés par Git. 🚀