Mettez à jour vos versions

Henry Ford a dit un jour: "La meilleure voiture est une nouvelle voiture." Ainsi, nous, au sein du groupe d'entreprises Tinkoff, pensons aux versions logicielles. L'inertie dans le processus de livraison des fonctionnalités et des correctifs urgents entraîne tôt ou tard une lourde dette technique pour le client et se termine le plus souvent par une stagnation du projet dans son ensemble.

Garantir un indicateur de délai de commercialisation élevé tout en maintenant la qualité n'est pas une tâche facile. De mon point de vue, vous ne pouvez pas construire immédiatement des rails sur lesquels il sera possible d'apporter rapidement et facilement des modifications plusieurs mois après le début. La croissance d'un projet s'accompagne généralement d'une augmentation du nombre de personnes qui y travaillent, ce qui signifie qu'il crée une source potentielle de chaos dans vos versions.

Notre expérience ne vaut guère la peine d'être considérée comme des instructions pour réussir, mais un certain nombre d'idées m'ont paru suffisamment intéressantes pour être partagées avec vous. Commençons.

Le point de départ de notre histoire est techniquement le suivant. Le système se compose de plusieurs services, dont la base de code est fouillée par une trentaine de personnes - plusieurs équipes réparties par domaine d'activité, par exemple, au service des particuliers et des personnes morales. J'essaierai d'ignorer les détails techniques et architecturaux du projet afin de me concentrer sur le processus de sortie lui-même.

Nous travaillons sur Gitflow , donc l'article sera principalement intéressant pour ceux qui ont choisi ce mode de livraison particulier.

Les problèmes

Le premier problème rencontré est lié à l' automatisation insuffisante des processus . La mise en œuvre de toutes les activités de publication dans notre équipe est liée au rôle de responsable de publication (RM).

En voici quelques uns:

1. Quitter les branches de publication et créer des balises.
2. Fusionner avec le maître et développer des branches.
3. Générez et déployez des artefacts inclus dans la version.
4. Communication avec des spécialistes impliqués dans le processus - par exemple, avec l'AQ ou les administrateurs.

Ces tâches de routine nécessitent de plus en plus de ressources à mesure que le projet se développe (dans notre cas, une augmentation du nombre de services), donc la première étape consiste à automatiser tout ce qui peut être automatisé. Nous nous intégrons à l'outil CI / CD afin d'allouer et de fusionner les branches de publication, de lancer des builds de test et de déployer des artefacts; avec l'outil de suivi des tâches et le messager d'entreprise pour une notification en temps opportun du participant responsable de l'étape suivante - par exemple, changez le statut de la tâche et configurez le hook pour envoyer une notification.

Le gestionnaire de versions devra toujours résoudre manuellement les conflits potentiels résultant de la fusion des branches, mais les versions rapides et fréquentes devraient réduire leur nombre à néant.

Le prochain problème est le test .

L'un des critères de construction pour nous est la réussite des tests. Il est habituel de diviser les tests en au moins deux types: unité et intégration.

Les tests unitaires permettent de vérifier l'exactitude des modules individuels du code source du programme, ce qui revient le plus souvent à tester une ou plusieurs méthodes ayant une connexion logique évidente.

Les tests d'intégration vérifient généralement l'opérabilité de toute une cascade de tels modules, c'est-à-dire le fonctionnement d'une fonctionnalité entière côté client. Par exemple, si une interface de repos a été implémentée dans une tâche, nous vérifierons l'opérabilité de l'autorisation, la désérialisation de la demande elle-même, la validité des champs transférés, l'intégration avec d'autres services et bases de données, ainsi que la logique métier elle-même. À première vue, il peut sembler que de tels tests sont très autosuffisants et peuvent couvrir tous les problèmes potentiels. Il n'est pas nécessaire de comprendre le fonctionnement de chaque brique individuelle, et l'interface appelée encapsule toute la logique afin d'obtenir une réponse simple sur la sortie: si elle fonctionne ou non.

En fait, ils créent un certain nombre de problèmes différés, en voici quelques-uns:

1. La participation d'un grand nombre de composants testés affecte proportionnellement le temps d'assemblage et l'exécution de ces tests.
2. L'encapsulation de la logique du test conduit souvent au fait qu'il est difficile de garantir l'exactitude du résultat du test. Souvent, nous personnalisons le test pour le résultat, et encore plus souvent, le résultat correspond à l'attente en raison d'effets secondaires aléatoires.
3. La pertinence des données de test est perdue.
4. Les intégrations avec des systèmes tiers, en particulier dans des environnements de test, tombent souvent. Cela annule le temps passé à courir, car ce n'est pas toujours évident: il s'agit d'une baisse ou d'une panne temporaire causée par nos modifications.

Car la plupart des problèmes ont déjà trouvé une solution. Mais, comme d'habitude, les solutions ne viennent pas sans restrictions supplémentaires ni nouveaux problèmes.

Choisir les bons tests pour vous et les implémenter correctement est une tâche très difficile. De plus, il est important de trouver un équilibre entre la qualité de la couverture et la vitesse de construction afin d'optimiser vos versions.

Dans notre cas, nous avons opté pour un hybride. Nous continuons à lever tous les composants nécessaires pour un test complet des fonctionnalités, en lavant simultanément toutes les intégrations possibles. Pour sauvegarder les contrats API, nous utilisons Pact et pour vérifier l'intégration avec la base de données - Testcontainers .

Une telle approche de l'écriture des tests a abouti à une solution au troisième problème - un temps long pour le test manuel d'une tâche . La stabilité des tests hybrides a conduit à l'idée d'attirer un ingénieur QA au stade de la spécification de la tâche de compilation des cas de test - cela leur permettra d'être sauté au stade des tests manuels. L'intégration avec des produits utiles tels que TestRail et Allure est devenue une sorte de pont entre le développeur et le testeur. Un contrat est créé, dont l'exécution est étape par étape reflétée dans le rapport généré lors de l'assemblage de test.

Il reste à connecter les rapports à votre outil de suivi des tâches pour un suivi transparent des tâches. Une histoire claire réduira également le temps nécessaire pour compiler et implémenter des tests pour les futures tâches connexes.

De cette façon, les ingénieurs QA gagnent suffisamment de temps pour se concentrer sur le test de cas exceptionnels et l'intégration avec d'autres systèmes.

Le dernier problème est lié à cela. Pour les tests manuels, toutes les tâches fusionnent à partir des branches de fonctionnalités lors du développement et du lancement d'un déploiement vers le banc de test.

Tout d'abord, avec cette approche, vous ne pouvez pas parler de tests purs de la fonctionnalité, car en parallèle, les changements connexes d'autres développeurs peuvent tomber dans le développement.

Deuxièmement, lors de la publication de la branche de publication, il se peut que le contrôle qualité n'ait pas eu le temps de tester certaines tâches. Vous avez le choix: annuler les modifications affectées par ces tâches ou ralentir la publication jusqu'à la fin des tests.

Vous devrez faire un tel choix tout le temps, sauf si vous isolez votre environnement de test . Il est important qu'il n'y ait aucun changement dans le composant sous test autre que ceux apportés par la tâche. Dans notre cas, nous devons être en mesure de récupérer un ou plusieurs services dont les succursales ont été modifiées et gérer le routage à l'intérieur du cluster en envoyant uniquement les demandes dont nous avons besoin du QA à ces instances. La tâche est compliquée si des mécanismes d'équilibrage sont déjà utilisés sur le cluster, qui doivent également être pris en compte.

Ayant saisi cette opportunité, nous avons commencé à effectuer des tests manuels directement sur des branches de fonctionnalités distinctes: déployer le service souhaité pendant la durée du test, en s'intégrant dans l'environnement global de manière isolée. En fusionnant uniquement les tâches prédéfinies dans la branche de développement et en supprimant les verrous, nous avons nous-mêmes commencé à déterminer quelles modifications devaient être incluses dans la version et lesquelles ne devaient pas l'être.

Il convient de noter qu'une telle solution ne devrait pas devenir une solution miracle pour les équipes qui apportent des modifications à presque les mêmes fichiers. Dans ce cas, le stockage des fonctionnalités est inversement proportionnel au nombre de conflits qui surviennent lors de la fusion. En pratique, avec des versions assez fréquentes, cela se produit extrêmement rarement dans une équipe de cinquante développeurs.

Au lieu de la sortie

En résumé, nous pouvons identifier les principales approches qui peuvent aider à accélérer les versions:

1. Automatisation des opérations de routine.
2. Transparence des processus pour toutes les parties concernées.
3. L'équilibre nécessaire entre rapidité et qualité dans l'écriture de tests automatisés.
4. Temps réduit pour les tests manuels.
5. Isolement de l'environnement pour les tests.

Il est important de comprendre que dans le choix des différentes approches, principes et stratégies, il vaut toujours la peine de partir du contexte de votre problème. Il existe de nombreuses façons tout aussi fiables et plus sophistiquées d'accélérer la livraison de votre logiciel au client. Une tentative de répondre aux difficultés émergentes a conduit aux conclusions décrites ci-dessus. Pour nous, ils ont été la première étape vers une approche plus audacieuse des versions .