La boucle DevOps
Livrer est une boucle, pas une ligne droite : ce qui se passe en production alimente directement ce que l'équipe planifie ensuite.
Feedback continu
Planifier
Les éléments de travail sont priorisés selon les objectifs métier et ce que la production et les utilisateurs vous apprennent.
Principes fondamentaux du DevOps
Intégration continue & déploiement continu
Automatisez le processus de build, test et déploiement. Intégrez fréquemment les modifications de code. Déployez automatiquement en production après le passage des tests automatisés. Réduisez les erreurs manuelles et accélérez les boucles de feedback.
Tout automatiser
Automatisez les tâches répétitives : builds, tests, déploiements, provisionnement d'infrastructure, scans de sécurité. Libérez du temps humain pour le travail à haute valeur ajoutée. Réduisez les erreurs des processus manuels. Assurez la cohérence entre les environnements.
Collaboration & culture
Cassez les silos entre les équipes. Responsabilité partagée pour la qualité et la fiabilité. Post-mortems sans blâme. Apprentissage et amélioration continus. Expérimentation et innovation encouragées.
Mesurer la performance de livraison
Le programme de recherche DORA a popularisé des indicateurs qui équilibrent vitesse et stabilité. Nous les utilisons pour ouvrir la discussion et suivre les progrès, pas pour classer les équipes.
Fréquence de déploiement
La fréquence à laquelle les modifications arrivent en production. Des livraisons petites et fréquentes sont plus faciles à tester, à comprendre et à annuler.
Délai de mise en production
Le temps entre un commit et son exécution en production. Un délai long révèle généralement des étapes manuelles, des transferts ou des files d'attente.
Taux d'échec des modifications
La part des déploiements qui provoquent un problème en production et nécessitent un correctif, un hotfix ou un retour arrière.
Délai de rétablissement après un déploiement en échec
La rapidité avec laquelle le service revient à la normale après une modification ratée ou un incident.
Vitesse et stabilité ne s'opposent pas : les équipes qui déploient souvent de petites modifications ont en général des incidents moins nombreux et plus courts, car chaque modification est plus facile à tester et à annuler.
Les habitudes que nous aidons les équipes à adopter
Les outils rendent le DevOps possible ; les habitudes le rendent durable.
Travailler par petits lots. Une modification qui se relit en quelques minutes peut être fusionnée et déployée avec beaucoup moins de risque.
Garder la branche principale livrable en permanence, avec des branches de courte durée et des pull requests.
S'accorder sur une définition de « terminé » qui inclut tests, documentation et monitoring, et pas seulement du code qui fonctionne.
Mener après chaque incident des revues sans recherche de coupable, qui cherchent les causes dans le système et le processus, pas chez la personne.
Rendre le travail visible sur un seul tableau partagé par le développement, l'exploitation et le métier.
Réserver de la capacité pour l'amélioration : tests instables, pipelines lents et dette technique.