Environnements GitLab CI/CD (deploy targets)

Où déployez-vous votre application : développement, staging, production ? Les environnements GitLab CI/CD permettent de visualiser, suivre et contrôler vos déploiements vers chaque cible. Avec l’historique des versions, le rollback en un clic, et la protection des environnements sensibles.

En 30 secondes

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

GitLab crée une page “Environments” avec l’historique des déploiements, l’accès à l’URL, et la possibilité de rollback.

Ce guide est fait pour vous si…

Vous déployez sur plusieurs cibles Dev, staging, prod avec des configs différentes.

Vous voulez des review apps Un environnement par branche/MR pour les tests.

Vous devez pouvoir rollback Revenir à une version précédente rapidement.

Vous protégez la production Approbation obligatoire, branches autorisées.

Prérequis

Avant de continuer, assurez-vous de maîtriser :

• Rules GitLab CI/CD (pour contrôler quand déployer)
• Variables GitLab CI/CD

Qu’est-ce qu’un environnement ?

Un environnement représente une cible de déploiement : un serveur, un cluster Kubernetes, une instance cloud. GitLab utilise cette information pour :

• Afficher l’historique des déploiements sur chaque environnement
• Permettre le rollback vers une version précédente
• Fournir un lien direct vers l’application déployée
• Protéger les environnements sensibles (approbation, branches autorisées)

Types d’environnements

Type	Nom	Cas d’usage
Statique	production, staging	Environnements permanents, un seul de chaque
Dynamique	review/$CI_COMMIT_REF_NAME	Un par branche/MR, créé et détruit automatiquement

Glissez pour voir

Créer un environnement statique

Un environnement statique existe en permanence. C’est le cas typique de vos environnements de staging et production.

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

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

Propriétés de environment :

Propriété	Description
name	Nom de l’environnement (apparaît dans l’interface)
url	URL de l’application déployée (lien cliquable dans GitLab)
deployment_tier	Niveau : production, staging, testing, development, other

Glissez pour voir

deployment_tier

Le deployment_tier aide GitLab à organiser vos environnements :

environment:
  name: production
  deployment_tier: production

GitLab affiche les environnements de production en priorité dans le dashboard.

Créer des environnements dynamiques (review apps)

Les review apps créent un environnement unique pour chaque branche ou merge request. Idéal pour tester une fonctionnalité avant de la merger.

deploy_review:
  stage: deploy
  script: ./deploy-review.sh $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: stop_review
    auto_stop_in: 1 week
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script: ./destroy-review.sh $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

Points clés :

• name: review/$CI_COMMIT_REF_NAME crée un environnement unique par branche
• on_stop: stop_review définit le job qui détruira l’environnement
• auto_stop_in: 1 week détruit automatiquement après 1 semaine d’inactivité
• action: stop dans le job stop_review indique que c’est le job de destruction

Nettoyage obligatoire

Sans on_stop et auto_stop_in, vos review apps s’accumulent indéfiniment. Pensez toujours à définir une stratégie de nettoyage.

Variables d’environnement spécifiques

GitLab expose des variables automatiques pour chaque déploiement :

Variable	Description	Exemple
CI_ENVIRONMENT_NAME	Nom complet de l’environnement	review/feature-login
CI_ENVIRONMENT_SLUG	Nom formaté pour URL (max 24 car.)	review-feature-lo-a1b2c3
CI_ENVIRONMENT_URL	URL définie dans environment.url	https://staging.example.com
CI_ENVIRONMENT_TIER	Niveau de l’environnement	production
CI_ENVIRONMENT_ACTION	Action en cours	start, stop, prepare

Glissez pour voir

deploy:
  script:
    - echo "Deploying to $CI_ENVIRONMENT_NAME"
    - echo "URL will be $CI_ENVIRONMENT_URL"
    - ./deploy.sh --env-slug $CI_ENVIRONMENT_SLUG
  environment:
    name: staging
    url: https://staging.example.com

Scoped variables : variables par environnement

Définissez des variables différentes selon l’environnement dans Settings > CI/CD > Variables :

1. Ajoutez une variable (ex: DATABASE_URL)
2. Dans “Environments”, sélectionnez l’environnement cible
3. La variable n’existera que pour les jobs déployant sur cet environnement

# Variable DATABASE_URL avec scope
- Scope: staging     → postgres://staging-db.example.com/app
- Scope: production  → postgres://prod-db.example.com/app

Bonne pratique

Utilisez les scoped variables pour les secrets spécifiques à chaque environnement : credentials de base de données, clés API, endpoints.

Protéger un environnement

Les environnements sensibles (production) doivent être protégés pour éviter les déploiements accidentels.

1. Allez dans Settings > CI/CD > Protected environments

2. Sélectionnez l’environnement à protéger (ex: production)

3. Configurez les restrictions :

   • Allowed to deploy : qui peut déployer (Maintainers, groupes, utilisateurs)
   • Required approvals : nombre d’approbations avant déploiement
   • Allowed to approve : qui peut approuver

Résultat : un déploiement vers production nécessitera une approbation avant de s’exécuter.

Rollback en un clic

GitLab garde l’historique de tous les déploiements sur chaque environnement. Pour revenir à une version précédente :

1. Allez dans Operate > Environments

2. Cliquez sur l’environnement concerné

3. Dans l’historique des déploiements, trouvez la version souhaitée

4. Cliquez sur le bouton Rollback (flèche circulaire)

Rollback = re-déploiement

Le rollback rejoue le job de déploiement de la version précédente. Assurez-vous que vos scripts de déploiement sont idempotents (peuvent être rejoués sans effet de bord).

Arrêt automatique des environnements

Pour éviter l’accumulation d’environnements, configurez l’arrêt automatique :

deploy_review:
  environment:
    name: review/$CI_COMMIT_REF_NAME
    on_stop: stop_review
    auto_stop_in: 3 days  # Arrêt automatique après 3 jours

stop_review:
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  when: manual

Formats pour auto_stop_in :

• 30 minutes
• 3 days
• 1 week
• 1 month

Pour prolonger la durée, épinglez l’environnement dans l’interface :

Exemple complet : workflow multi-environnements

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script: docker build -t myapp:$CI_COMMIT_SHA .

test:
  stage: test
  script: docker run myapp:$CI_COMMIT_SHA npm test

# Review app pour chaque MR
deploy_review:
  stage: deploy
  script: ./deploy.sh review $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: stop_review
    auto_stop_in: 1 week
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script: ./destroy.sh review $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

# Staging : auto sur main
deploy_staging:
  stage: deploy
  script: ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
    deployment_tier: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# Production : manuel sur main
deploy_production:
  stage: deploy
  script: ./deploy.sh production
  environment:
    name: production
    url: https://www.example.com
    deployment_tier: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

Surveillance des environnements

GitLab propose un dashboard des environnements (Operate > Environments) qui affiche :

• État actuel de chaque environnement
• Dernier déploiement réussi
• Branche/commit déployé
• Lien vers l’application

Erreurs fréquentes

Symptôme	Cause probable	Solution
Environnement non créé	Job n’a pas la clé environment	Ajouter environment: au job
Review apps qui s’accumulent	Pas de on_stop ni auto_stop_in	Configurer le nettoyage automatique
Rollback échoue	Script non idempotent	Rendre le script rejoable
Variable non trouvée	Mauvais scope sur la variable	Vérifier le scope dans Settings
Déploiement prod bloqué	Protected environment	Demander approbation ou vérifier permissions

Glissez pour voir

À retenir

1. environment.name crée un environnement dans GitLab avec historique des déploiements.
2. Environnements statiques (production) pour les cibles permanentes, dynamiques (review/$BRANCH) pour les review apps.
3. on_stop + auto_stop_in pour nettoyer automatiquement les environnements temporaires.
4. Scoped variables pour avoir des secrets différents par environnement.
5. Protected environments pour contrôler qui peut déployer en production.
6. Rollback disponible en un clic dans l’interface GitLab.

Prochaines étapes

Rapports qualité JUnit, coverage, Code Climate — exploiter les résultats de tests.

Debug pending Pourquoi mon job de déploiement reste en attente ?

Templates et réutilisation Factoriser la configuration avec extends et includes.

×

📖 Voir la documentation →