💼 Un projet plus réaliste

Maintenant que nous avons les bases, nous allons utiliser un projet de démo que nous avons préparer pour découvrir des fonctionnalités plus avancées.

1. Forker le projet sample-project via le bouton Fork

2. Regarder le .gitlab-ci.yml, il inclut:

   • des notions connues : rules, stage, environment
   • 2 nouvelles notions :
     • include: permet d'importer un autre fichier yml contenant des définitions de stages et de jobs, ou de components.
     • extends: permet de surcharger un job déjà défini. Cela peut être un job abstrait que l'on préfixe avec .

   👉 Ces 2 notions sont pratiques lorsque l'on souhaite mettre en place une bibliothèque de jobs réutilisables et/ou normaliser ses pipelines, mais aussi pour découper les jobs en plusieurs fichiers pour que cela reste lisible lorsque l'on a des pipelines avec beaucoup de jobs.

3. Déclencher un pipeline manuellement depuis Build > Pipelines et le bouton Run Pipeline

4. Vérifier que l'environnement est bien créé et que l'application est déployée en cliquant sur le bouton Open (dans Operate > Environments)

Success

Le site est déployé et accessible depuis le menu Operate > Environments avec le nom xxx-sample-project-main

Il serait intéressant de pouvoir avoir un environnement par Merge Request afin de valider des modifications avant de valider celle-ci.

🔎 Review app

Pour cela, GitLab fournit le mécanisme de review app (doc officielle) qui sont des environnements dynamiques.

Le projet sample-project contient déjà les mécanismes dans le CI pour gérer cela (via la variable DYNAMIC_ENVIRONMENT_URL, cf le fichier dans le répertoire ci/pages/).

Désormais:

• créer une branche review-app et la MR associée (attention à pointer sur la branche main de votre projet et pas de celle du projet d'origine qui est sélectionnée par défaut)
• sur cette branche, modifier le fichier main.go dans le répertoire website (✋ pas besoin de connaitre le go pour faire la modification 😅)
  • Par exemple, remplacer 👋 Hello World 🌍 par 👋 Hello Devfest Lille 🍺
• commiter

Success

• Le pipeline s'exécute correctement ✅
• Un environnement a été ajouté dans la liste ✅
• Le site modifié est déployé à l'URL liée à l'environnement ✅
• L'environnement est affiché dans la MR ✅

• merger la MR dans main

Success

• Le pipeline s'exécute correctement ✅
• L'environnement de la MR a été supprimé ✅
• Le site de la branche main est mis à jour ✅

🧱 Utilisation des components

Depuis la version 16.6, GitLab propose les CI/CD components permettant de facilement factoriser et capitaliser sur la création de pipeline CI.

🐣 Mon premier component

1. Créer un répertoire .gitlab/components
2. Dans un fichier my_component.yml, créer un premier component en se basant sur ce snippet
3. Dans le fichier gitlab-ci.yml, ajouter l'include pour utiliser le component (💡 aide)
4. Commiter

Success

• Le pipeline s'exécute correctement ✅
• Le job du composant est exécuté ✅

L'avantage des components, ils fournissent des valeurs par défaut pour les input. Mais ceux-ci peuvent facilement être surchargés.

1. Dans le fichier gitlab-ci.yml, modifier l'include du component pour que l'animal ne soit plus celui par défaut mais soit dragon
2. Commiter

Success

• Le pipeline s'exécute correctement ✅
• Le job du composant est exécuté ✅
• Dans les logs du job 🐮_meuh, un dragon nous dit bonjour.

La gestion des inputs permet facilement customiser un job et son exécution. Mais, avoir des components en local est assez limitant. Cela peut servir pour des gros projets avec des pipelines complexes pour simplifier la lisibilité des étapes.

Pour capitaliser plus largement, il sera plus intéressant d'inclure des components qui seraient gérés globalement sur un groupe, une instance GitLab.

🔗 Component mutualisé

On vous a préparé un component disponible ici.

1. Inclure ce component dans le fichier .gitlab-ci.yml dans sa version 1.3
2. Commiter

Success

• Le pipeline s'exécute correctement ✅
• Le job du composant est exécuté ✅

🧪 Gestion des tests unitaires

Dans les vrais projets, nous avons tous des tests unitaires. GitLab permet d'avoir des rapports sur les tests unitaires à différents niveaux.

Nous allons donc ajouter un nouveau job pour exécuter les tests unitaires. Pour cela nous, nous créerons un component local au projet.

Dans le projet en cours, sur la branche main:

1. ajouter à la racine du repository, un fichier de tests unitaires (en JS par exemple, snippet) nommé par exemple : test.js
2. inclure le component mocha_tests (dans le même projet que charasay), en version 2.5 dans .gitlab-ci.yml (section include) pour importer le job
3. Surcharger ce job pour produire un artifact avec le fichier de résultats des tests test-results.xml (GitLab fournit des mots clés pour reconnaitre des rapports).

4. commiter

   Success

   • Le pipeline s'exécute correctement ✅
   • Dans l'onglet du pipeline, le nombre de tests unitaires est affiché et tous sont ok ✅

5. créer une branche et une MR failing-test (attention à pointer sur la branche main de votre projet et pas de celle du projet d'origine qui est sélectionnée par défaut)

6. sur cette branche, ajouter un nouveau fichier de test failing.js qui ne passe pas
   • 💡 exemple

7. commiter

   Bug

   • Le pipeline est en erreur ✋
   • Dans la MR, le résumé des tests apparait avec le test en erreur ✅

8. corriger le test en erreur

9. commiter

   Success

   • Le pipeline s'exécute correctement ✅
   • Dans la MR, le résumé des tests apparait sans test en erreur ✅

🖼️ Code quality

GitLab fournit également des analyseurs de code pour contrôler la qualité, en se basant sur l'outil CodeClimate.

Dans le projet en cours sur la branche main:

1. configurer code climate pour go en utilisant le snippet fourni dans le fichier .codeclimate.yml à la racine du projet
   • il existe d'autres analyzers en fonction du langage de programmation utilisés
2. ajouter un job pour contrôler la qualité du code go en utilisant les jobs fournis par GitLab
   • Configurer pour que le job code_quality s'exécute durant le stage tests
3. commiter

Success

Le pipeline s'exécute correctement ✅

On constate que le job code-quality met un certain temps à s'exécuter par défaut. GitLab permet via la notion de label de pouvoir typer les jobs. Cela sert en particulier pour que les jobs soient exécutés sur des runners en particulier, comme par exemple certains shared runners mis à disposition sur gitlab.com.

1. modifier le job code-quality pour qu'il soit pris en charge par un runner medium
2. commiter sur la branche main

Success

• Le pipeline s'exécute correctement ✅
• Le job code-quality s'exécute plus rapidement ✅
• Le job a été exécuté par un shared runner medium ✅

On peut également avoir le rapport de Code Quality au sein d'une merge request.

1. créer une branche & une MR code-quality (attention à pointer sur la branche main de votre projet et pas de celle du projet d'origine qui est sélectionnée par défaut)
2. modifier le fichier main.go pour ajouter un problème (par exemple : // FIXME ou // TODO)
3. compléter le job code_quality pour qu'il s'exécute sur les MR
4. commiter sur la branche code-quality

Success

• Le pipeline s'exécute correctement ✅
• Le panel Code Quality apparait dans la MR ✅