Introduction cicd slides
Le Développement "Traditionnel" (Avant la CI/CD)¶
Dans un cycle classique (Cascade ou cycle en V long) : - Les développeurs travaillent sur des branches isolées pendant des semaines - Le code est intégré en une seule fois à la fin d'une phase - Les tests sont effectués manuellement par une équipe QA dédiée - Les déploiements sont rares, stressants et nécessitent souvent des nuits blanches
Les Problèmes Rencontrés¶
- Integration Hell (L'enfer de l'intégration) : Conflits massifs lors du merge des branches
- "Ça marche sur ma machine" : Écarts entre l'environnement de dev, de test et de prod
- Feedback tardif : Les bugs sont découverts des semaines après avoir été écrits (coût de correction exponentiel)
- Time-to-Market lent : Délai énorme entre une idée et sa mise en production
Qu'est-ce que l'Intégration Continue (CI) ?¶
L'Intégration Continue est une pratique de développement consistant à intégrer les modifications de code dans une branche partagée le plus souvent possible (quotidiennement au minimum).
Le processus : 1. Le développeur pousse son code sur le dépôt 2. Un serveur de CI (Runner) détecte le changement 3. Le code est automatiquement compilé et testé 4. Le développeur reçoit un feedback immédiat (Succès/Échec)
Pourquoi a-t-on besoin de la CI ?¶
- Détection précoce des bugs : Chaque commit est validé
- Qualité de code constante : Passage obligatoire des linters et tests unitaires
- Simplification des merges : En intégrant souvent, on évite les gros conflits
- Confiance : On sait à tout moment que la branche principale est stable
Qu'est-ce que le Déploiement Continu (CD) ?¶
Le CD (Continuous Delivery / Deployment) prend le relais de la CI pour automatiser la mise à disposition de l'application.
Il existe deux nuances importantes : - Continuous Delivery (Distribution Continue) : Le code est toujours prêt à être déployé, mais la mise en production nécessite une validation humaine (bouton) - Continuous Deployment (Déploiement Continu) : Chaque changement qui passe les tests est automatiquement déployé en production sans intervention humaine
Les Bénéfices de la CD¶
- Réduction des risques : On déploie de petits changements très souvent au lieu d'un énorme changement risqué
- Reproductibilité : Le processus de déploiement est scripté, plus d'erreur humaine manuelle
- Time-to-Market : Une fonctionnalité peut être en ligne quelques minutes après avoir été terminée
- Rollback facilité : Si un problème survient, revenir à la version précédente est aussi automatisé
Le Concept de "Pipeline"¶
Le pipeline est l'orchestration de toutes ces étapes. Il est généralement divisé en Stages :
- Build : Compilation, gestion des dépendances, création d'artefacts (images Docker)
- Test : Tests unitaires, d'intégration, couverture de code
- Security : Scan de vulnérabilités (SAST/DAST)
- Staging : Déploiement sur un environnement de pré-production
- Production : Déploiement final
Vers la Modernisation : Le Shift Left¶
La CI/CD permet d'appliquer la philosophie Shift Left : - On déplace les responsabilités (Sécurité, Tests, Performance) vers la gauche du cycle (au plus tôt) - DevSecOps : Intégrer la sécurité dès la CI (scans de conteneurs avec Trivy, tests DAST) - Plus on détecte tôt, moins c'est cher, plus c'est sûr
Récapitulatif : Pourquoi la CI/CD ?¶
- Vitesse : Accélérer le cycle de release
- Fiabilité : Automatiser pour éliminer l'erreur humaine
- Qualité : Tester tout, tout le temps
- Agilité : Réagir rapidement aux retours utilisateurs
C'est la colonne vertébrale de la culture DevOps
