Semaine 29-30 : Git et CI/CD 🚀
Objectifs pédagogiques
- Maîtriser Git pour la gestion collaborative et le versionnement du code.
- Mettre en place et administrer des pipelines d’Intégration et de Déploiement Continus (CI/CD).
- Automatiser les déploiements d’applications de manière fiable et réversible.
Sommaire de Navigation
1 — Git : Système de Contrôle de Version Distribué
Git est le système de contrôle de version (Version Control System – VCS) le plus utilisé. Il permet de suivre les modifications apportées aux fichiers, de revenir à des versions antérieures et de faciliter le travail collaboratif.
Système Distribué
Contrairement aux systèmes centralisés, chaque développeur possède une copie complète du référentiel (repository) avec tout l’historique.
- Avantage : Vous pouvez travailler hors ligne, et la défaillance du serveur central ne paralyse pas le travail.
- Référentiel : L’endroit où toutes les versions du code sont stockées. Exemples : GitHub, GitLab, Bitbucket.
Les Trois États de Git
Git gère le code à travers trois zones principales pour le suivi des modifications :
- Répertoire de Travail (Working Directory) : Les fichiers que vous modifiez actuellement.
- Zone de Staging (Staging Area / Index) : Zone où vous préparez les modifications à inclure dans le prochain commit.
- Référentiel Local (.git directory) : L’historique permanent de vos commits locaux.
2 — Workflow et Commandes Fondamentales de Git
Le travail avec Git repose sur la gestion des branches et l’enregistrement régulier des commits.
Commandes Clés
| Commande | Rôle |
|---|---|
git init |
Initialise un nouveau référentiel Git local. |
git add [fichier] |
Ajoute les modifications d’un fichier à la zone de staging. |
git commit -m "Message" |
Enregistre un ensemble de changements (staging area) dans l’historique local. |
git push |
Envoie les commits locaux vers le référentiel distant (ex: GitHub). |
git pull |
Récupère et fusionne les modifications du référentiel distant vers le référentiel local. |
Gestion des Branches
- Branche : Un pointeur léger et mobile vers un commit. La branche principale est souvent appelée `main` ou `master`.
- Flux de Travail (Git Flow / Trunk-Based) : Utilisation de branches distinctes (`feature`, `develop`, `release`) pour isoler les développements et les tests avant de les fusionner dans `main`.
git checkout -b [nom_branche]: Crée et bascule vers une nouvelle branche.git merge [branche_a_fusionner]: Intègre les modifications d’une branche dans la branche actuelle.
3 — Intégration Continue (CI)
L’Intégration Continue (CI) est une pratique de développement où les développeurs fusionnent leurs modifications de code fréquemment (plusieurs fois par jour) dans la branche principale. Chaque fusion déclenche une série de vérifications automatisées.
Objectifs de la CI
- Détection Précoce des Erreurs : Identifier rapidement les bugs ou les problèmes de compatibilité.
- Assurer la Qualité du Code : Exécuter des linters (vérification de style) et des tests unitaires/d’intégration.
- Création d’Artéfacts : Produire des livrables prêts au déploiement (ex: un fichier JAR, une image Docker).
Outils de CI
Les outils de CI orchestrent l’exécution des tâches définies dans un fichier de configuration (Pipeline).
- Exemples : **Jenkins**, **GitLab CI**, **GitHub Actions**, **Azure DevOps Pipelines**.
Étapes Typiques d’un Pipeline CI
- Checkout : Récupération du code depuis le référentiel Git.
- Build : Compilation du code (si nécessaire).
- Test : Exécution des tests unitaires.
- Packaging : Création de l’artéfact (ex: une image Docker).
- Scan de Sécurité : Analyse statique du code ou scan de l’image (Security Check).
4 — Livraison et Déploiement Continus (CD)
La Livraison Continue (Continuous Delivery) et le Déploiement Continu (Continuous Deployment) prolongent la CI en automatisant le déploiement de l’artéfact validé.
Livraison Continue (CDel)
L’artéfact est prêt à être déployé à tout moment (après la CI et les tests), mais le déploiement final en production nécessite une **approbation manuelle** (par un administrateur ou un chef de projet).
Déploiement Continu (CDep)
Le code qui passe tous les tests (CI et tests d’intégration/système) est **automatiquement** déployé en production **sans intervention humaine**. C’est le niveau d’automatisation le plus élevé, nécessitant une confiance totale dans le pipeline.
Avantages de la CI/CD
- Déploiement plus rapide et plus fréquent.
- Réduction des erreurs humaines lors du déploiement.
- Possibilité de revenir en arrière (Rollback) rapidement en cas de problème.
5 — Stratégies de Déploiement Avancées
Pour minimiser l’impact des déploiements sur les utilisateurs finaux, des stratégies avancées sont utilisées, souvent facilitées par les outils CI/CD et l’orchestration (Kubernetes).
Rollback
Capacité à revenir à la version stable précédente en cas de défaillance du nouveau déploiement. Un déploiement fiable doit toujours être réversible.
Déploiement Blue/Green
- Principe : Maintenir deux environnements de production identiques : ‘Bleu’ (ancien, stable) et ‘Vert’ (nouveau, à déployer).
- Processus : Le trafic est basculé instantanément de ‘Bleu’ vers ‘Vert’ une fois que ‘Vert’ est validé. Si un problème survient, le trafic est instantanément rebasculé vers ‘Bleu’.
Déploiement Canary (Canari)
- Principe : Déployer la nouvelle version sur un petit sous-ensemble d’utilisateurs ou de serveurs (le « canari »).
- Processus : Si l’équipe de surveillance ne détecte aucun problème (erreurs, latence) après une période définie, la nouvelle version est progressivement étendue au reste de la flotte de serveurs.