Module 5Mettre en œuvre les outils de la chaîne DevOps
Chapitre 9 sur 11
Culture DevOps, CALMS, outils de la chaîne, intégration, livraison et déploiement continus, indicateurs DORA.
Objectifs
Avec ce chapitre, tu sauras…
Leçon 1
Le mouvement est né vers 2008-2009 (le terme vient des conférences DevOpsDays, lancées par Patrick Debois en Belgique en 2009). Il prolonge l'agilité : si l'agilité a permis de développer plus vite, les mises en production restaient lentes et manuelles ; le DevOps comble cet écart.
Tableau: Les avantages
| Avantage | Explication |
|---|---|
| collaboration | développeurs, exploitants, testeurs et sécurité travaillent ensemble sur un objectif commun |
| vitesse | des mises en production fréquentes : le délai de mise sur le marché (time to market) diminue grâce à l'automatisation des tests et des déploiements |
| fiabilité | des changements petits et testés automatiquement : moins de pannes, et des corrections plus rapides |
| agilité | l'organisation s'adapte plus facilement aux variations de la demande et aux changements |
| satisfaction des clients | des améliorations livrées en continu, à partir de leurs retours |
| innovation | plus de temps pour créer, moins pour les tâches répétitives |
| sécurité | le DevSecOps intègre les contrôles de sécurité dans la chaîne (analyse du code, des dépendances, des conteneurs) au lieu de les faire à la fin |
| Lettre | Pilier | Sens |
|---|---|---|
| C | Culture | collaboration, confiance, responsabilité partagée, droit à l'erreur (on cherche la cause, pas un coupable) |
| A | Automatisation (Automation) | automatiser tout ce qui est répétitif : construction, tests, déploiements, infrastructure |
| L | Lean | éliminer le gaspillage, livrer en petits lots, améliorer le flux en continu |
| M | Mesure | mesurer pour décider : fréquence des déploiements, pannes, temps de rétablissement, satisfaction |
Vidéo · À regarder
FRC'est quoi le DevOps ? Tout comprendre en deux minutes ! CI/CD, feedback et qualité !
YouTube (FR) · YouTube
Leçon 2
| Étape | Rôle | Outils courants |
|---|---|---|
| planifier | backlog, sprints, priorités | Jira, Trello, tableaux GitLab |
| coder | écrire le code, le versionner, le relire | Git, GitLab, GitHub, Bitbucket ; VS Code |
| construire (build) | installer les dépendances, compiler, empaqueter | Composer, npm, Maven ; Docker (images) |
| tester |
Leçon 3
| Intégration continue | Livraison continue | Déploiement continu | |
|---|---|---|---|
| construction et tests automatiques | oui | oui | oui |
| déploiement automatique en recette | — |
Leçon 4
| Indicateur | Question | Équipes très performantes |
|---|---|---|
| fréquence de déploiement | à quelle fréquence met-on en production ? | à la demande, plusieurs fois par jour |
| délai de mise en production des changements (lead time) | combien de temps entre un commit et sa mise en production ? | moins d'un jour |
| taux d'échec des changements | quelle part des déploiements provoque un incident ? | faible |
Leçon 5
| Méthodes agiles | DevOps | |
|---|---|---|
| rapproche | le client (et le métier) et les développeurs | les développeurs et l'exploitation |
| objectif | construire le bon produit, en s'adaptant au changement | livrer et faire fonctionner le produit de façon rapide et fiable |
| focus | dialogue permanent, adaptation, collaboration avec le client | automatisation, déploiement fiable et sécurisé, livraison accélérée |
1DevOps rapproche…
2Dans CALMS, le A signifie…
3En livraison continue, la mise en production est…
4Le déploiement continu…
5L'orchestrateur de conteneurs le plus utilisé est…
6Terraform sert à…
7Le temps entre un commit et sa mise en production est…
8Prometheus et Grafana servent à…
L'essentiel du chapitre
| Partage (Sharing) |
| partager les connaissances, les outils, les tableaux de bord et les retours d'expérience |
| tests automatisés, qualité, sécurité |
| PHPUnit, Jest, Cypress ; SonarQube |
| livrer (release) | produire une version prête à déployer (un artefact) | registres d'images et de paquets |
| déployer | installer la version sur les serveurs | GitLab CI/CD, Jenkins, GitHub Actions ; Ansible ; Kubernetes |
| exploiter | faire fonctionner l'infrastructure | Terraform (créer l'infrastructure par du code), Ansible, Puppet, Salt (configurer les serveurs) ; fournisseurs cloud (AWS, Azure, Google Cloud) |
| surveiller | métriques, journaux, alertes | Prometheus et Grafana (métriques et tableaux de bord) ; ELK (Elasticsearch, Logstash, Kibana) pour les journaux |
| Famille d'outils | À retenir |
|---|---|
| gestion du code source | Git (l'historique) et les plateformes GitHub, GitLab, Bitbucket (le partage et la collaboration) ; Subversion (SVN) est plus ancien |
| CI/CD | Jenkins (open source, très répandu, à configurer soi-même), GitLab CI/CD (intégré à GitLab), GitHub Actions, CircleCI, TeamCity, Bamboo, et les services des fournisseurs cloud |
| conteneurs | Docker crée et exécute des conteneurs : l'application avec tout ce dont elle a besoin, identique du poste du développeur jusqu'à la production |
| orchestration | Kubernetes (le plus utilisé), Docker Swarm : déployer et gérer des centaines de conteneurs, les répartir, les redémarrer, les mettre à l'échelle |
| infrastructure as code | Terraform décrit l'infrastructure (serveurs, réseaux, bases) dans des fichiers versionnés ; Ansible configure les serveurs |
| cloud | AWS (le leader), Microsoft Azure, Google Cloud ; répartition de charge (load balancing) entre plusieurs serveurs |
| surveillance et alertes | Prometheus, Grafana, ELK |
| gestion des secrets | Vault (HashiCorp), les secrets de Kubernetes, les variables protégées de GitLab |
| oui |
| mise en production | — | manuelle (un clic, décidée par l'équipe) | automatique |
Vidéo · À regarder
FRGitLab CI/CD expliqué simplement (Pour développeurs et DevOps)
chillotech · YouTube
| combien de temps pour rétablir le service après un incident ? |
| moins d'une heure |
| pratiques |
| sprints, backlog, revue, rétrospective |
| CI, tests continus, CD, infrastructure as code, surveillance |
| retours | du client, à chaque sprint | de la production (mesures, incidents), en continu |
| automatisation | peu imposée | au cœur de la pratique |
En octobre, l'équipe de Kitab a fait 40 mises en production ; 4 ont provoqué un incident, rétablis en 30 min, 2 h, 45 min et 25 min ; le délai moyen entre un commit et sa mise en production est de 6 heures. (1) Calcule la fréquence de déploiement par jour ouvré (22 jours), le taux d'échec des changements et le temps moyen de rétablissement. (2) Quel indicateur l'équipe doit-elle améliorer en priorité ?
Le cadre CALMS
Les piliers du DevOps se résument par l'acronyme CALMS :
Ce que tu vas voir (vidéo courte, entièrement sur ce sujet) : le DevOps en deux minutes : rapprocher développement et exploitation, automatiser avec l'intégration et le déploiement continus (CI/CD) et s'appuyer sur le feedback. C'est la définition de cette section.
┌──────── DEV ────────┐ ┌──────── OPS ────────┐
planifier ─► coder ─► construire ─► tester ─► livrer ─► déployer ─► exploiter ─► surveiller
▲ │
└──────────────────────── retours des utilisateurs et des mesures ◄────────────────┘L'intégration continue (Continuous Integration, CI) est une pratique où les développeurs intègrent très souvent (plusieurs fois par jour) leurs modifications dans le dépôt partagé ; chaque intégration déclenche automatiquement la construction et les tests. Objectifs : trouver et corriger les bugs plus tôt, améliorer la qualité, réduire le temps de validation des nouvelles versions.
Pourquoi ? Autrefois, chacun travaillait seul pendant des semaines et n'intégrait son code qu'à la fin : les fusions étaient longues et douloureuses (le « merge hell »), et les bugs restaient longtemps cachés. Avec la CI, les problèmes apparaissent quelques minutes après le push, quand la modification est encore fraîche dans la tête du développeur.
La livraison continue (Continuous Delivery) prolonge la CI : chaque modification qui passe les tests est automatiquement préparée pour la production (construite, testée plus largement : interface, charge, API, et déployée sur un environnement de recette). Il existe toujours une version prête à déployer ; la mise en production elle-même reste une décision humaine (un clic). Le déploiement continu (Continuous Deployment) va plus loin : chaque modification validée est mise en production automatiquement, sans intervention humaine.
Le programme de recherche DORA (DevOps Research and Assessment, Google) a identifié quatre indicateurs qui distinguent les équipes les plus performantes ; ils traduisent concrètement les promesses du DevOps :
Dessine la chaîne DevOps de Kitab, de la user story dans Jira jusqu'à la surveillance du site en production, en nommant l'outil utilisé à chaque étape (ceux des chapitres précédents et du chapitre 10). Indique ce qui est automatique et ce qui reste manuel, et si l'équipe fera de la livraison ou du déploiement continu, en justifiant.
Place chaque outil à la bonne étape de la boucle DevOps : Jira, Git, Composer, PHPUnit, SonarQube, Docker, GitLab CI/CD, Kubernetes, Terraform, Grafana, ELK, Vault.
Pour chaque équipe, dis quelle pratique elle applique : (1) chaque push lance les tests, mais les développeurs déploient à la main par FTP ; (2) chaque fusion dans main déploie automatiquement sur le serveur de recette, puis le Product Owner clique sur « Déployer en production » après la revue ; (3) chaque fusion dans main qui passe les tests est en production dix minutes plus tard, sans action humaine ; (4) l'équipe teste à la main une fois par mois avant de livrer.
Le déploiement continu inclut la livraison continue, qui inclut l'intégration continue. Beaucoup d'équipes préfèrent garder la main sur la dernière étape : elles pratiquent la livraison continue. On parle de CI/CD pour l'ensemble.
Ce que tu vas voir (7 min) : les chapitres « Présentation des pipelines », « Cycle de vie ». Le formateur présente les pipelines et leur cycle de vie : du commit à la construction, aux tests et au déploiement.
Les deux premiers mesurent la vitesse, les deux derniers la stabilité : le DevOps montre que les deux vont ensemble.
Les deux sont complémentaires : une équipe agile qui livre un incrément « terminé » tous les quinze jours a besoin d'une chaîne DevOps pour le mettre en production facilement ; une chaîne DevOps n'a de sens que si l'on sait quoi livrer.