Chapitre 5: premier pas en CI/CD

Le CI/CD veut dire continuous integration / continuous delivery. Il consiste à automatiser toutes les opérations de validation, d’intégration puis de déploiement du code.

Nous n’en sommes pas encore au déploiement du code. Pour l’instant nous souhaiterions simplement nous simplifier la vie et vérifier que le code soit bien formaté et linté quand on le transfert (push) sur github. automatiquement.

Dans ce chapitre nous allons utiliser github workflows pour valider la qualité du code en utilisant les commandes make définies dans le chapitre précédent : black, lint et setup

CI/CD

Continuous Integration (CI) et Continuous Deployment (CD) sont des pratiques de développement logiciel. CI vise à intégrer et à tester le code de manière continue, au fil des commits, tandis que CD vise à automatiser le déploiement des versions du code qui ont été intégrées et testées avec succès.

• Continuous Integration (CI): Les développeurs fusionnent régulièrement leur code dans un référentiel partagé, et chaque fusion déclenche une série d’automatisations de tests et de vérifications. L’objectif est de détecter les erreurs le plus tôt possible dans le processus de développement et d’assurer une intégration fluide du code.

• Continuous Deployment (CD): CD est une extension de CI qui automatise le déploiement du code vers les environnements de production après son intégration et sa validation réussies. L’objectif est de livrer rapidement et fréquemment des versions de logiciels sans compromettre la stabilité ni la qualité.

Comme souvent en MLOps, il y existe de nombreux services et plateformes pour automatiser des tâches. Pour le CI/CD Jenkins est probablement l’outil le plus fréquent. Lancé en 2011, Jenkins est très complet et bénéficie de plus de 1900 plugins pour repondre a tous contextes. C’est cette profusion de plugins plus ou moins maintenus qui complexifie l’utilisation de Jenkins.

Depuis son rachat par Microsoft en 2018, github a développé des outils de CI/CD adaptés à des projets plus simples. gitlab offre aussi des outils similaires.

Dans la suite nous utiliserons github workflows.

Continuous integration avec github workflows

Commençons donc par vérifier que lorsque l’on pousse notre code sur github, il est bien formaté et linté. Si nous avions écrit des tests unitaires, nous rajouterions une étape de test dans le workflow.

A la racine du projet, vous allez créer un répertoire .github (attention il y a un point . avant github) et dans ce répertoire .github un autre répertoire workflows

Vous aurez donc la structure suivante

/.github/workflows

/data

/src

Dans le répertoire workflows, créez le fichier mlops.yml au format yaml. (vous pouvez choisir un autre nom cela n’a pas vraiment d’importance dans la suite)

et dans ce fichier vous écrivez:

name: Validate code

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          make install

      - name: Format code
        run: |
          make format

      - name: Lint with pyLint
        run: |
          make lint

Le code est assez clair:

1. nom du workflow

2. événements: on push. Il existe de nombreux autres événements tout au long du cycle de vie du code: deploy, delete, fork, pull_request, etc …

3. les uses qui sont les hooks pour activer les actions. Notez la définition de la version de python

4. et enfin les actions elles-mêmes qui constituent la phase de build. On en note 3 qui correspondent aux commandes du Makefile: install, format et lint

Quand vous poussez votre code, github va exécuter ces 3 actions dans la phase de build et n’accepter votre code que si les 3 actions passent. Si une des actions échoue, le code ne sera pas déployé.

Prenons un exemple, modifiez et poussez votre code sans l’avoir au préalable vérifié avec pylint.

Allez ensuite dans votre repo sur github et cliquez dans l’onglet “Actions” et dans le message de votre dernier commit.

vous devriez voir que votre build a échoué parce que pylint a trouvé des erreurs.

Attention: comme le build a échoué, votre code n’a pas été mis à jour dans votre repo github.

Commentez maintenant la partie linting du fichier mlops.yml, modifiez votre code et poussez le. le build passe et votre code est mis à jour.

Nous ne touchons là que la partie immergée de l’iceberg du CI/CD. Nous reviendrons dans la suite sur la partie déploiement du code à condition que le build soit réussi.

Pull requests et protection de la branche main

Lorsque vous travaillez sur un projet à plusieurs, certaines règles de protection du code sont mises en place. Il est fréquent que la branche main, voir les autres branches (dev ou staging) soit protégée et ne puissent pas être mise à jour automatiquement même si votre code passe l’étape du build.

Plutôt que de fusionner vos modifications (votre feature branch) directement dans la branche dev ou main, vous allez créer un pull request.

Une pull request indique à l’équipe que votre feature branch est prête à être fusionnée mais que vous souhaiteriez avoir l’avis d’un des autres développeurs. De cette façon, vous pouvez discuter et vous mettre d’accord sur certains points de code à simplifier. Cette discussion permet aussi de garder le fil rouge de conventions et d’organisation du code tout au long du projet.

Une fois les commentaires et les discussions résolues, votre collaborateur peut fermer le pull request et déclencher la fusion de votre feature branch. A ce stade les vérifications de build sont effectuées par github actions et votre code n’est réellement fusionné dans la branche main ou dev que si toutes les actions réussissent.

En résumé, le processus de travail devient semblable à

1. Créer une branche (feature branch)

2. Ecrire le code de la feature

3. Proposer ces modifications via une pull request

4. Discuter et réviser le code avec un collaborateur

5. Prendre en compte les suggestions

6. Rebaser le code si la branche principale a changé

7. Passer les vérifications d’intégration continue

8. Fusionner ou fermer la pull request

9. Supprimer la feature branche

Conclusion

Mettre en place un premier niveau d’intégration continue est finalement assez simple. Tout se déclare dans un fichier yaml qui reprend les commandes du Makefile.

Dans le prochain chapitre nous allons construire l’environnement cloud d’exécution du projet MLOps -DPE ce qui nous permettra ensuite de déployer automatiquement le code une fois le build réussi.