3 min de lecture
Dans le Chapitre 4 : Suivre l'essentiel – Indicateurs clés de performance et tableaux de bord, nous avons examiné comment la visualisation du flux de travail et la définition des bons indicateurs clés de performance nous ont aidés à repérer les goulets d'étranglement et à aligner nos équipes autour de la création de valeur. Grâce à une meilleure visibilité sur notre pipeline DevOps, nous avons commencé à nous poser des questions plus approfondies, non seulement sur l'emplacement des goulets d'étranglement, mais aussi sur les raisons de leur apparition.
Dans le Chapitre 5, nous abordons l'un des changements techniques et méthodologiques les plus importants de notre parcours de transformation : l'amélioration de notre stratégie de création de branches et l'optimisation du déploiement continu. Ces changements ont joué un rôle déterminant dans la résolution des retards persistants entre le développement et la production.
Identification du nouveau goulet d'étranglement
L'analyse du flux de travail et l'identification des goulets d'étranglement où le travail s'accumule ont constitué un aspect clé de la réussite de notre transformation DevOps. Cet accent mis sur le flux est au cœur de la manière dont nous avons appliqué le triangle DevOps — outils, architecture et personnes — afin d'atteindre une livraison plus rapide et plus fiable.
À mesure que nous progressions dans l'amélioration de la testabilité avec l'augmentation de la couverture des tests unitaires et de l'automatisation des tests, nous avons constaté que la qualité du code s'améliorait, mais que le goulet d'étranglement persistait dans la phase de test Scrum. Malgré les progrès réalisés en matière d'automatisation des tests, le travail continuait de s'accumuler et le goulet d'étranglement s'est déplacé du développement vers les tests au niveau du système. Les indicateurs clés de performance (KPI) ont montré que le travail en cours par équipe pendant le développement diminuait, mais que le code restait bloqué au point de transition vers les tests système. Ce retard nous a finalement empêchés d'obtenir un flux fluide.
La cause profonde : stratégie de création de branches et fusions tardives
L'analyse a révélé que la cause profonde de l'accumulation résidait dans notre stratégie de création de branches. Les développeurs et les testeurs créaient des branches de fonctionnalités à partir de la branche principale lors du démarrage de nouvelles fonctionnalités. Au fur et à mesure que le code évoluait, les ingénieurs envoyaient leurs modifications vers des branches de fonctionnalités distantes afin de fusionner leur travail avec celui des autres. Cependant, ce code n'était pas réintégré dans la branche principale assez fréquemment.
Les pipelines CI/CD étaient configurés sur la branche principale, exécutant des tests automatisés et procédant au déploiement sur le cloud, suivis de tests de non-régression. Cependant, étant donné que les dernières modifications n'étaient pas envoyées régulièrement vers la branche principale, les exécutions du pipeline s'effectuaient sur du code obsolète, ce qui les rendait redondantes et inefficaces.
La solution : des branches de fonctionnalités à courte durée de vie
Pour résoudre ce problème, nous avons compris qu'il était nécessaire d'affiner la stratégie de création de branches. Bien que chaque stratégie de création de branches présente des avantages et des inconvénients, nous avons décidé de conserver la stratégie de branches de fonctionnalités, mais en y apportant un ajustement clé : des branches de fonctionnalités à courte durée de vie qui sont fusionnées plus fréquemment dans la branche principale.
La stratégie de branches de fonctionnalités à courte durée de vie offre plusieurs avantages, dont le plus crucial est l'amélioration du flux et la résolution des goulets d'étranglement dans le cycle de développement. Des branches plus éphémères garantissent que les fusions de code sont plus simples, plus rapides et comportent moins d'erreurs. Cette approche permet également un retour d'information plus rapide, ce qui améliore la qualité globale et la rapidité du processus de développement.
Déploiement continu : le défi du pipeline
Mettre en place des pipelines de déploiement continu robustes est une tâche complexe qui nécessite une approche ciblée et progressive. D'après notre expérience, il est recommandé de confier la mise en place et la maintenance de ces pipelines à une équipe dédiée à la plateforme, plutôt que de demander à chaque équipe Scrum de travailler dessus individuellement. Bien que la responsabilité finale des pipelines de livraison continue doive incomber aux équipes Scrum, la tâche initiale de leur configuration bénéficie grandement de l'intervention d'une équipe dédiée.
Équipe de plateforme : réduire la charge mentale et favoriser la concentration
Pour structurer notre équipe de plateforme, nous nous sommes inspirés de l'ouvrage Team Topologies de Matthew Skelton et Manuel Pais. Ce livre souligne l'importance d'avoir une équipe de plateforme dédiée chargée de mettre en place et de gérer l'infrastructure, en l'occurrence nos pipelines de CD. Cette structure permet aux équipes Scrum de se concentrer sur le développement de fonctionnalités tout en bénéficiant d'une configuration de pipeline stable et standardisée.
Comme l'indique l'ouvrage :
« L'équipe de plateforme est chargée de concevoir et de maintenir la plateforme interne que les équipes alignées sur un flux utilisent pour effectuer leur travail. Le rôle de la plateforme est de réduire la charge mentale de ces équipes afin qu'elles puissent se concentrer sur la création de valeur. »
En centralisant la responsabilité des pipelines, nous avons pu créer une plateforme commune et partagée sur laquelle les équipes alignées sur le flux pouvaient compter. Cela nous a permis de réduire la charge mentale des équipes de développement, leur permettant ainsi de se concentrer sur la création de valeur plutôt que sur la gestion de l'infrastructure.
Faire évoluer la plateforme pour une amélioration continue
Disposer d'une équipe de plateforme ne se résume pas à configurer des pipelines ; il s'agit de faire évoluer l'infrastructure partagée et les outils au fil du temps. Une équipe de plateforme dédiée est la mieux placée pour apporter des améliorations progressives au pipeline de livraison continue, en veillant à ce qu'il reste adapté aux besoins des équipes et qu'il s'adapte à notre croissance. Cette évolution constante garantit que la plateforme demeure fiable, évolutive et efficace, permettant à nos équipes de donner le meilleur d'elles-mêmes.
Prochaine étape : automatisation et retours d'information
Maintenant que la gestion des branches est rationalisée et que les déploiements sont fluides, nous abordons la dernière étape de notre parcours DevOps : l'automatisation et les retours d'information. Dans ce prochain et dernier chapitre, nous verrons comment le bouclage de la boucle grâce à des analyses automatisées et à des retours rapides a transformé le mode de fonctionnement de nos équipes.
Restez à l'écoute !
