formation git

Utiliser Git et la CI/CD pour les projets Data : guide complet

Emmanuel Jakobowicz Mis à jour le : 14 février 2025 méthode Leave a Comment

Dans le domaine de la data, on manipule des notebooks Jupyter, des scripts d’ingénierie (ETL, feature engineering), des modèles de Machine Learning, ainsi que divers fichiers de configuration et de paramétrage. Git est l’outil indispensable pour gérer ces éléments en équipe et conserver un historique complet et traçable de toutes les modifications. Et pour rendre le cycle de développement encore plus fluide, il est recommandé d’intégrer des processus d’Intégration Continue et Livraison Continue (CI/CD).

Dans cet article, nous allons :

  • Décrire la terminologie et le fonctionnement de base pour utiliser Git.
  • Présenter des exemples de commandes utiles (classiques et avancées).
  • Expliquer comment structurer un workflow Git pour les projets Data.
  • Montrer comment la CI/CD peut automatiser et fiabiliser le déploiement de vos pipelines et modèles.
  • Aborder l’installation de Git sur différentes plateformes.

1. Pourquoi Git est-il si important pour les projets Data ?

Avant l’arrivée de Git, les développeurs utilisaient principalement des systèmes de gestion de versions centralisés (comme Subversion ou CVS). Désormais, Git, qui est distribué, permet à chaque collaborateur de disposer d’un répertoire complet contenant tout l’historique du projet.

1.1 Avantages spécifiques pour la data

  • Collaboration facilitée
    Plusieurs data scientists, data engineers ou analystes peuvent travailler simultanément sur le même projet en créant des branches indépendantes, puis fusionner (merge) leur travail.
  • Traçabilité des analyses
    Chaque commit « fige » l’état d’un script ou d’un notebook à un instant T. Cela permet de reproduire des résultats en revenant à une version antérieure.
  • Gestion des notebooks
    Malgré la structure JSON peu adaptée aux diffs, des outils comme nbdime facilitent l’inspection et la résolution de conflits sur vos notebooks Jupyter.
  • Sécurisation du travail
    L’historique étant répliqué sur chaque machine, il y a moins de risques de perte en cas de panne serveur.

Avec Git, vous obtenez un historique complet, des logs précis et la possibilité de revenir en arrière rapidement si un problème survient (problème de data drift, bug, résultats incohérents, etc.). C’est un véritable « filet de sécurité » pour vos projets data.

1.2 Installation de Git

Pour commencer à utiliser Git, vous devez l’installer sur votre machine. Voici les options les plus courantes :

  • Windows
    • Téléchargez l’installeur depuis le site officiel : https://git-scm.com/download/win.
    • Suivez les étapes de l’assistant d’installation, en conservant généralement les paramètres par défaut.
    • Vérifiez la bonne installation en ouvrant un terminal (PowerShell ou Git Bash) et en tapant : git --version
  • macOS
  • Linux (Ubuntu / Debian)
    • Dans un terminal, exécutez : sudo apt-get update sudo apt-get install git
    • Autres distributions : utilisez le gestionnaire de paquets approprié (yum, dnf, pacman, etc.).
    • Vérifiez : git --version

Une fois installé, vous pouvez configurer vos informations de base (nom et email) :

git config --global user.name "VotreNom"
git config --global user.email "votre.email@exemple.com"

Votre environnement est maintenant prêt pour versionner vos projets data.

2. Terminologie fondamentale de Git

Pour bien exploiter Git, il est nécessaire de connaître certains concepts clés :

  • Dépôt (Repository)
    L’espace dans lequel tous vos fichiers (scripts, notebooks, configurations) sont suivis par Git. Un dépôt peut être :
    • Local (sur votre machine), créé avec git init.
    • Distant (hébergé sur GitHub, GitLab, Bitbucket…), nommé par défaut origin lorsqu’on le clone.
  • Index (Staging Area)
    L’index, ou zone de préparation, où vous placez les modifications avant de les valider avec un commit. Les fichiers qui ne sont pas ajoutés dans l’index n’apparaîtront pas dans le prochain commit.
  • Commit
    Un commit représente un instantané de l’état des fichiers à un moment donné, accompagné d’un message décrivant les changements. Les commits sont enchaînés de manière linéaire (chaînage via des identifiants).
  • Branche (Branch)
    Une branche est une suite de commits. Elle vous permet de travailler sur une fonctionnalité ou une amélioration sans affecter la branche principale (main ou master). La commande git checkout -b nouvelle-branche crée et bascule sur une nouvelle branche.
  • Merge / Pull Request
    • Merge : action de fusionner les commits d’une branche source vers une branche cible (souvent main).
    • Pull Request (PR) ou Merge Request (MR) : sur GitHub, GitLab ou autres, il s’agit d’une demande de fusion souvent associée à une revue de code.
  • HEAD
    Pointeur qui indique la position actuelle du dépôt. Quand vous faites un commit, HEAD se déplace sur ce nouveau commit.

3. Exemples de commandes Git (bases et avancées)

3.1 Initialisation et clonage

# Créer un dépôt local dans un dossier vide
git init

# Cloner un dépôt distant
git clone https://github.com/mon-org/mon-projet-data.git

3.2 Contrôle de l’état et de l’historique

# Voir quels fichiers ont changé, lesquels sont ajoutés ou non
git status

# Visualiser l’historique des commits
git log

# Visualiser l’historique succinct (oneline) et les branches
git log --oneline --graph --decorate

3.3 Gestion des modifications

# Ajouter un fichier au staging
git add script_nettoyage.py

# Ajouter tous les fichiers modifiés
git add .

# Valider les changements en créant un commit
git commit -m "Ajout du script de nettoyage des données brutes"

3.4 Synchronisation avec le dépôt distant

# Envoyer les commits locaux sur la branche main du dépôt origin
git push origin main

# Récupérer les modifications depuis la branche main du dépôt origin
git pull origin main

3.5 Branching et merging

# Créer une nouvelle branche et y basculer
git checkout -b feature/ameliore-modele

# Revenir sur la branche main
git checkout main

# Fusionner la branche feature/ameliore-modele dans main
git merge feature/ameliore-modele

3.6 Gestion des conflits

Lorsque Git rencontre des modifications divergentes sur la même portion de code, il insère des marqueurs de conflit (<<<, ===, >>>) dans le fichier concerné. Vous devez ensuite :

  1. Ouvrir le fichier, décider quelles parties du code garder ou supprimer.
  2. Supprimer les marqueurs de conflit.
  3. Faire un git add <fichier_concerné> et enfin un git commit pour valider la résolution.

3.7 Commandes avancées

# Mettre temporairement de côté ses modifications
git stash
# ... vous faites autre chose ...
git stash pop

# Annuler le dernier commit sans perdre les modifications
git reset --soft HEAD~1

# Annuler le dernier commit et les modifications associées
git reset --hard HEAD~1

# Réécrire l'historique en repositionnant une branche sur une autre
git rebase main
  • stash : permet de sauvegarder temporairement vos modifications, puis de revenir à un état propre.
  • reset : utile pour annuler des commits ou des modifications (à manipuler avec prudence).
  • rebase : réapplique une suite de commits au-dessus d’une autre branche pour conserver un historique plus linéaire (avec précaution si le code est déjà partagé).

4. Workflow Git adapté aux projets Data

4.1 Organisation des répertoires

Pour un projet Data, on retrouve souvent la structure suivante :

mon-projet-data/
├── data/           # Données (attention aux gros fichiers)
├── notebooks/      # Notebooks Jupyter (.ipynb)
├── scripts/        # Scripts Python, R, Bash...
├── models/         # Sauvegardes de modèles (.pkl ou autre)
├── requirements.txt
└── README.md
  • Versionnez en priorité vos scripts, notebooks et fichiers de config.
  • Évitez les gros fichiers dans Git (datasets volumineux, gros modèles). Utilisez Git LFS ou des stockages dédiés (S3, Google Cloud Storage, etc.).
  • Nettoyez vos notebooks avant commit (en enlevant les sorties inutiles ou trop volumineuses).

4.2 Branches de fonctionnalité et Pull Requests

  1. Créez une branche : git checkout -b feature/nouvelle-idee
  2. Développez votre code ou notebook, committez régulièrement.
  3. Pushez votre branche sur le dépôt distant : git push origin feature/nouvelle-idee
  4. Ouvrez une Pull Request depuis la plateforme (GitHub, GitLab).
  5. Demandez des relectures : validez la qualité du code, la pertinence des analyses, etc.
  6. Faites un merge lorsque tout est validé.

5. Introduction à la CI/CD pour les projets Data

5.1 Qu’est-ce que la CI/CD ?

  • CI (Continuous Integration) : À chaque fois que vous poussez du code, un service exécute automatiquement une série de tests (unitaires, d’intégration, etc.).
  • CD (Continuous Delivery ou Deployment) : Une fois les tests validés, le code peut être déployé automatiquement en production ou livré sur un environnement de staging.

Dans un contexte Data, cela peut prendre la forme de :

  1. Tests unitaires sur des scripts de nettoyage et de transformation.
  2. Validation de métriques de performance des modèles (Accuracy, F1, RMSE, etc.).
  3. Exécution automatique de notebooks Jupyter pour vérifier la cohérence des analyses.
  4. Déploiement d’une API (par exemple un modèle pré-entraîné) si les tests passent.

5.2 Exemple avec GitLab CI

Si vous utilisez GitLab, vous pouvez configurer un fichier .gitlab-ci.yml à la racine de votre dépôt :

stages:
  - test
  - deploy

test_job:
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest tests/
  only:
    - merge_requests
    - main

deploy_job:
  stage: deploy
  script:
    - echo "Déploiement de l'app ou du modèle"
  only:
    - main

Explications :

  • stages : liste des étapes à exécuter dans l’ordre (test, puis deploy).
  • test_job : exécute des tests (pytest) sur la branche principale ou lors des merge requests.
  • deploy_job : déploie l’application ou le modèle, seulement sur la branche main.
  • only : spécifie sur quelles branches se déclenchent ces jobs.

5.3 Exemple avec GitHub Actions

Sur GitHub, vous pouvez créer un fichier YAML sous .github/workflows/ci.yml :

name: CI

on:
  push:
    branches: [ "main", "feature/*" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Python
        uses: actions/setup-python@v3
        with:
          python-version: "3.9"

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest --maxfail=1 --disable-warnings

Explications :

  • on.push.branches: déclenche le workflow quand il y a un push sur main ou toute branche commençant par feature/.
  • pull_request.branches: lance également ce workflow lors d’une PR vers main.
  • actions/checkout@v2: permet de récupérer le code du dépôt.
  • actions/setup-python@v3: installe la version de Python voulue (ici 3.9).
  • pytest: exécute vos tests, en s’arrêtant à la première erreur (--maxfail=1).

6. Bonnes pratiques pour allier Git et CI/CD dans un projet Data

  1. Des commits fréquents et explicites
    • Évitez de grossir un seul commit avec trop de changements.
    • Rédigez des messages de commit clairs : “Corrige le bug de lecture du CSV dans script_nettoyage.py”.
  2. Maintenir un README et une arborescence claire
    • Documentez l’installation du projet (fichiers requirements.txt, setup).
    • Expliquez la structure globale pour faciliter la prise en main.
  3. Tester vos pipelines data
    • Mettez en place des tests unitaires et des tests d’intégration (même avec un sous-échantillon de données).
    • Vérifiez la cohérence des transformations et la reproductibilité des analyses.
  4. Utiliser Git LFS ou un stockage distant
    • Pour les grands fichiers ou modèles (ne polluez pas l’historique Git).
    • Git LFS fonctionne bien pour versionner des fichiers de plusieurs centaines de Mo.
  5. Automatiser la qualité de code
    • Configurez des outils de linting (Flake8, Black, isort, etc.) pour maintenir un style cohérent.
    • Suivez les normes PEP 8 (en Python) ou d’autres conventions internes.
  6. Revue de code et validation collective
    • Les pull requests / merge requests permettent de discuter de la qualité du code et de la validité scientifique des résultats.
    • Encouragez l’équipe à commenter et à poser des questions pour un meilleur partage de connaissances.
  7. Déploiement automatisé de modèles
    • Si votre projet inclut un modèle de Machine Learning, vous pouvez automatiser son déploiement sur un serveur (API, Docker, Kubeflow, MLflow…) quand la PR est validée et que les tests de performance sont satisfaisants.

7. Conclusion

Git est un pilier essentiel pour la bonne conduite d’un projet data, offrant une traçabilité fine, une collaboration fluide et une réversibilité totale des modifications. Couplé à des outils de CI/CD (Intégration Continue et Livraison Continue), il vous permet d’automatiser de nombreux aspects du cycle de développement et de déploiement : exécution de tests, validation de notebooks, mise à jour d’API ou de pipelines data, etc.

En suivant les bonnes pratiques ci-dessus et en adoptant une discipline de commits fréquents, d’utilisation pertinente des branches, et de relectures mutuelles, votre équipe pourra atteindre un haut niveau de qualité et de confiance dans ses livrables data. Les erreurs seront détectées plus tôt, les processus de livraison seront plus rapides et plus fiables, et la collaboration, plus efficace.

Nous espérons que ce guide vous aidera à mieux organiser vos projets data et à tirer parti de Git et de la CI/CD. Pour des tutoriels plus avancés (GitFlow, Git LFS, configuration plus poussée de GitHub Actions ou GitLab CI), n’hésitez pas à consulter nos autres publications sur le blog de stat4decision.

Bon versioning à tous, et bonnes analyses de données !

Vous voulez aller plus loin inscrivez-vous à notre formation Git.

Partager cet article

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.