Branchement et déploiement continu

En Chapitre 4 : Suivre ce qui compte - ICP et tableaux de bordnous avons exploré comment la visualisation du flux de travail et la définition des bons KPI us ont aidés à repérer les goulots d'étranglement et à aligner nos équipes sur la création de valeur. Grâce à une meilleure visibilité de notre pipeline DevOps, nous avons commencé à poser des questions plus approfondies, non seulement sur les goulets d'étranglement, mais aussi sur les raisons de leur apparition.

Au chapitre 5, nous nous penchons sur l'un des changements techniques et de processus les plus importants de notre parcours de transformation : l'affinement de notre stratégie de branchement et l'activation du déploiement continu. Ces changements ont été essentiels pour résoudre les retards persistants entre le développement et la production.

Identifier le nouveau goulot d'étranglement

L'analyse du flux de travail et l'identification des goulets d'étranglement où le travail s'accumule ont été des aspects clés de notre transformation DevOps. Cette attention portée au flux est au cœur de la manière dont nous avons appliqué le triangle DevOps - outils, architecture et personnel - pour parvenir à une livraison plus rapide et plus fiable.

Au fur et à mesure que nous améliorions la testabilité en augmentant 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 goulot d'étranglement se situait toujours au niveau de la phase de test scrum. Malgré les progrès réalisés en matière d'automatisation des tests, le travail continuait à s'accumuler et le goulot d'étranglement s'est déplacé du développement vers les tests au niveau du système. Les indicateurs clés de performance (ICP) ont montré que le travail en cours par équipe pendant le développement diminuait, mais le code restait bloqué au point de transition vers les tests du système. Ce retard us finalement empêchés d'obtenir un flux régulier.

La cause première : Stratégie de ramification et fusions retardées

L'analyse a révélé que la cause première de l'arriéré se trouvait dans notre stratégie de ramification. Les développeurs et les testeurs créaient des branches de fonctionnalités à partir de la branche principale lorsqu'ils lançaient de nouvelles fonctionnalités. Au fur et à mesure que le code se développait, les ingénieurs transféraient leurs modifications vers des branches de fonctionnalités distantes afin de fusionner leur travail avec d'autres. Cependant, ce code n'était pas fusionné dans la branche principale assez fréquemment.

Les pipelines CI/CD ont été mis en place sur la branche principale, exécutant des tests automatisés et déployant sur le cloud, suivis par des tests de régression. Cependant, comme les dernières modifications n'étaient pas poussé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 : les branches de fonctionnalités à courte durée de vie

Pour résoudre ce problème, nous avons réalisé qu'il était nécessaire d'affiner la stratégie de ramification. Bien qu'il y ait des avantages et des inconvénients aux différentes stratégies de ramification, nous avons décidé de continuer avec la stratégie des branches de fonctionnalités, mais avec un ajustement clé : des branches de fonctionnalités de courte durée qui sont fusionnées plus fréquemment avec la branche principale.

La stratégie des branches de fonctionnalités à courte durée de vie offre plusieurs avantages, le plus important étant d'améliorer le flux et de s'attaquer aux goulets d'étranglement du cycle de développement. Des branches à durée de vie plus courte garantissent que les fusions de code sont plus faciles, plus rapides et moins sujettes aux 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

La mise en place de pipelines de déploiement continu robustes est une tâche complexe qui nécessite une approche ciblée et incrémentale. D'après notre expérience, il est recommandé d'avoir une équipe dédiée à la plateforme pour mettre en place et maintenir ces pipelines, plutôt que de demander à chaque équipe de scrum d'y travailler individuellement. Bien que la propriété finale des pipelines de livraison continue doive revenir aux équipes de mêlée, la tâche initiale de leur mise en place bénéficie grandement d'une équipe dédiée à la plateforme.

L'équipe de la plate-forme : Réduire la charge cognitive et favoriser la concentration

Pour nous inspirer dans la structuration de notre équipe de plate-forme, nous nous sommes tournés vers Team Topologies de Matthew Skelton et Manuel Pais. Ce livre souligne l'importance d'avoir une équipe dédiée à la plateforme qui est responsable de la mise en place et de la gestion de l'infrastructure -dans notre cas, les pipelines de CD. Cette structure permet aux équipes de scrum de se concentrer sur le développement des fonctionnalités, tout en bénéficiant d'une configuration stable et standardisée des pipelines.

Comme l'indique le livre :

"L'équipe chargée de la plateforme est responsable de la construction et de la maintenance de la plateforme interne que les équipes alignées sur les flux utilisent pour effectuer leur travail. L'objectif de la plateforme est de réduire la charge cognitive des équipes alignées sur les flux, 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 les flux peuvent compter. Cela us a permis de réduire la charge cognitive des équipes de développement, leur permettant de se concentrer sur la création de valeur plutôt que sur les problèmes d'infrastructure.

Faire évoluer la plateforme pour une amélioration continue

Avoir une équipe plateforme ne consiste pas seulement à mettre en place les pipelines, mais aussi à faire évoluer l'infrastructure et les outils partagés au fil du temps. Une équipe dédiée à la plateforme est la mieux placée pour apporter des améliorations progressives au pipeline de livraison continue, en s'assurant qu'il reste aligné sur les besoins des équipes et qu'il s'adapte au fur et à mesure de notre évolution et de notre croissance. Cette évolution continue garantit que la plateforme reste fiable, évolutive et efficace, ce qui permet ànos équipes de travailler au mieux de leurs capacités.

À suivre : Automatisation et retour d'information

Une fois les branchements rationalisés et les déploiements fluides, nous nous tournons vers la dernière frontière de notre voyage DevOps : l 'automatisation et le retour d'information. Dans le prochain et dernier chapitre, nous verrons comment le fait de boucler la boucle avec des informations automatisées et un retour d'information rapide a transformé le mode de fonctionnement de nos équipes.

Restez à l'écoute !