GitLab CI/CD : comment automatiser ses pipelines

Dans l'approche GitOps, il existe de nombreux outils permettant d'exécuter des pipelines CI/CD : certains se concentrent uniquement sur la partie intégration continue, d'autres avec le déploiement en plus. Parmi tous les outils présents sur le marché, propriétaires (comme GitHub) ou open source (comme Jenkins), s'il y en a un qui est considéré comme l'un des plus matures et des plus robustes, c'est bien GitLab.

Quelques années après sa création, GitLab avait déjà une vision innovante pour intégrer dans une seule plateforme à la fois la gestion de dépôts Git et l'exécution de pipelines automatisés. Cette double casquette a fait de GitLab l'un des outil les plus appréciés pour les développeurs, notamment au sein des entreprises qui ne souhaitent pas publier leur code source via Internet sur des plateformes comme GitHub.

Au cours de cet article, nous allons détailler les différentes fonctionnalités de GitLab CI/CD, qui ont permis d'en faire un sérieux concurrent face à des géants comme GitHub. Nous verrons ainsi comment créer et exécuter un pipeline CI/CD sur GitLab à partir d'un fichier de configuration YAML.

GitLab CI/CD

Comme d'autres plateformes similaires telles que GitHub, GitLab est un gestionnaire de dépôts Git qui facilite la collaboration au sein d'équipes de développement, basée sur le langage Ruby.

Une des principales caractéristiques de GitLab est sa nature open source, et dispose à la fois d'une version gratuite, et d'une version payante pour les entreprises.

À partir des versions 10, GitLab a évolué pour devenir bien plus qu'un simple outil de gestion de dépôt Git. Il propose maintenant une approche DevOps complète, fusionnant le développement et les opérations au sein d'une expérience utilisateur unifiée.

GitLab se compose d'une série de modules qui s'intègrent harmonieusement pour offrir une solution complète pour le développement, la gestion de projet et les opérations DevOps. Au cœur de cette solution, nous pouvons créer des projets, des espaces dédiés où l'on héberge le code, collabore avec toutes les équipes et où l'on peut suivre les problèmes, bug ou propositions d'améliorations.

GitLab propose également des fonctionnalités intégrées pour l'intégration continue et la livraison continue (CI/CD), regroupées sous le nom de GitLab CI/CD.

Les fonctionnalités d'intégration continue (CI) sont au cœur de GitLab, nous permettant d'ajouter des fragments de code à une application hébergée dans un dépôt Git. Chaque fois que l'on effectue un push de code, GitLab peut exécuter un pipeline de scripts pour tester les modifications avant de les valider et de les intégrer au projet.

La livraison continue (CD) de GitLab nous offre également la possibilité de déployer automatiquement nos applications en production à chaque push de code. La configuration du CI/CD se fait grâce à un fichier nommé .gitlab-ci.yml situé à la racine de votre dépôt Git. Les scripts définis dans ce fichier sont exécutés par le GitLab Runner, qui orchestre le processus de déploiement.

GitLab CI/CD offre plusieurs avantages pour les équipes de développement logiciel.

• Intégration continue intégrée : les pipelines CI/CD sont directement intégrées directement dans la plateforme GitLab, ce qui facilite grandement la configuration et l'utilisation de l'intégration continue pour tous les projets.
• Automatisation des workflows : Vous pouvez automatiser diverses tâches, telles que les tests unitaires, les tests d'intégration, la compilation, le déploiement, etc., en utilisant des pipelines définis dans GitLab CI.
• Pipelines déclaratifs : les pipelines GitLab sont définies avec du YAML, qui est devenu en quelques années un standard pour l'aspect déclaratif des ressources. Cela permet donc de versionner efficacement les pipelines elles-mêmes.

GitLab Runners

Les GitLab Runners sont des agents qui permettent d'exécuter des tâches automatisées, notamment des builds, des tests et des déploiements, dans les pipelines GitLab. Concrètement, ce sont eux qui exécutent véritablement les jobs. Les Runners peuvent être de diverses nature.

• Ils peuvent être situés sur des serveurs séparés de l'instance qui héberge GitLab : il peut s'agit de machines virtuelles, mais aussi de conteneurs Docker ou même dans Kubernetes.
• Les Runners sont pensés pour distribuer la charge et permettent une configuration avancée : certains peuvent avoir des ressources différentes, des capacités d'exécution variées, etc.

GitLab offre plusieurs types de Runners pour répondre à différents besoins de déploiement et d'exécution de tâches. Un des plus utilisés est le Runner Shell : concrètement, ce type de runner utilise un Shell local sur la machine où il est configuré pour exécuter les tâches du pipeline. Il est utile pour les tests rapides, les scripts simples et les projets de petite taille, et il ne nécessite pas de conteneur Docker ou de machine virtuelle.

Un autre type de Runner souvent utilisé est le Runner Docker : ils exécutent des tâches dans des conteneurs Docker isolés. Ils sont utiles pour exécuter des environnements de build ou de test spécifiques, ainsi que pour garantir l'isolation des tâches.

À découvrir : notre formation DevOps Engineer

Il en existe également d'autres, comme Runner Kubernetes, lorsque la charge de travail peut nécessiter une scalabilité importante, ou encore des Runners spécifiques comme Runner VirtualBox ou Runner Windows.

GitLab dispose de son propre vocabulaire pour identifier des objets, des processus ou des événements. En pratique, on retrouvera un ensemble assez important de vocabulaire déjà connu parmi les autres outils équivalents.

• Job : il s'agit sûrement l'un des concepts les plus importants. Un Job est une tâche automatisée qu'un Runner doit exécuter. Cela peut inclure la construction d'un projet, l'exécution de tests ou encore le déploiement d'une application. Il s'agit particulièrement de la plus petite unité de calcul dans un processus automatisé.
• Pipeline : lorsque des jobs sont exécutés de manière séquentielle ou en parallèle (ou même les deux à la fois), cela forme des Pipelines. Il s'agit d'une séquence de jobs organisés de manière à automatiser un processus de bout en bout. GitLab permet de définir des pipelines complexes en utilisant le format YAML.
• Trigger : le trigger indique la manière donc un pipeline est déclenché/exécuté. Par exemple, le déclenchement peut être réalisé en réponse à un événement (push sur Git, appel API via Webhook), ou selon des intervalles périodiques (CRON).

Pipeline et Jobs

En réalité, un pipeline, c'est plus que simplement des jobs ordonnés. En effet, comment ces jobs peuvent-ils communiquer entre eux ? Comment peuvent-ils se partager des informations ou des fichiers ?

Les jobs sont isolés les uns des autres pour garantir la cohérence et la sécurité des opérations. Chaque travail s'exécute dans son propre espace de travail isolé, ce qui signifie qu'il dispose de son propre répertoire dédié où il effectue toutes les opérations de construction, de test et de déploiement. Cette isolation entre les jobs permet d'éviter les interférences potentielles entre eux et garantit que les travaux s'exécutent de manière fiable et prévisible.

Ensuite, certains de ces jobs vont produire des artifacts, qui sont le résultat de la construction d'une application. Il peut s'agir d'un fichier binaire, d'un package, ou d'autres éléments créés lors de la construction. En général, ce sont ces artifacts que l'on déploie.

• Il peut s'agit de fichiers HTML/CSS/JS statique pour le déploiement de site Web.
• Cela peut être des fichiers JAR qui seront ensuite déployés.
• Des images Docker peuvent également être construites dans un job GitLab.

Au final, il y a beaucoup de flexibilité au sein d'un job, il suffit de choisir une typologie de job qui convient à nos besoins.

À lire : découvrez notre formation DevOps Engineer

Création d'un pipeline CI/CD sur GitLab

Pour configurer une pipeline CI/CD dans un projet GitLab, il suffit de créer un fichier .gitlab-ci.yml à la racine du proejt Git. Par défaut, GitLab nous propose le pipeline suivant.

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

unit-test-job:
  stage: test
  script:
    - echo "Running unit tests... This will take about 20 seconds."
    - sleep 20
    - echo "Code coverage is 90%"

lint-test-job:
  stage: test 
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 10
    - echo "No lint issues found."

deploy-job:
  stage: deploy
  environment: production
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."

Tout d'abord, nous définissons les stages de notre pipeline. Un stage peut être vu comme une étape composée d'un ou plusieurs jobs : tant qu'un stage n'est pas terminé, le suivant ne démarrera pas. Cette configuration peut donc être utile si l'on souhaite exécuter un certain nombre de jobs en parallèle, tout en attendant qu'ils se terminent tous avant d'en exécuter un suivant.

Dans cet exemple, il y a trois stages, qui correspondent assez bien aux étapes que l'on retrouve dans la plupart des applications.

• build : cette première étape est destinée à la compilation du code source, notamment pour les langages compilés comme le C, Rust, Go ou Java.
• test : cette étape est destinée à l'exécution de tests, avec notamment les tests unitaires et les tests de linting. Cela permet de s'assurer par exemple que le code respecte un certain standard avant de l'intégrer ou déployer l'application.
• deploy : enfin, cette étape est destinée au déploiement de l'application, généralement sur un environnement de production.

Chaque étape du pipeline contient un ou plusieurs jobs, qui sont des unités d'exécution définies par les développeurs pour effectuer des tâches spécifiques. Dans cet exemple, il y a quatre jobs définis : build-job, unit-test-job, lint-test-job et deploy-job. Pour chaque job, nous avons le stage associé, le script (c'est-à-dire les commandes à exécuter) et pour le dernier job le champ environment, qui permettra de passer des environnements spécifiques (ici, l'environnement sera similaire aux autres puisque production n'a pas encore été défini.

Le principal avantage de GitLab est qu'il dispose d'une interface visuelle permettant de monitorer les différentes étapes (stages) et jobs. Cela facilite grandement la possibilité d'inspecter les logs, ou de relancer certains jobs de manière spécifique.

Conclusion

Pour de nombreuses entreprises qui souhaitent intégrer une approche GitOps dans leurs processus, GitLab se révèle être un acteur de choix. En effet, sa possibilité d'être déployé On-Premise permet aux entreprises désireuses de conserver le code source en interne d'utiliser un outil mature et bien en place.

La possibilité de configurer de manière très détaillé les différents Runners offre une grande flexibilité pour de nombreux projets nécessitants des pipelines CI/CD. Avec sa très grande popularité, GitLab est sans conteste l'un des outil de gestion de dépôts Git et de pipelines d'automatisation les plus robustes sur le marché actuellement.