La correction de bogues est une partie fastidieuse mais obligatoire de tout développement, et tout le monde ne veut pas le faire. Comment transformer la correction de bugs en quelque chose d'excitant? Organisez un concours! Dans cet article, nous parlerons en détail de notre "marathon de correction de bogues" de 24 heures - de la préparation préliminaire au ratissage des derniers commits après l'attribution des gagnants.
Infecté par l'idée
L'échelle de développement de notre application Sberbank Online a considérablement augmenté au cours de la dernière année. Parallèlement à cela, de petits bogues ont commencé à s'accumuler, qui ne se reflétaient en aucune façon sur les mesures clés. Mais nous avons compris qu'il s'agit d'une bombe à retardement et qu'il faut en faire quelque chose.
Nous avons été inspirés par la façon dont nos collègues
Avito résolvent ces problèmes, et nous avons décidé d'organiser une attaque massive contre les bogues au format bagaton - en tenant compte de notre structure de développement, de notre culture et des spécificités du flux.
Il fallait tout arranger pour que les gars eux-mêmes veuillent participer à un bagaton et prouver leur sang-froid sans directives d'en haut. Pour ce faire, la compétition doit avoir une ambiance cool. Nous avons décidé de proposer un style spécial, quelque chose de reconnaissable sur les bugs. Les bogues sont des bogues. Qui détruit les insectes dans la vie ordinaire? Désinsectiseurs - gars en combinaison de protection chimique jaune. Où ont-ils été allumés ces dernières années? Dans une série populaire sur un professeur de chimie. Il y a une base, on termine avec des activités. Ils ont organisé un tournoi de jeux vidéo, un quiz avec des prix, des nominations individuelles sympas ... et bien sûr, beaucoup de plats délicieux. Mais l'essentiel, quoi qu'on en dise, c'est la compétition d'élimination des bogues. Cela a été rappelé un tableau de bord avec une interface web, montrant la progression des équipes, leurs positions actuelles, le nombre de points, etc. Nous avons discuté de tout avec les chefs d'équipe - ils ont approuvé nos plans.
Android vs iOS - si malhonnête
Tout d'abord, nous voulions pousser les développeurs Android de Sberbank Online avec leurs collègues iOS, pour jouer sur la rivalité des plateformes. Mais dans le processus, les organisations ont réalisé que ce n'était pas la meilleure solution, car techniquement les plates-formes fonctionnent dans des conditions inégales. Il se trouve que sur iOS, les builds sont plus rapides et les autotests sont exécutés.
Ensuite, nous avons changé le format et formé des équipes mixtes: cinq développeurs Android et iOS chacun. Auparavant, les capitaines étaient choisis parmi les développeurs proactifs pour aider à former des équipes. Il s'est avéré neuf équipes. Et malgré le fait que nous ayons résolu le problème du fer du point de vue du fair-play, nous devions toujours nous assurer que d'autres restrictions ne gêneraient pas notre armée de correcteurs de bogues.
La prochaine quête était le choix de la date de bagaton. Les dates de sortie pour chaque plateforme sont différentes - elles ont été sélectionnées pour que tout le monde soit à l'aise. Nous avons essayé de rapprocher le plus possible la date de l'attribution du candidat à la libération.
De plus, bagaton charge fortement les infrastructures de plate-forme. Quand il y a une compétition, qui corrige les bugs plus rapidement, le nombre de pull demandes décolle. Un mois et demi avant Bagaton, il y avait un risque que notre équipement ne puisse pas faire face aux pics prévus. Mais à ce moment-là, nous attendions du fer neuf, et il est arrivé juste à temps. Nous avons réussi à connecter, configurer et renforcer l'infrastructure de bande passante des deux plateformes à plusieurs reprises.
Pipeline - comment ne pas tout abaisser dans un tuyau
Tout a été fait ici comme suit: juste avant le début du bagaton de notre développement, nous avons pris la branche dans laquelle les équipes devaient travailler. De nombreuses demandes de tirage avec des bugs corrigés y ont été versées lors du bagaton. Des autotests ont été exécutés sur chacun d'eux, les développeurs ont examiné les demandes d'extraction et les testeurs ont vérifié les nouvelles versions pour corriger le bogue. Et donc toutes les 24 heures de la compétition.
Il fallait également répartir la charge des testeurs. Nous avons fait un graphique horaire du nombre prévu de demandes de tirage dans l'intervalle de bagaton de 24 heures - en fonction du nombre de participants, de la charge du serveur, des activités de tiers, etc. Comparé aux performances moyennes des testeurs et au nombre d'heures effectives de chaque bagaton d'accompagnement. Nous avons réparti le "devoir" pour que le samedi matin, les lignes soient aussi peu nombreuses que possible. En général, ils se sont trompés.
Dans le même temps, nous avons tenu compte du fait qu'après bagaton, il était nécessaire de commencer immédiatement les tests de régression afin d'évaluer la qualité de la branche le plus tôt possible et de décider de sa perfusion dans la branche dev. C'est une charge supplémentaire pour les testeurs.
Examen des fonctionnalités
Il était très important pour nous non seulement de corriger les bugs, mais de le faire qualitativement. Trois procédures permettent de vérifier le code envoyé par les développeurs dans les demandes d'extraction. Pour que le code s'aligne, ils doivent réussir:
- Trois développeurs expérimentés ont examiné et approuvé le code.
- le code s'est normalement écrasé et n'a pas échoué aux autotests;
- Après la génération et l'infusion, le bogue dans l'assembly sur les conditions décrites ne reprend pas.
Nous craignions qu'en mode compétitif, personne ne se révise. Et au sein de l'équipe, vous ne pouvez pas laisser d'avis. Par conséquent, ils ont décidé de ne rien inventer et d'agir sur le flux standard, comme dans le mode de travail: un examen croisé arbitraire - celui qui est libre, il prend le processus sur lui-même.
Il était également nécessaire d'effectuer un suivi afin que les avis ne soient pas envoyés dans la file d'attente. Afin de jouer la sécurité, nous avons attiré des signataires de la revue (même ceux qui n'ont pas participé au bagaton lui-même) et avons rappelé activement aux participants l'orientation sur la qualité. Un développeur iOS senior, en parallèle avec la correction de bugs pour son équipe, a reçu en un jour 80 requêtes pull - il a lu et compris. C'est vraiment beaucoup!
Nous sélectionnons et évaluons les bugs
Nous avons pris des bogues de faible priorité, nous avons éliminé les déchets évidents par les étiquettes et les dates. Au total, 490 bugs se sont avérés - pour la plupart de petite et moyenne taille, que les mains n'ont pas atteints en raison de tâches plus importantes. Ce sont tous des triviaux et des mineurs sensés:
- bogues qui sont passés de version en version à plusieurs reprises
- bugs résolus à la demande des utilisateurs
- crash le plus récent
- bogues de régression
- bogues affectant l'UX
Tous les bogues ont été divisés en trois vagues selon la priorité de fermeture:
- La première vague - environ 230 bugs
- La deuxième vague - environ 150 bugs
- La troisième vague (réserve) - environ 110 bugs
Les défauts ont été évalués non pas par leur complexité, mais par leur criticité pour l'entreprise. Les plus critiques sont «artificiellement» et placés temporairement en priorité «bloqueur» et «critique». Plus la priorité du bug est élevée, plus il a été attribué de points. La complexité n'a pas été prise en compte - il est arrivé que le bloqueur de bugs se ferme en 20 minutes, et le trivial - en 4 heures. Pour un bug, vous pourriez gagner de 1 à 7 points.
Nous avons conservé le score de chaque équipe pour les bogues fermés en fonction de leur valeur dans les règles de bagaton. Si les équipes ont eu le temps, elles ont mis au travail le défaut suivant. La motivation par la valeur a permis de fermer en premier lieu des bugs plus critiques.
Comment fermer les bogues
Nous avons divisé la première vague de bugs en 11 groupes (avec une marge), égaux en nombre de points et dans le ratio d'Android et iOS. La première vague est constituée de bogues «chers», prioritaires avec un coût accru. Pour une recherche pratique dans Jira, nous leur avons attribué les étiquettes appropriées. Environ 20 bugs ont été publiés dans chaque groupe.
Au début du bagaton, nous avons rassemblé des capitaines d'équipe et joué des labels. De plus, les capitaines dans leur filtre ont désigné l'étiquette souhaitée et distribué les bogues correspondants au sein de l'équipe. Nous avons donc réussi à éliminer la correction de bugs chaotique, où les gars prenaient simplement ce qui leur était le plus compréhensible.
Les quatre premières heures, les équipes se sont vues attribuer des points uniquement pour les bugs avec les labels du groupe qui leur étaient tombés pour fixer un rythme précis. Lorsque le temps était écoulé, les bogues encore ouverts passaient dans la deuxième vague, s'ajoutant aux autres qui avaient du sens de se fermer dans le bagaton.
À 19h00, tous les bugs non dévoilés sont entrés dans la troisième vague - en plus des bugs qui étaient déjà prévus là-bas. En conséquence, pour la soirée, nous avons eu des bogues «rapides» qui se fermaient dans le flux habituel: caches et actuels, déchargés littéralement un jour avant le bagaton, ainsi que des bogues avec la priorité la plus basse. Les trois vagues se sont mises au travail. En conséquence, 286 des 493 bogues sélectionnés ont été fermés pour bagaton.
Bagaton unit
Le siège social de Bagaton était situé dans notre salle de conférence, il y avait aussi des quiz et un tournoi de jeux vidéo. Les équipes n'étaient pas limitées, dispersées partout où cela leur convenait. En conséquence, toute la banque a découvert bagaton. Un consommateur de produits du quatrième étage a déclaré: «Je vais me rencontrer au 14e étage, à la recherche de la bonne salle de réunion. Tout à coup, je comprends que je viens de voir des visages familiers, je reviens - mes développeurs sont assis avec des figurines puissantes et principales, sans aucune attention pour moi. Ha - je pense - ils ne se cacheront pas de leur propriétaire de produit et sur 10 étages, d'accord, asseyez-vous déjà, le bugfix est une bonne chose. "
Il y avait une équipe dans laquelle un seul Android est venu au bagaton et en même temps six développeurs iOS puissants. Nous avons exceptionnellement éliminé cette équipe un autre package avec des bugs iOS.
De plus, sept développeurs des régions sont venus à bagaton. Certains ont rencontré leurs équipes pour la première fois, ce qu'ils n'avaient auparavant vu que par vidéoconférence. C'était très cool de voir comment ces gars-là ont activement rejoint le processus.
Comment les résultats ont-ils été évalués?
Pour près d'une centaine de développeurs, nous n'avions que 15 testeurs. Et la nuit, il y en a quatre. Tous n'étaient pas suffisants, les tests se sont donc poursuivis le lendemain. Ce sont les testeurs qui ont attribué des points aux équipes, nous les avons donc retirés de l'équipe afin d'éliminer les biais. Dans un flux de travail normal, le testeur peut appeler le développeur et découvrir: "Écoutez, mec, il y a un tel problème ...". Sur bagaton, c'était strict: les testeurs devraient envelopper tout ce qui ne passe pas clairement.
Nous avons donc pu constater que certains développeurs ne travaillent pas dans le flux accepté. Le hackathon est devenu une sorte de catalyseur pour tous les écarts. Ceux qui travaillent clairement dans le flux ont réussi les tests lors de la première vague et ont obtenu des points. Tous ceux qui ne correspondaient pas vraiment sont entrés dans la file d'attente, qu'ils avaient déjà ratissée après bagaton. Il a obtenu 60 bugs.
Incidents
En général, tout s'est déroulé comme d'habitude, les incidents étaient typiques et résolus dans un ordre de marche. Quand quelque chose s'est cassé, certains des Signors sont immédiatement passés du correctif à l'élimination de l'incident.
Il y a eu un drôle d'incident. Lors de la préparation du tableau de bord, nous avons décrit les risques possibles: accès à Jira, mises à jour continues, etc. Ils ont informé tous les administrateurs que pendant le temps du bagaton il était nécessaire de suspendre tous les travaux de maintenance, les mises à jour de Jira et des serveurs. Création de comptes de sauvegarde pour accéder à Jira. Et soudain, vers 18h00, nous nous rendons compte que le tableau de bord a cessé de collecter des données. Les hypothèses étaient différentes. Peut-être n’ont-ils pas pris en compte un protocole de sécurité? La raison était inattendue. Notre organisation est très grande, il n'est pas toujours possible d'obtenir des informations complètes sur tous les processus planifiés. Notre tableau de bord a été déployé sur une machine virtuelle sur l'un des serveurs secondaires. Il s'est avéré que c'est ce jour-là, vendredi soir, que ce serveur, selon un plan inconnu, a été physiquement déconnecté de la prise, chargé dans la voiture et envoyé en résidence permanente dans notre nouveau centre de données. Par conséquent, samedi matin, nous devions collecter toutes les données et calculer les points en mode manuel.
Fusionner les branches et autres résultats
En mode de fonctionnement normal, toute la branche est entraînée manuellement par plus de 800 cas de test. Une équipe complète de testeurs effectue nos tests de régression à temps plein en deux semaines. Nous ne pouvions pas nous permettre de continuer à nous développer inchangés aussi longtemps. Pour réduire le temps de test, nous avons sélectionné les principaux cas de test de la santé de l'application - environ 107. Jusqu'à la fin de lundi, ils ont piloté 80% d'iOS, 50% d'Android et n'ont révélé aucun bug critique. Nous avons décidé que les succursales pouvaient être fusionnées.
Sur les 286 bugs fermés sur le bagaton, 182 bugs ont été corrigés. Les autres sont des redjacks qui ne sont pas pertinents pour diverses raisons, des bugs (quelque part la conception ou la fonctionnalité a déjà changé). Ces bogues ne sont pas critiques, mais maintenant ils n'auront plus besoin d'être distraits et vous pouvez vous concentrer calmement sur les tâches importantes.
De plus, beaucoup, suite aux résultats de bagaton, avaient une question: combien de bugs avons-nous fait? Seulement huit bugs sur iOS et sept bugs sur Android.
Il est important pour nous que les développeurs se sentent responsables du code produit sur un pied d'égalité avec les autres membres de l'équipe. C'est important dans tout développement, mais dans le développement distribué, cela devient une condition préalable à un travail réussi. Et à notre avis, nous avons réussi à augmenter le niveau de cette même propriété et esprit d'équipe. Le résultat a été une histoire avec beaucoup de profits: en peu de temps, nous avons corrigé un tas de bugs, déchargé les backlogs, amélioré les compétences de l'équipe et obtenu beaucoup de fans.
Matériel préparé par l'équipe Sberbank Digital Business Platform