Aujourd'hui, nous observons comment le modèle de développement de la cascade se meurt progressivement dans le monde entier. Elle n'est pas aimée pour sa lourdeur et sa mauvaise réaction au changement. Cela affecte directement la pertinence du produit et augmente le TTM (time-to-market), entraînant des coûts supplémentaires. Les développeurs reconstruisent sur des rails agiles, et nous ne faisons pas exception.
La méthodologie agile a été créée à l'origine pour les petites équipes qui fabriquent un produit clé en main de bout en bout et sont elles-mêmes responsables de sa qualité. Mais que se passe-t-il si vous développez des systèmes bancaires hautement critiques sur lesquels travaillent des dizaines d'équipes agiles? Comment obtenir la confiance dans le produit qui donne un test long et complet comme en cascade? Dans cet article, nous partagerons notre solution à ce problème.
Tout le monde résout le problème de différentes manières, mais il s'agit généralement de tester l'automatisation. Des tests sur les stubs sont en cours d'élaboration, les règles générales de constitution des backlogs des équipes voisines sont des cadres d'interaction inter-équipes comme SAFe. Par conséquent, en raison de la synchronisation du backlog, les équipes de produits associés peuvent écrire et effectuer des tests ensemble, y compris des tests d'intégration. Nous avons de tels cadres.
Mais maintenant, nous nous mettons à la place du propriétaire d'un système bancaire complexe et hautement critique. Qui, après tout, est responsable de la qualité de l'ensemble de ce produit s'ils sont directement impliqués dans des dizaines d'équipes agiles responsables à part entière? Vous devez être sûr que rien n'échouera en production. Introduire des tests supplémentaires? Salut, cascade et au revoir, TTM.
Il n'y a pas de solution parfaite. Dans cette situation, nous aurons toujours un conflit entre les principes de méthodologie et la fiabilité garantie du résultat. C'est le compromis que nous avons trouvé.
Portes de qualité
Si la spécificité de votre produit suppose qu'il n'est pas complètement isolé des autres, alors aux points de contact, vous devez respecter une seule règle - respecter le niveau de qualité minimum. Le code doit être couvert par des tests unitaires, ne doit pas contenir de défauts critiques de sécurité de l'information, les distributions doivent subir des tests de fumée lors de leur livraison. Pas d'étain, mais les exigences sont obligatoires pour tout le monde. Leur implémentation est une passe aux tests généraux.
Ainsi, en général,
la pratique
Quality Gates ressemble à un ensemble de vérifications automatisées intégrées au pipeline de développement de chaque système. En fait, il reflète la tendance aux tests shift-shift, dont on parle désormais souvent dans le cadre des devops.
Nous nous sommes mis d'accord avec toutes les équipes sur un certain nombre de contrôles, portes de qualité, qu'ils doivent franchir lors du passage des étapes du cycle de vie.
Codage
Avant de construire le code, vous avez besoin d'une analyse statique obligatoire, en vérifiant la conformité du code avec les normes d'un langage de programmation particulier. Ainsi que l'exhaustivité de la couverture avec des tests unitaires. Il existe différents outils pour cela. Par exemple, nous aimons SonarQube. Après avoir franchi ce seuil de qualité, les équipes peuvent être sûres qu'elles n'ont pas violé un certain nombre de règles de base à un stade précoce. Par exemple, une duplication importante a été évitée, ce qui augmente la complexité du code et la probabilité de problèmes.
Le deuxième test avant assemblage est un contrôle IS. Il existe des pratiques généralement acceptées pour identifier les problèmes de SI dans le code et les outils qui peuvent scanner le code et identifier les endroits dangereux. Par exemple, une variable incorrectement déclarée peut entraîner des problèmes de production. Ici, nous avons convenu de ne pas autoriser tout ce qui peut être révélé au stade de la rédaction du code, aux pentests et aux contrôles plus complexes.
Construction de distribution
Lors de l'assemblage du kit de distribution, nous vérifions toujours le résultat: que l'assemblage s'est déroulé correctement, que tous les services ont démarré et fonctionnent comme il se doit, que le kit de distribution peut être installé sur l'environnement souhaité et qu'il fonctionnera. Un tel test de vérification buiild élimine les malentendus potentiels entre le testeur et le développeur. Dans la pratique de la cascade, il était habituel que le développeur finisse le travail, remette la distribution aux testeurs et, une fois installé sur le stand, il s'est avéré que l'assemblage n'avait même pas commencé. Ensuite, tout le cycle a été rompu, le développement a été étiré et rien de bon ne s'est produit.
Notre interaction d'intégration est très compliquée. Il est important de ne pas casser le stand où les autres équipes peuvent être contrôlées. Nous pouvons le faire en raison d'une mauvaise distribution, et les voisins du stand le sauront avant nous - nous allons simplement perturber tout le processus de travail pour eux. De plus, cela peut ruiner les données de test. Et leur préparation coûte aussi de l'argent et prend beaucoup de temps. Surtout quand il s'agit de données utilisateur anonymisées.
Tests de fumée
Comme le kit de distribution est installé sur chaque banc d'essai, il passe une série de tests de fumée simples. Au banc d'essai du système, la fonctionnalité de la distribution est testée. De plus, le kit de distribution est placé sur le stand de test d'intégration, où les interactions d'intégration sont testées. Il exécute également une série de tests de fumée. Si la distribution ne les réussit pas, il ne peut pas passer à l'étape suivante.
En utilisant ces portes de qualité, nous obtenons une première idée de la qualité de la distribution. Si les tests de fumée ont réussi, l'équipe commence les tests. Si le kit de distribution n'a pas réussi les tests de fumée à ce stade, il ne réussira probablement pas les tests manuels. Ici, nous ne l'attribuons que si l'assemblage est potentiellement prêt à passer au bal.
Des portes de qualité comme cadre
Nous nous efforçons de faire en sorte que les portes de qualité deviennent un cadre complet pour gérer la qualité de développement d'un grand nombre de produits en agile. Si une équipe ne parvient pas à franchir les portes de qualité, même obligatoires, c'est un signal qu'il y a des problèmes qui doivent être discutés et résolus. D'un autre côté, si une équipe a déjà maîtrisé les portes de qualité de base et les a intégrées dans les procédures internes, cela peut aller plus loin et inclure des portes de qualité supplémentaires.
À l'avenir, nous prévoyons de déployer de nouveaux ensembles de portes de qualité obligatoires. Et aussi en option, pour que chaque équipe avec un niveau de maturité suffisant puisse choisir ce dont elle a besoin. Par exemple, si vous souhaitez déterminer la stabilité du package de distribution sur les sites de test d'intégration, l'équipe prendra seul des portes de qualité. Si vous devez vous assurer qu'un assemblage complexe et multi-composants n'entrave pas le déploiement, d'autres le prendront. Quelqu'un a un penchant pour la sécurité à l'avant, quelqu'un pour les contrôles des tests de charge, la disponibilité des stands, la réponse, quelqu'un avant l'intégration ou la vérification de certaines données. Chaque équipe pourra trouver des portes de qualité pour son cas.
Il est important de noter que les portes de qualité ne sont pas un substitut aux tests, mais
un outil de contrôle principal . Personne n'annule les tests. La tâche principale ici est de minimiser le plus tôt possible les dommages causés aux autres équipes par la mauvaise qualité des produits.
Un exemple de pipeline tiers qui comprend des portes de qualitéRésultats de la mise en place de portes de qualité
Tout d'abord, nous avons augmenté la stabilité du cycle de production. Un changement dans l'action, nous pouvons immédiatement détecter les bogues de fonctionnalité critiques. Moins de temps est consacré aux différentes itérations de tests; les défauts plus tôt sont détectés, donc leur élimination est moins coûteuse.
Le délai de livraison a diminué - le temps écoulé entre le début du codage des fonctionnalités et sa mise en œuvre en production. La stabilité de la phase d'ingénierie de TTM a augmenté du fait que nous avons réduit les temps d'arrêt dans le processus de livraison du kit de distribution à l'environnement industriel. Nous passons le même temps pour les tests, mais nous n'avons aucun temps d'arrêt en raison de l'effondrement du stand et de la nécessité d'attendre que la distribution soit reconstruite.
Le temps disponible pour tester les environnements a augmenté. Avant, vous pouviez mettre un assemblage dessus et l'oublier pendant une semaine. En attendant, les équipes liées n'ont pas pu être testées dans cet environnement, car votre build est défectueux et vous ne le saurez qu'après une semaine. Maintenant, lorsque vous posez l'assemblage au sol, vous le testez vous-même pour les problèmes les plus courants, si nécessaire, reculez, terminez, renvoyez-le. Et la chance de ne pas arrêter personne devient beaucoup plus élevée. L'introduction de portes de qualité entraînera également une réduction des coûts de restauration des stands et de recyclage des données des tests.
Votre opinion
Comme nous l'avons dit au début, la contradiction entre les principes de développement agile et intégré ne peut pas être tranchée comme un nœud gordien. On ne peut que s’efforcer d’apporter le moins de problèmes possible. Dans notre cas, la pratique de portes de qualité aide, mais, bien sûr, nous ne la considérons pas comme idéale. Comment résolvez-vous ce problème? Il serait très intéressant pour nous de discuter de cette question.
Nikolay Vorobyov-Sarmatov, Sberbank-Technology, Sberworks
Merci à Mikhail Bizhan pour son aide dans la préparation de l'article!