Exercice 03 : Configurer des environnements de déploiement

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Déclarer un environnement avec environment: name: et url:
✅ Configurer un déploiement staging automatique et production manuel (when: manual)
✅ Consulter l'historique des déploiements dans Deployments → Environments
✅ Comprendre le concept de rollback via les environnements GitLab

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐⭐☆ (Avancé)

Prérequis :

Exercice 02 gitlab-ci-avance complété
Compréhension des règles rules: GitLab CI

📖 Contexte

Les Environments dans GitLab sont plus qu'un simple label : ils créent un historique des déploiements, permettent les rollbacks en un clic, et s'intègrent avec les feature flags et le monitoring. Chaque job qui déclare environment: crée une entrée dans Deployments → Environments.

📋 Énoncé

Créez un pipeline de déploiement avec deux environnements : staging (déploiement automatique sur main) et production (déploiement manuel, avec URL réelle). Observez l'historique des déploiements et testez le rollback.

🧭 Déroulement de l'exercice

Tâche 1 : Configurer le déploiement staging

Créez un job deploy-staging qui déclare environment: name: staging avec une URL simulée. Ce job s'exécute automatiquement sur main.

Indice :
`yaml
deploy-staging:
environment:
name: staging
url: https://staging.mon-app.example.com
script:
- echo "Déploiement sur staging..."
`
Après ce job, GitLab crée une entrée dans Deployments → Environments avec le statut "Active" pour l'environnement staging.

Vérification : L'onglet Deployments → Environments affiche staging avec une URL et le statut du dernier déploiement.

Tâche 2 : Configurer le déploiement production avec approbation manuelle

Créez un job deploy-production avec environment: name: production, when: manual dans les rules:, et une URL de production.

Indice :
`yaml
deploy-production:
environment:
name: production
url: https://mon-app.example.com
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual
- when: never
`
when: manual dans rules: est différent de when: manual au niveau du job. Préférez la version dans rules: car elle est plus explicite et compatible avec needs:.

Vérification : Le job deploy-production apparaît avec un bouton play dans le pipeline. Sans clic, l'environnement production reste sur la version précédente.

Tâche 3 : Utiliser des variables d'environnement dynamiques

Configurez des variables d'environnement différentes selon l'environnement cible. Utilisez $CI_ENVIRONMENT_NAME dans le script pour adapter le comportement.

Indice :
`yaml
script:
- echo "Déploiement sur $CI_ENVIRONMENT_NAME"
- echo "URL cible : $CI_ENVIRONMENT_URL"
`
$CI_ENVIRONMENT_NAME et $CI_ENVIRONMENT_URL sont des variables prédéfinies injectées automatiquement quand un job déclare environment:.

Vérification : Les logs affichent le nom de l'environnement et son URL.

Tâche 4 : Simuler un rollback

Faites un premier déploiement sur staging. Puis faites un second déploiement avec un echo "v2.0". Dans Deployments → Environments → staging, cliquez sur "Re-deploy" du déploiement précédent pour simuler un rollback.

Indice : GitLab conserve l'historique des déploiements. Le bouton "Re-deploy" sur un déploiement précédent relance le même job avec le même commit, simulant un rollback. Le déploiement "actif" est toujours le dernier déploiement réussi.

Vérification : Après le rollback, le commit actif dans l'environnement staging repointe sur la version précédente.

Tâche 5 : Configurer l'auto-stop d'un environnement de review

Créez un job de déploiement de "review app" pour les branches de merge request, avec on_stop: pointant vers un job de nettoyage.

Indice :
`yaml
deploy-review:
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_COMMIT_REF_SLUG.preview.example.com
on_stop: stop-review
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

stop-review:
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
when: manual
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
`

Vérification : Lors de la fermeture d'une MR, GitLab propose de déclencher stop-review pour nettoyer l'environnement.

🗂️ Mini-Projet : Environnements staging et production

Checkpoints de validation :

Deployments → Environments liste staging et production
deploy-staging se déclenche automatiquement sur main
deploy-production nécessite un clic manuel (bouton play)
$CI_ENVIRONMENT_NAME est correctement valorisée dans les logs
Un rollback peut être effectué depuis l'interface GitLab

Exercice 03 : Configurer des environnements de déploiement

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Déclarer un environnement avec environment: name: et url:
✅ Configurer un déploiement staging automatique et production manuel (when: manual)
✅ Consulter l'historique des déploiements dans Deployments → Environments
✅ Comprendre le concept de rollback via les environnements GitLab

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐⭐☆ (Avancé)

Prérequis :

Exercice 02 gitlab-ci-avance complété
Compréhension des règles rules: GitLab CI

📖 Contexte

📋 Énoncé

🧭 Déroulement de l'exercice

Tâche 1 : Configurer le déploiement staging

Créez un job deploy-staging qui déclare environment: name: staging avec une URL simulée. Ce job s'exécute automatiquement sur main.

Indice :
`yaml
deploy-staging:
environment:
name: staging
url: https://staging.mon-app.example.com
script:
- echo "Déploiement sur staging..."
`
Après ce job, GitLab crée une entrée dans Deployments → Environments avec le statut "Active" pour l'environnement staging.

Vérification : L'onglet Deployments → Environments affiche staging avec une URL et le statut du dernier déploiement.

Tâche 2 : Configurer le déploiement production avec approbation manuelle

Créez un job deploy-production avec environment: name: production, when: manual dans les rules:, et une URL de production.

Indice :
`yaml
deploy-production:
environment:
name: production
url: https://mon-app.example.com
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual
- when: never
`
when: manual dans rules: est différent de when: manual au niveau du job. Préférez la version dans rules: car elle est plus explicite et compatible avec needs:.

Vérification : Le job deploy-production apparaît avec un bouton play dans le pipeline. Sans clic, l'environnement production reste sur la version précédente.

Tâche 3 : Utiliser des variables d'environnement dynamiques

Configurez des variables d'environnement différentes selon l'environnement cible. Utilisez $CI_ENVIRONMENT_NAME dans le script pour adapter le comportement.

Indice :
`yaml
script:
- echo "Déploiement sur $CI_ENVIRONMENT_NAME"
- echo "URL cible : $CI_ENVIRONMENT_URL"
`
$CI_ENVIRONMENT_NAME et $CI_ENVIRONMENT_URL sont des variables prédéfinies injectées automatiquement quand un job déclare environment:.

Vérification : Les logs affichent le nom de l'environnement et son URL.

Tâche 4 : Simuler un rollback

Indice : GitLab conserve l'historique des déploiements. Le bouton "Re-deploy" sur un déploiement précédent relance le même job avec le même commit, simulant un rollback. Le déploiement "actif" est toujours le dernier déploiement réussi.

Vérification : Après le rollback, le commit actif dans l'environnement staging repointe sur la version précédente.

Tâche 5 : Configurer l'auto-stop d'un environnement de review

Créez un job de déploiement de "review app" pour les branches de merge request, avec on_stop: pointant vers un job de nettoyage.

Indice :
`yaml
deploy-review:
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_COMMIT_REF_SLUG.preview.example.com
on_stop: stop-review
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

stop-review:
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
when: manual
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
`

Vérification : Lors de la fermeture d'une MR, GitLab propose de déclencher stop-review pour nettoyer l'environnement.

🗂️ Mini-Projet : Environnements staging et production

Checkpoints de validation :

Deployments → Environments liste staging et production
deploy-staging se déclenche automatiquement sur main
deploy-production nécessite un clic manuel (bouton play)
$CI_ENVIRONMENT_NAME est correctement valorisée dans les logs
Un rollback peut être effectué depuis l'interface GitLab