Ramification et déploiement continu

Dans le Chapitre 4 : Suivre ce qui compte – KPI et tableaux de bord, nous avons exploré comment la visualisation du flux de travail et la définition des bons KPI nous ont aidés à identifier les goulots d'étranglement et à aligner nos équipes sur la création de valeur. Avec une meilleure visibilité sur notre pipeline DevOps, nous avons commencé à poser des questions plus approfondies – non seulement où se trouvaient les goulots d'étranglement, mais pourquoi ils se produisaient.

Dans le Chapitre 5, nous nous plongeons dans l'un des changements techniques et de processus les plus importants de notre parcours de transformation : l'affinage de notre stratégie de ramification 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 goulots d'étranglement où le travail s'accumule ont été un aspect clé de la réussite de notre transformation DevOps. Cette concentration sur le flux est au cœur de la manière dont nous avons appliqué le triangle DevOps – outils, architecture et personnes – pour parvenir à une livraison plus rapide et plus fiable.

À mesure que nous progressions dans l'amélioration de la testabilité avec une couverture croissante des tests unitaires et de l'automatisation des tests, nous avons constaté que la qualité du code s'améliorait, mais le goulot d'étranglement se situait toujours dans la phase de test Scrum. Malgré les progrès en matière d'automatisation des tests, le travail s'accumulait toujours, et le goulot d'étranglement est passé du développement aux tests au niveau du système. Les indicateurs clés de performance (KPI) montraient que le travail en cours par équipe pendant le développement diminuait, mais le code restait bloqué au point de transition vers les tests système. Ce retard nous a finalement empêchés d'atteindre un flux fluide.

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

L'analyse a révélé que la cause profonde de l'arriéré résidait dans notre stratégie de branchement. 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 se développait, les ingénieurs poussaient leurs modifications vers des branches de fonctionnalités distantes pour fusionner leur travail avec celui des autres. Cependant, ce code n'était pas fusionné assez fréquemment dans la branche principale.

Les pipelines CI/CD ont été configurés sur la branche principale, exécutant des tests automatisés et déployant vers le cloud, suivis de tests de régression. Cependant, comme les dernières modifications n'étaient pas régulièrement poussées vers la branche principale, les exécutions des pipelines fonctionnaient sur du code obsolète, ce qui les rendait redondantes et inefficaces.

La solution : 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 branchement. Bien qu'il y ait des avantages et des inconvénients à différentes stratégies de branchement, nous avons décidé de poursuivre avec la stratégie de branches de fonctionnalités, mais avec un ajustement clé : des branches de fonctionnalités à courte durée de vie qui sont fusionnées plus fréquemment avec la branche principale.

La stratégie de branches de fonctionnalités à courte durée de vie offre plusieurs avantages, le bénéfice le plus critique étant l'amélioration du flux et la résolution des goulots d'étranglement dans le cycle de développement. Les branches à courte durée de vie 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 vitesse 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. Selon notre expérience, avoir une équipe plateforme dédiée pour mettre en place et maintenir ces pipelines est l'approche recommandée, plutôt que de laisser chaque équipe Scrum y travailler individuellement. Bien que la responsabilité finale des pipelines de livraison continue doive incomber aux équipes Scrum, la tâche initiale de leur mise en place bénéficie grandement d'une équipe plateforme dédiée.

Équipe de plateforme : Réduire la charge cognitive et favoriser la concentration

Pour nous inspirer dans la structuration de notre équipe plateforme, nous nous sommes tournés vers Team Topologies de Matthew Skelton et Manuel Pais. Le livre souligne l'importance d'avoir une équipe plateforme dédiée 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 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 le livre :

« L'équipe plateforme est responsable de la construction et de la maintenance de la plateforme interne que les équipes alignées sur les flux utilisent pour réaliser leur travail. L'objectif de la plateforme est de réduire la charge cognitive pour 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 partagée et commune sur laquelle les équipes alignées sur les flux pouvaient compter. Cela nous 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 préoccupations liées à l'infrastructure.

Faire évoluer la plateforme pour l'amélioration continue

Avoir une équipe de plateforme ne consiste pas seulement à mettre en place les 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, s'assurant qu'il reste aligné avec les besoins des équipes et s'adapte à mesure que nous nous développons et grandissons. Cette évolution continue garantit que la plateforme reste fiable, évolutive et efficace, permettant à nos équipes de travailler au mieux de leurs capacités.

À suivre : Automatisation et retour d'information

Avec le branching rationalisé et les déploiements fluides, nous abordons la dernière étape de notre parcours DevOps : l'Automatisation et le Feedback. Dans le prochain et dernier chapitre, nous explorerons comment la boucle avec des informations automatisées et un retour rapide a transformé la façon dont nos équipes fonctionnent.

Restez à l'écoute !