Préface
L'écosystème de paiement Mir Plat.Form comprend plusieurs dizaines de systèmes, dont la plupart interagissent les uns avec les autres à l'aide de différents protocoles et formats. Nous, l'équipe des tests d'intégration, vérifions que ces interactions répondent aux exigences établies.
Pour le moment, l'équipe travaille avec 13 systèmes critiques pour la mission et l'entreprise. Les systèmes essentiels à la mission garantissent que Mir Plat.Form remplit ses principales fonctions, qui assurent la stabilité et la continuité du fonctionnement du système de cartes bancaires de la Fédération de Russie. Les systèmes critiques pour l'entreprise sont chargés de prendre en charge les services supplémentaires fournis aux clients de Mir Plat.form, dont dépendent les activités opérationnelles directes de l'entreprise. La fréquence de déploiement des versions sur PROD varie d'une fois par semaine à une fois par trimestre, tout dépend du système et de l'état de préparation des participants pour la fréquence des mises à jour. Au total, nous avons compté environ 200 sorties qui sont passées par notre équipe l'année dernière.
Les mathématiques simples disent ce qui suit: le nombre de chaînes testées est N-systèmes * M-intégrations entre eux * K-versions. Même en utilisant l'exemple de 13 systèmes * 11 intégrations * 27 versions de version, il existe environ 3 861 options de compatibilité système possibles. La réponse semble évidente - des autotests? Mais le problème est un peu plus sérieux, seuls les autotests ne vous sauveront pas. Compte tenu du nombre croissant de systèmes et de leurs intégrations, ainsi que de la fréquence différente des versions, il existe toujours le risque de tester la mauvaise chaîne de versions de système. Par conséquent, il existe un risque de manquer un défaut dans l'interaction intersystème, affectant par exemple le bon fonctionnement du système de paiement Mir (PS).
Naturellement, dans PRODA, la présence de tels bugs est inacceptable et la tâche de notre équipe est de réduire ce risque à zéro. Si vous vous souvenez du texte ci-dessus, tout «éternuement» affecte non seulement les systèmes internes de Mir Plat.form, mais aussi les acteurs du marché: banques, commerçants, particuliers et même d'autres systèmes de paiement. Par conséquent, pour éliminer les risques, nous avons procédé de la manière suivante:
- Introduction d'une base de publication unifiée. Pour cette tâche, le calendrier des versions de Confluence suffisait, indiquant les versions des systèmes installés dans PROD;
- Nous suivons les chaînes d'intégration conformément aux dates de sortie. Ici, nous n'avons pas non plus réinventé la roue, nous en aurons encore besoin. Pour résoudre ce problème, nous avons utilisé des structures Epic dans JIRA pour les tests d'intégration des versions. Exemple de structure pour la version 1.111.0 de System3:
D'une part, toutes ces actions ont permis d'améliorer la compréhension par l'équipe des intégrations testées, des versions du système et de la séquence de leur mise en production sur PROD. D'un autre côté, il y a toujours la probabilité de tests incorrects dus au facteur humain:
- Si la date de sortie d'un système a été déplacée, un membre de l'équipe doit corriger manuellement le calendrier et l'ensemble de la structure dans JIRA, y compris les délais d'exécution des tâches et, éventuellement, la version des systèmes testés;
- Avant de tester l'intégration, vous devez vous assurer que l'environnement de test comprend les versions correctes des systèmes. Pour ce faire, vous devez parcourir manuellement les bancs de test et exécuter quelques commandes de console.
De plus, des travaux de routine supplémentaires sont apparus, prenant parfois une part importante du temps.
Il est devenu évident que ce processus de préparation des tests d'intégration des versions doit être en quelque sorte automatisé et, si possible, combiné en une seule interface. C'est là que notre propre vélo de sauvetage entre en jeu: Système de surveillance des tests d'intégration ou simplement SMIT.
Quelles options aimeriez-vous mettre en œuvre dans le système en cours de développement?
1. Un calendrier de publication clair avec la possibilité d'afficher les versions de tous les systèmes pour une date spécifique;
2. Environnements de surveillance pour les tests d'intégration:
- liste des environnements;
- affichage visuel des bancs d'essai et des systèmes faisant partie d'un environnement distinct;
- contrôle de version des systèmes déployés sur des bancs de test.
3. Travail automatisé avec des tâches dans Jira:
- créer une structure de publication Epic;
- gestion du cycle de vie des tâches de test;
- mise à jour des tâches en cas de décalage de la date de sortie;
- mettre des rapports d'attrait dans les tâches de test.
4. Travail automatisé avec les branches dans Bitbucket, à savoir la création de branches de version dans les projets:
- autotests d'intégration;
- auto-chauffage de l'environnement d'intégration.
5. Interface utilisateur intuitive pour exécuter des tests automatiques et mettre à jour les versions du système.
Qu'est-ce que SMITH
Puisque le système n'est pas compliqué, nous ne sommes pas devenus trop intelligents avec la technologie. Le backend a été écrit en Java à l'aide de Spring Boot. L'interface est React. Il n'y avait pas d'exigences particulières pour la base de données, nous avons donc choisi MySql. Comme il est habituel pour nous de travailler avec des conteneurs, tous les composants ci-dessus ont été encapsulés dans Docker, avec Docker Compose. SMITH fonctionne rapidement et de manière aussi fiable que les autres systèmes Mir Plat.Form.
L'intégration
- Atlassian Jira. Dans le jir, les tâches de test de chaque intégration spécifique sont créées, ouvertes, mises en œuvre et fermées, si tous les tests sont réussis, un lien vers le rapport d'allure est joint dans les commentaires.
- Atlassian BitBucket. , , / . “” , .
- Jenkins. Jenkins, . , , glue Cucumber.
- . . ssh.
Avant de pouvoir gérer un calendrier et surveiller l'état des environnements dans SMIT, vous devez créer une liste des systèmes testés et les relations entre eux. Tous les réglages peuvent être effectués via l'interface Web:
Après avoir ajouté le système testé à la liste SMIT:
- Va "frapper" sur tous les hôtes des systèmes nommés SYS_CMD dans la liste des environnements;
- trouve la version de ce système à l'aide de la commande spécifiée dans la configuration;
- écrira dans sa base de données la version actuelle de ce système et l'environnement dans lequel il apparaît.
En conséquence, SMIT contiendra des informations sur tous les systèmes déployés sur les environnements utilisés, y compris leurs numéros de version. Sur la base de ces informations, vous pouvez visualiser le calendrier des versions.
Calendrier de sortie
Une fois que les propriétaires des systèmes ou les chefs d'équipe des équipes de développement de produits nous ont indiqué la date d'installation d'une nouvelle version dans PROD, nous enregistrons cette version dans le calendrier. Il s'avère que c'est l'image:
vous pouvez facilement remarquer des conflits où plusieurs versions sont installées à la fois en quelques jours et une "chaleur" est possible. Les propriétaires de produits sont informés de ces conflits, car il est vraiment dangereux d'installer plusieurs nouvelles versions de systèmes le même jour.
Également sur la page avec le calendrier, il y a une fonction pour afficher les versions de tous les systèmes pour une date spécifique:
Il convient de noter que lors de l'enregistrement d'une nouvelle version dans le calendrier, SMIT crée automatiquement une structure Epic dans Jira et libère des branches dans des projets dans Bitbucket.
État de l'environnement
Une autre fonction très pratique de SMITH est de visualiser l'état actuel d'un environnement particulier. Sur cette page, vous pouvez découvrir la liste des systèmes inclus dans l'environnement et la pertinence de leurs versions.
Comme vous pouvez le voir sur la capture d'écran, SMITH a trouvé une version obsolète de System 4 sur host-4.nspk.ru et propose de la mettre à jour. Si vous appuyez sur le bouton rouge avec une flèche blanche, SMITH appellera le travail Jenkins pour déployer la version actuelle du système dans l'environnement actuel. Il est également possible de mettre à jour tous les systèmes après avoir appuyé sur le bouton correspondant.
Environnements de test d'intégration
Il vaut la peine de dire un peu comment nous définissons les environnements de test. Un environnement est un ensemble de stands avec des systèmes Mir Plat.form déployés et une intégration personnalisée (sur un stand - un système). Au total, nous avons 70 stands, répartis en 12 environnements.
Dans le projet d'autotests d'intégration, nous avons un fichier de configuration dans lequel les testeurs définissent des environnements de test. La structure du fichier ressemble à ceci:
{
"properties":{
"comment":" system property Environment. property, , System.getProperties()",
"common.property":"some global property"
},
"environments":[
{
"comment":" name, Environment common + . common1",
"name":"env_1",
"properties":{
"comment":" system property Environment. property. , System.getProperties()",
"env1.property":"some personal property"
},
"DB":{
"comment":" TestResource' DbTestResource. id, ",
"url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",
"driver":"com.mysql.jdbc.Driver",
"user":"fo",
"password":"somepass"
},
"SYS_CMD":{
"comment":" TestResource' RemoteExecCmd. type = remote",
"type":"remote",
"host":"10.111.111.111",
"username":"user",
"password":"somepass"
}
}
]
}Outre le fait que ce fichier est nécessaire au fonctionnement du projet d'autotest d'intégration, il s'agit également d'un fichier de configuration supplémentaire pour SMIT. Lorsque vous demandez la mise à jour des informations sur les environnements dans SMIT, une requête HTTP est envoyée à l'API de notre bitbucket, où nous stockons le projet avec des autotests d'intégration. De cette manière, SMITH obtient le contenu actuel du fichier de configuration de la branche principale.
Exécution de tests
L'un des objectifs de la création de SMIT était de simplifier au maximum la procédure de lancement des autotests d'intégration. Considérons ce que nous avons fini avec un exemple:
sur la page de test du système (dans cet exemple, Système 3), vous pouvez sélectionner une liste de systèmes avec lesquels vous souhaitez vérifier l'intégration. Après avoir sélectionné les intégrations requises et cliqué sur le bouton «Démarrer le test», SMITH:
1. Forme une file d'attente et lance séquentiellement les travaux Jenkins correspondants;
2. surveille l'exécution des travaux;
3. modifie le statut des problèmes correspondants dans Jira:
- Si le travail s'est terminé avec succès, la tâche dans Jira sera automatiquement fermée, un lien vers un rapport d'attrait et un commentaire indiquant qu'aucun défaut n'a été trouvé dans cette intégration y seront attachés.
- Si le travail est défectueux, la tâche dans Jira restera ouverte et attendra une décision de l'employé responsable de l'intégration, qui sera en mesure de déterminer la cause de l'échec des tests. La personne responsable de l'intégration est visible sur la carte d'intégration.
Production
SMITH a été créé pour minimiser les risques des tests d'intégration, mais en tant qu'équipe, nous voulions plus! En particulier, l'un des souhaits était qu'en un clic sur le bouton, les autotests soient lancés avec l'environnement de test correct, tout soit vérifié dans les correspondances d'intégration nécessaires et les tâches dans Jira soient ouvertes et fermées avec les rapports. Une telle utopie d'auto-testeurs: dites au système ce qu'il faut vérifier - et allez boire du café :)
Résumons ce que nous avons réussi à mettre en œuvre:
- Calendrier de publication visuel avec la possibilité d'afficher les versions de tous les systèmes à une date spécifique;
- UI , , ;
- ;
- UI ;
- Epic Task Jira, Allure ;
- Bitbucket.
Pour le moment, le système fait l'objet de tests bêta fermés parmi les membres directs de l'équipe de test d'intégration. Lorsque tous les défauts détectés seront éliminés et que le système remplira ses fonctions de manière stable, nous ouvrirons l'accès aux employés des équipes associées et des propriétaires de produits afin qu'ils puissent exécuter nos tests de manière indépendante et étudier le résultat.
Ainsi, dans un scénario idéal, tout ce qui doit être fait pour vérifier la conformité du système avec les exigences d'intégration est d'aller sur l'interface Web SMIT, de mettre à jour le système nécessaire via celle-ci, de cocher toutes les cases et d'exécuter les tests, puis de vérifier qu'ils ont tous été terminés avec succès. Les tâches seront créées automatiquement, les rapports d'allure seront remplis, les statuts correspondants seront affectés à ces tâches.