Les premières étapes de notre transformation DevOps

Dans le deuxième chapitre de cette série - DevOps for the Win, nous explorons les étapes initiales cruciales d'un parcours de transformation DevOps. Les premières étapes d'un parcours de transformation sont souvent les plus difficiles. Dans le cadre de DevOps, l'identification des bonnes étapes initiales - celles qui sont à la fois impactantes et réalisables - est essentielle pour réaliser des progrès significatifs.

De nombreuses organisations commettent l'erreur de mettre en œuvre aveuglément les meilleures pratiques sans tenir compte des contraintes qui leur sont propres, ce qui conduit souvent à la frustration et à la lassitude de l'échec. Au lieu de cela, une approche plus stratégique est nécessaire - une approche qui identifie les goulets d'étranglement et les élimine systématiquement.

Comment identifier les premières étapes ?

Un principe puissant permettant de déterminer par où commencer provient d'une recherche publiée il y a 30 ans dans The Goal : A Process of Ongoing Improvement (Le but : un processus d'amélioration continue) par Eliyahu M. Goldratt. L'idée est simple : il s'agit d'identifier le principal goulet d'étranglement, c'est-à-dire le facteur limitant les performances du système. Dans notre cas, cela est apparu clairement lorsque nous avons constaté que le travail s'accumulait au sein de l'équipe de développement. Des tâches étaient commencées mais non achevées, et le carnet de commandes ne cessait de s'allonger.

Pour découvrir les causes profondes, nous avons organisé des sessions d'approfondissement avec les équipes de développement, les responsables techniques et les chefs de produit. Ces discussions ont permis de mettre en évidence plusieurs problèmes clés :

• Les équipes entreprenaient de nouvelles tâches avant d'avoir achevé celles qui existaient déjà.
• Il n'existait pas de critères clairs d'achèvement des tâches - ce que les développeurs considéraient comme "terminé" différait souvent des attentes des parties prenantes.
• Il n'y avait pas de mesures objectives de la qualité avant de marquer l'achèvement du travail, ce qui entraînait des défauts et des reprises.
• Les réaffectations fréquentes ont perturbé la stabilité de l'équipe, ce qui a entraîné des pertes d'efficacité.

Mise en place d'équipes stables

L'une des premières mesures correctives a consisté à restructurer les équipes pour les rendre plus cohérentes et plus ciblées. Au lieu de traiter des groupes d'individus comme des groupes de travail ad hoc, nous avons formé des équipes stables et durables avec une propriété clairement définie.

La mise en place de certaines équipes, comme les équipes de développement, a été relativement simple. En revanche, l'organisation des équipes de soutien, telles que les équipes d'infrastructure, de gestion de projet, de gestion de produit et d'analyse commerciale, s'est avérée plus délicate. Nous avons procédé à plusieurs itérations pour trouver les bonnes combinaisons.

En suivant le principe de la priorité à l'équipe décrit dans Team Topologies de Matthew Skelton et Manuel Pais, nous.. :

• Création de petites équipes autonomes (4 à 7 membres) pour favoriser une expertise approfondie du domaine et la responsabilisation.
• Élimination des dépendances entre les équipes en veillant à ce que les personnes soient entièrement affectées à une seule équipe.
• Il a amélioré la structure des équipes, en particulier pour les fonctions d'appui telles que l'infrastructure et la gestion des produits, afin d'optimiser le flux de travail.

Exploiter les outils pour la visibilité et la gestion

Une fois les équipes structurées, nous sommes passés à Azure DevOps pour la gestion du carnet de commandes et du travail. Une plateforme unifiée a permis :

• Une meilleure visibilité du travail afin que les équipes puissent suivre les progrès de manière transparente.
• Définitions normalisées de la notion de "fait" afin d'harmoniser les attentes entre les différentes fonctions.
• Amélioration de la gestion du carnet de commandes, réduction des dérives et des conflits de priorité.

Mise en œuvre de mesures de qualité objectives

Pour résoudre le problème du manque de clarté des mesures de qualité avant de marquer les tâches comme "prêtes à être testées", nous avons intégré un outil d'analyse statique du code, qui fournit des informations objectives sur.. :

• Couverture du code
• Vulnérabilités en matière de sécurité
• Senteurs de code

Nous avons également amélioré notre définition du terme "terminé" pour faire des contrôles de qualité une étape obligatoire avant de marquer l'achèvement des travaux.

Gestion des travaux en cours (WIP)

L'un des changements les plus marquants a été le suivi et la limitation des travaux en cours (WIP). Un niveau élevé de WIP indiquait des goulots d'étranglement, ce qui us a permis us traiter de manière proactive les domaines dans lesquels le travail était au point mort.

Cette approche systématique, ancrée dans les topologies The Goal et Team, a jeté les bases d'une amélioration continue, d'une réduction des dépendances et d'une meilleure responsabilisation.

Au cours de notre transformation DevOps, l'une des conclusions les plus importantes a été qu'après les premières améliorations, le principal obstacle au flux s'est déplacé vers la conception logicielle, plus précisément vers la testabilité de notre code. Après avoir résolu les premiers goulots d'étranglement en améliorant la configuration des équipes, en définissant une « définition du terminé » et en mettant en œuvre l'analyse du code, nous avons remarqué que le travail s'accumulait pendant la phase de test. Le code développé par les équipes Scrum était souvent en attente d'être testé par les QA au sein des mêmes équipes Scrum.

S'attaquer au prochain goulot d'étranglement : Les lacunes en matière de tests

Une fois les goulets d'étranglement initiaux résolus, une nouvelle contrainte est apparue : les retards dans les tests. Alors que les tâches de développement progressaient efficacement, les tests devenaient un obstacle, empêchant des mises en production plus rapides. Après enquête, nous avons identifié les principaux problèmes qui ralentissaient le processus :

• Dépendance à l'égard des tests manuels : La plupart des tests étaient exécutés manuellement, ce qui entraînait des boucles de rétroaction lentes et une détection tardive des défauts.
• Dépendance de l'interface utilisateur lors des tests : Les composants de l'interface utilisateur étant généralement terminés en dernier, les tests ne pouvaient commencer que tard dans le cycle de développement.
• Manque d'automatisation proactive : Les tests automatisés, tels que les tests d'interface utilisateur basés sur Selenium, n'ont été rédigés qu'après les tests manuels, ce qui a limité leur efficacité lors des premières étapes de la validation.

Passer à des approches fondées sur les tests

Pour éliminer ce goulot d'étranglement, nous avons donné la priorité aux tests unitaires et aux tests d'API par rapport aux tests d'interface utilisateur. Cette évolution a nécessité des changements fondamentaux dans l'état d'esprit des développeurs et dans la conception des logiciels :

Amélioration des tests de l'API

Pour rendre les tests d'API efficaces :

1. APIs bien définies: APIs être simples, bien documentées et disponibles dès le début de la phase de développement afin que les testeurs puissent créer des cas de test de manière proactive.
2. Éviter que la base de données soit le point d'intégration:
   • L'utilisation de bases de données comme point d'intégration entre les équipes a créé des dépendances qui ont ralenti les tests.
   • La création de cas de test nécessitait la mise en place de bases de données contenant des données complexes, ce qui augmentait le temps de mise en place et limitait la possibilité de tester plusieurs scénarios.
   • En passant à une intégration basée sur des API (principalement REST sur HTTP et, plus récemment, GraphQL), nous avons considérablement réduit les retards et les complexités causés par les dépendances de la base de données.

Ce changement a permis d'accélérer l'automatisation des cas de test pour APIs, démontrant ainsi que le fait de privilégier les conceptions API-first améliorait à la fois la testabilité et l'efficacité.

Renforcer les pratiques de tests unitaires

Les tests unitaires ont posé un plus grand défi :

• Progrès rapides, puis théâtre de la couverture: Au départ, nous avons atteint des niveaux élevés de couverture du code, mais l'examen du code a révélé que de nombreux tests unitaires étaient superficiels, rédigés uniquement pour atteindre les objectifs de couverture. Ces tests ne permettaient pas de vérifier des fonctionnalités significatives, de couvrir des scénarios d'échec ou de valider des cas limites.
• Changer les mentalités: Les développeurs devaient comprendre la valeur des tests unitaires, non seulement pour améliorer la qualité du code, mais aussi pour accélérer le développement en détectant rapidement les problèmes.

Les défis de l'écriture d'un code testable

Le principal obstacle à l'efficacité des tests unitaires était le manque de testabilité de la base de code elle-même. Les principaux problèmes étaient les suivants

• Grandes fonctions monolithiques.
• Composants étroitement liés.
• Mauvaise séparation des préoccupations.
• Abstraction insuffisante.

Il était donc difficile d'isoler et de tester efficacement les unités individuelles. Pour y remédier, nous avons

1. Lignes directrices fournies: Nous avons partagé les meilleures pratiques sur :
   • Sélection des fonctions pour les tests unitaires.
   • Refonte du code pour améliorer la testabilité.
   • Concevoir et utiliser des mocks pour faciliter les tests.
2. L'accent a été mis sur les améliorations progressives: Les développeurs ont été encouragés à apporter de petites modifications significatives pour améliorer la testabilité au fil du temps.

Progrès, défis et avenir

Pour les produits existants, l'amélioration de la testabilité est restée un processus lent en raison des contraintes architecturales. Cependant, ces actions ne visaient pas seulement à améliorer le code actuel, elles constituaient un investissement pour l'avenir:

• Les développeurs ont pris de meilleures habitudes, intégrant la testabilité dans les nouvelles bases de code.
• Les équipes sont devenues plus autonomes, réduisant ainsi leur dépendance vis-à-vis QA externes QA
• L'organisation a évité de répéter les erreurs du passé, ce qui a permis de faciliter la maintenance et l'évolution des futurs produits.

Ce qu'il faut en retenir ? DevOps ne consiste pas à mettre en œuvre des outils ou des listes de contrôle. Il s'agit d'améliorer en permanence le flux de travail, une contrainte à la fois.

Dans le prochain chapitre de cette série, nous explorerons la "conception pour la testabilité". Nous verrons comment l'amélioration de la conception des logiciels peut éliminer les contraintes liées aux tests, permettant ainsi des boucles de rétroaction plus rapides et une meilleure qualité logicielle - d'abord dans les structures d'équipe, puis dans la gestion des flux de travail, et enfin dans la testabilité - nous jetterons les bases d'une transformation DevOps durable.