Intégration Continue avec GITLAB-CI/CD

GitLab CI est un système très puissant d’intégration continue, intégrant de nombreuses fonctionnalités, et évoluant rapidement. Je vous en propose une introduction.

C’est quoi le CI/CD

Avant d’attaquer dans le vif du sujet, remettons en place le sujet. Qu’est-ce que le CI/CD ?

L’approche CI/CD permet d’augmenter la fréquence de déploiement des applications grâce à l’utilisation de l’automatisation au niveau des étapes de développement des applications. Les principaux concepts liés à l’approche CI/CD sont l’intégration continue et la livraison continue et lé déploiement continue.

CI pour CONTINUOUS INTEGRATION

L’intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l’application développée. […] Elle permet d’automatiser l’exécution des suites de tests et de voir l’évolution du développement du logiciel. wikipedia

CD pour CONTINUOUS DELIVERY/DEPLOYMENT

La livraison continue est une approche d’ingénierie logicielle dans laquelle les équipes produisent des logiciels dans des cycles courts, ce qui permet de le mettre à disposition à n’importe quel moment. Le but est de construire, tester et diffuser un logiciel plus rapidement. L’approche aide à réduire le coût, le temps et les risques associés à la livraison de changement en adoptant une approche plus incrémentale des modifications en production. Un processus simple et répétable de déploiement est un élément clé. wikipedia

GITLAB CI

GitLab CI va vous permettre d’automatiser les builds, les tests, les livraisons et les déploiements de vos applications.

Principes de fonctionnement de gitlab

Les pipelines

Les pipelines est le composant de premier niveau de l’intégration, de la livraison et du déploiement continue de gitlab.

Les pipelines gèrent des étapes qui contient des taches qui sont exécutés sur des runners.

Les étapes (stages)

Les étapes sont simplement une division logique entre des ensembles de tâches.

Toutes les tâches d’une même étape sont exécutées en parallèle (s’il y a suffisamment de runners) et l’étape suivante ne commence que lorsque toutes les tâches de l’étape précédente sont terminées sans erreurs.

Il suffit que l’une des tâches échoue pour que l’ensemble du pipeline échoue à part quelque cas particuliers.

Les taches

Une tâche est un ensemble d’instructions qu’un runner doit exécuter et peut produire un artefact.

Les artefacts

Un artifact peut contenir des fichiers et/ou dossiers qui vont être stockés au sein des pipelines pour être utilisé par d’autres taches.

Les tags

Utilisez tags pour sélectionner un runner spécifique dans la liste de tous les runners disponibles pour le projet.

Création d’un pipeline CI/CD Gitlab

Prérequis

Pour commencer, nous avons besoin de : • Un compte GitLab.com • Un repo GitLab

Ici nous utiliserons les runners de Gitlab.com mais si vous avez installé votre propre serveur gitlab vous devrez ajouter vos propres runners sur vos serveurs.

Déclaration d’un pipeline CI/CD Gitlab dans votre repository

Il suffit d’ajouter un fichier manifeste portant le nom .gitlab-ci.yml

Comme son nom l’indique ce fichier utilise la syntaxe YAML. En voici un exemple:

job 0:
  stage: .pre
  script: echo "make something useful before build stage"

build-job:
  tags:
    - ruby
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."

Ici nous avons :

• Quatre stages (étapes) : .pre build, test et deploy
• L’étape test contient deux taches : test-job1 et test-job2
• Les taches sont de simples echo qui affichent des variables prédéfinies de gitlab.

En fait il existe deux stages prédéfinis : .pre et .post qui sont toujours lancés respectivement au début et à la fin du ci.

Si vous commitez votre fichier vous pourrez suivre l’exécution du pipeline dans le menu CI/CD.

Ici le résultat de l’étape build :

Running with gitlab-runner 13.9.0-rc2 (69c049fd)
  on docker-auto-scale ed2dce3a
  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true
Preparing the "docker+machine" executor
Using Docker executor with image ruby:2.5 ...
Pulling docker image ruby:2.5 ...
Using docker image sha256:b8f85f05a4c615b08acb073a366ccf8559bdde860861712bb178fb4ee01102a3 for ruby:2.5 with digest ruby@sha256:edc40b439ce1e771849bb398f70b4e202c18d30a0db391f437820bd712774c75 ...
Preparing environment
Running on runner-ed2dce3a-project-25219583-concurrent-0 via runner-ed2dce3a-srm-1615992594-66af060f...
Getting source from Git repository
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/Bob74/test-gitlab/.git/
Created fresh repository.
Checking out eb21ab21 as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script
00:01
Using docker image sha256:b8f85f05a4c615b08acb073a366ccf8559bdde860861712bb178fb4ee01102a3 for ruby:2.5 with digest ruby@sha256:edc40b439ce1e771849bb398f70b4e202c18d30a0db391f437820bd712774c75 ...
$ echo "Hello, $GITLAB_USER_LOGIN!"
Hello, Bob74!
Cleaning up file based variables
00:01
Job succeeded

Vous remarquerez que gitlab.com fait appel à un runner docker utilisant une image ruby 2.5.

Utiliser des images dans votre pipeline gitlab

On peut en premier lieu changer l’image par défaut de tout le pipeline.

default:
  image: ruby:2.7.2

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

...

Ce qui donne :

Running with gitlab-runner 13.9.0-rc2 (69c049fd)
  on docker-auto-scale 0277ea0f
  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true
Preparing the "docker+machine" executor
00:34
Using Docker executor with image ruby:2.7.2 ...
Pulling docker image ruby:2.7.2 ...

Il est possible d’utiliser différentes images dans chacune des étapes. Pour cela il suffit de le spécifier :

default:
  image: ruby:2.7.2

build-job:
  image: alpine:3.12
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"
...

Ce qui donne :

Running with gitlab-runner 13.9.0-rc2 (69c049fd)
  on docker-auto-scale fa6cab46
  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true
Preparing the "docker+machine" executor
Using Docker executor with image alpine:3.12 ...

Les images utilisées sont celles que vous retrouvez dans le docker hub.

Utiliser des variables

Il est possible de créer vos propres variables en utilisant variables dans vos jobs. Ces variables sont de la forme clé: valeur

default:
  image: ruby:2.7.2

build-job:
  image: alpine:3.12
  stage: build
  variables:
    test: "je suis un test"
  script:
    - echo "$test"
...

Depuis la version 14.3 il est possible d’utiliser des variables dans d’autres variables :

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS"'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al'

Il est également possible de créer des variables dans les paramètres CI/CD de votre projet. Ces variables sont soit de la forme File ou Variable et peuvent être cachées/protégées. Nous n’avons pas vu encore la notion d’environnement, mais on peut également limité la portée à un environnement précis.

Gérer vos artefacts

On va modifier la tache build-job pour stocker le fichier test.txt et le conserver pendant une semaine :

default:
  image: ruby:2.7.2

build-job:
  image: alpine:3.12
  stage: build
variables:
    test: "je suis un test"
  script:
    - echo "$test" > test.txt
  artifacts:
    paths:
      - test.txt
    expire_in: 1 week

...

Ce qui donne :

Uploading artifacts for successful job
Uploading artifacts...
test.txt: found 1 matching files and directories
Uploading artifacts as "archive" to coordinator... ok  id=1106004226 responseStatus=201 Created token=bezhCc6-
Cleaning up file based variables
00:01
Job succeeded

On retrouve ce fichier dans le menu ci/cd pipeline

Utilisation des groupes de resources pour limiter la concurrence.

Il peut arriver parfois que si deux jobs tournent en même temps cela provoque des erreurs.

Gitlab propose la notion de resource_group. Les groupes de resources (resource_group) permettent de limiter la concurrence des jobs d’un CI. Il est impossible que deux jobs appartenant au même resource_group de tourner en même temps, même s’ils sont dans deux pipelines différents, ils s’excluent mutuellement.

Exemple :

deploy-to-production:
  script: deploy
  resource_group: production

Conclusion

Cette brève introduction à GitLab ne se veut pas exhaustive, et si vous souhaitez aller plus loin revenez plus tard sur le sujet gitlab de ce blog.