Exercice 02 : Organiser les stages et les jobs

🎯 Objectifs

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

• ✅ Définir 3 stages enchaînés : build, test, deploy
• ✅ Créer plusieurs jobs dans un même stage pour les exécuter en parallèle
• ✅ Comprendre que les jobs d'un même stage s'exécutent simultanément
• ✅ Observer la dépendance implicite entre stages dans GitLab

Durée estimée : 20 minutes

Difficulté : ⭐☆☆☆☆ (Débutant)

Prérequis :

• Exercice 01 complété
• Compte GitLab.com avec un projet existant

📖 Contexte

Un pipeline GitLab CI est organisé en stages (étapes) et en jobs (tâches). Les stages s'exécutent séquentiellement, mais les jobs à l'intérieur d'un même stage s'exécutent en parallèle sur des runners différents. Cette organisation permet d'accélérer le pipeline tout en garantissant un ordre logique.

📋 Énoncé

Créez un pipeline avec 3 stages (build, test, deploy) contenant au total 5 jobs. Le stage test contiendra 2 jobs qui s'exécuteront en parallèle. Un job de deploy ne s'exécutera que si tous les tests réussissent.

🧭 Déroulement de l'exercice

Tâche 1 : Déclarer les 3 stages

Dans votre .gitlab-ci.yml, déclarez les stages build, test et deploy dans le bon ordre. Ajoutez aussi une image globale node:20-alpine.

Indice : L'ordre de déclaration dans la liste stages: détermine l'ordre d'exécution. Si vous omettez la clé stages:, GitLab utilise les stages par défaut : .pre, build, test, deploy, .post.

Vérification : Le CI Lint de GitLab valide le fichier sans erreur.

Tâche 2 : Ajouter le job de build

Créez un job build-app dans le stage build. Il doit simuler une compilation en affichant "Compilation en cours..." et en créant un fichier dist/app.js avec mkdir dist && echo 'app' > dist/app.js.

Indice : Pensez à utiliser artifacts: pour transmettre le dossier dist/ aux stages suivants. Pour l'instant, utilisez juste echo et mkdir pour simuler.

Vérification : Le job build-app s'affiche seul dans le stage build.

Tâche 3 : Ajouter 2 jobs de test en parallèle

Créez deux jobs dans le stage test :

• test-unitaire : affiche "Tests unitaires OK" et sleep 5
• test-lint : affiche "Lint OK" et sleep 3

Indice : Il suffit que les deux jobs aient stage: test. GitLab les enverra à deux runners différents et les exécutera simultanément. Le stage test ne sera considéré réussi que si les deux jobs réussissent.

Vérification : Dans le graphe du pipeline, les deux jobs test-* apparaissent côte à côte sous le même stage.

Tâche 4 : Ajouter le job de déploiement

Créez un job deploy-staging dans le stage deploy. Il doit afficher "Déploiement sur staging..." et le message "URL : https://staging.mon-app.example.com".

Indice : Le stage deploy ne démarrera que si tous les jobs du stage test ont réussi. C'est la dépendance implicite entre stages.

Vérification : Le job deploy-staging ne s'exécute que si test-unitaire ET test-lint sont verts.

Tâche 5 : Mesurer le gain de temps

Observez dans l'interface GitLab le temps total du pipeline. Comparez :

• Si test-unitaire (5s) et test-lint (3s) étaient séquentiels : 8s
• En parallèle : 5s (durée du plus long)

Indice : Allez dans CI/CD → Pipelines → cliquez sur votre pipeline. La durée totale est affichée en haut à droite. Elle correspond à la somme des stages, pas des jobs individuels.

Vérification : La durée du stage test dans les logs est proche de 5s (et non 8s).

🗂️ Mini-Projet : Pipeline 3 stages avec parallélisme

Structure du pipeline :

Stage: build   →   Stage: test      →   Stage: deploy
─────────────      ────────────────      ─────────────
build-app          test-unitaire         deploy-staging
                   test-lint
                   (parallèle)

Checkpoints de validation :

• 3 stages déclarés dans le bon ordre
• test-unitaire et test-lint s'exécutent en parallèle
• deploy-staging n'est pas lancé si un test échoue
• Le pipeline complet est vert en moins de 20 secondes
• Le graphe du pipeline est visible dans GitLab CI/CD