Vorwort
Das Mir Plat.Form-Zahlungs-Ökosystem umfasst mehrere Dutzend Systeme, von denen die meisten über verschiedene Protokolle und Formate miteinander interagieren. Wir, das Integrationstest-Team, überprüfen, ob diese Interaktionen den festgelegten Anforderungen entsprechen.
Derzeit arbeitet das Team mit 13 unternehmens- und geschäftskritischen Systemen. Missionskritische Systeme stellen sicher, dass Mir Plat.Form seine Hauptfunktionen erfüllt und die Stabilität und Kontinuität des russischen Bankkartensystems gewährleistet. Geschäftskritische Systeme sind für die Unterstützung zusätzlicher Dienste verantwortlich, die Mir Plat.form-Kunden bereitgestellt werden und von denen die direkten operativen Aktivitäten des Unternehmens abhängen. Die Häufigkeit der Einführung von Veröffentlichungen in PROD variiert von einmal pro Woche bis einmal pro Quartal. Dies hängt alles vom System und der Bereitschaft der Teilnehmer für die Häufigkeit von Aktualisierungen ab. Insgesamt haben wir ungefähr 200 Veröffentlichungen gezählt, die letztes Jahr durch unser Team gingen.
Einfache Mathematik sagt Folgendes: Die Anzahl der getesteten Ketten ist N-Systeme * M-Integrationen zwischen ihnen * K-Releases. Selbst am Beispiel von 13 Systemen * 11 Integrationen * 27 Release-Versionen gibt es ungefähr 3.861 mögliche Systemkompatibilitätsoptionen. Es scheint, dass die Antwort offensichtlich ist - Autotests? Das Problem ist jedoch etwas schwerwiegender. Nur Autotests werden Sie nicht retten. Angesichts der wachsenden Anzahl von Systemen und ihrer Integrationen sowie der unterschiedlichen Häufigkeit von Releases besteht immer das Risiko, dass die falsche Systemversionskette getestet wird. Daher besteht die Gefahr, dass ein Fehler in der systemübergreifenden Interaktion übersehen wird, der beispielsweise den ordnungsgemäßen Betrieb des Mir-Zahlungssystems (PS) beeinträchtigt.
Natürlich ist das Vorhandensein solcher Fehler in PRODA nicht akzeptabel, und die Aufgabe unseres Teams besteht darin, dieses Risiko auf Null zu reduzieren. Wenn Sie sich an den obigen Text erinnern, betrifft jedes „Niesen“ nicht nur die internen Systeme von Mir Plat.form, sondern auch die Marktteilnehmer: Banken, Händler, Einzelpersonen und sogar andere Zahlungssysteme. Um die Risiken auszuschließen, sind wir daher wie folgt vorgegangen:
- Einführung einer einheitlichen Release-Basis. Für diese Aufgabe war der Release-Kalender in Confluence ausreichend, der die Versionen der in PROD installierten Systeme angibt.
- Wir verfolgen Integrationsketten gemäß den Veröffentlichungsterminen. Auch hier haben wir das Rad nicht neu erfunden, wir werden es weiter brauchen. Um dieses Problem zu lösen, haben wir epische Strukturen in JIRA zum Integrationstest von Releases verwendet. Eine Beispielstruktur für Release 1.111.0 von System3:
Einerseits haben all diese Aktionen dazu beigetragen, das Verständnis des Teams für die getesteten Integrationen, Systemversionen und die Reihenfolge ihrer Freigabe für PROD zu verbessern. Andererseits besteht immer noch die Wahrscheinlichkeit, dass aufgrund des menschlichen Faktors falsche Tests durchgeführt werden:
- Wenn das Veröffentlichungsdatum eines Systems verschoben wurde, muss ein Teammitglied den Kalender und die gesamte Struktur in JIRA manuell korrigieren, einschließlich der Fristen für die Erledigung von Aufgaben und möglicherweise der Versionen der getesteten Systeme.
- Bevor Sie die Integration testen, müssen Sie sicherstellen, dass die Testumgebung aus den richtigen Versionen der Systeme besteht. Dazu müssen Sie manuell über die Prüfstände gehen und einige Konsolenbefehle ausführen.
Darüber hinaus sind zusätzliche Routinearbeiten aufgetreten, die manchmal einen erheblichen Teil der Zeit in Anspruch nehmen.
Es wurde deutlich, dass dieser Prozess der Vorbereitung auf Integrationstests von Releases irgendwie automatisiert und, wenn möglich, in einer Schnittstelle kombiniert werden muss. Hier kommt unser eigenes lebensrettendes Fahrrad ins Spiel: Integration Testing Monitoring System oder einfach SMIT.
Welche Optionen möchten Sie in das in der Entwicklung befindliche System implementieren?
1. Ein übersichtlicher Veröffentlichungskalender mit der Möglichkeit, Versionen aller Systeme für ein bestimmtes Datum anzuzeigen.
2. Überwachungsumgebungen für Integrationstests:
- Liste der Umgebungen;
- visuelle Anzeige von Prüfständen und Systemen, die Teil einer separaten Umgebung sind;
- Versionskontrolle von Systemen, die auf Prüfständen eingesetzt werden.
3. Automatisierte Arbeit mit Aufgaben in Jira:
- Erstellen einer epischen Release-Struktur;
- Lebenszyklusmanagement von Testaufgaben;
- Aktualisieren von Aufgaben im Falle einer Verschiebung des Veröffentlichungsdatums;
- Allure-Berichte in Testaufgaben einfügen.
4. Automatisierte Arbeit mit Zweigen in Bitbucket, nämlich das Erstellen von Freigabezweigen in Projekten:
- Autotests für die Integration;
- automatische Erwärmung der Integrationsumgebung.
5. Intuitive Benutzeroberfläche zum Ausführen von Autotests und Aktualisieren von Systemversionen.
Was ist SMITH?
Da das System nicht kompliziert ist, sind wir mit der Technologie nicht zu schlau geworden. Das Backend wurde mit Spring Boot in Java geschrieben. Das Frontend ist React. Da für die Datenbank keine besonderen Anforderungen gestellt wurden, haben wir uns für MySQL entschieden. Da es für uns üblich ist, mit Containern zu arbeiten, wurden alle oben genannten Komponenten in Docker verpackt und mit Docker Compose erstellt. SMITH arbeitet schnell und zuverlässig wie andere Mir Plat.Form-Systeme.
Integration
- Atlassian Jira. Im JIR werden Aufgaben zum Testen jeder spezifischen Integration erstellt, geöffnet, in Arbeit genommen und geschlossen. Wenn alle Tests erfolgreich sind, wird in den Kommentaren ein Link zum Allure-Bericht angehängt.
- Atlassian BitBucket. , , / . “” , .
- Jenkins. Jenkins, . , , glue Cucumber.
- . . ssh.
Bevor Sie einen Kalender verwalten und den Status von Umgebungen in SMIT überwachen können, müssen Sie eine Liste der getesteten Systeme und der Beziehungen zwischen ihnen erstellen. Alle Einstellungen können über die Weboberfläche vorgenommen werden:
Nach dem Hinzufügen des zu testenden Systems zur SMIT-Liste:
- Klopft auf alle Hosts von Systemen mit dem Namen SYS_CMD in der Liste der Umgebungen.
- ermittelt die Version dieses Systems mit dem in der Konfiguration angegebenen Befehl;
- schreibt die aktuelle Version dieses Systems und die Umgebung, in der es angezeigt wird, in seine Datenbank.
Infolgedessen enthält SMIT Informationen zu allen in den verwendeten Umgebungen bereitgestellten Systemen, einschließlich ihrer Versionsnummern. Basierend auf diesen Informationen können Sie den Veröffentlichungskalender visualisieren.
Kalender freigeben
Nachdem die Eigentümer von Systemen oder Teamleiter der Produktentwicklungsteams uns das Datum der Installation einer neuen Version in PROD mitgeteilt haben, registrieren wir diese Version im Kalender. Es stellt sich heraus, dass dies das Bild ist:
Sie können leicht Konflikte feststellen, bei denen mehrere Releases innerhalb weniger Tage gleichzeitig installiert werden und ein "Heat" möglich ist. Produktbesitzer werden über diese Konflikte informiert, da es sehr gefährlich ist, mehrere neue Systemversionen am selben Tag zu installieren.
Auf der Seite mit dem Kalender gibt es auch eine Funktion zum Anzeigen von Versionen aller Systeme für ein bestimmtes Datum:
Es ist zu beachten, dass SMIT bei der Registrierung einer neuen Version im Kalender automatisch eine epische Struktur in Jira erstellt und Zweige in Projekten in Bitbucket freigibt.
Umweltzustand
Eine weitere sehr praktische Funktion von SMITH besteht darin, den aktuellen Status einer bestimmten Umgebung anzuzeigen. Auf dieser Seite finden Sie eine Liste der in der Umgebung enthaltenen Systeme und die Relevanz ihrer Versionen.
Wie Sie im Screenshot sehen können, hat SMITH auf host-4.nspk.ru eine veraltete System 4-Version gefunden und bietet an, diese zu aktualisieren. Wenn Sie die rote Taste mit einem weißen Pfeil drücken, ruft SMITH den Jenkins-Job auf, um die aktuelle Version des Systems in der aktuellen Umgebung bereitzustellen. Es ist auch möglich, alle Systeme nach Drücken der entsprechenden Taste zu aktualisieren.
Integrationstestumgebungen
Es lohnt sich, ein wenig darüber zu erzählen, wie wir Testumgebungen definieren. Eine Umgebung besteht aus einer Reihe von Ständen mit bereitgestellten Mir Plat.form-Systemen und angepasster Integration (an einem Stand - einem System). Insgesamt haben wir 70 Stände, die in 12 Umgebungen unterteilt sind.
Im Projekt der automatischen Integrationstests haben wir eine Konfigurationsdatei, in der Tester Testumgebungen festlegen. Die Dateistruktur sieht folgendermaßen aus:
{
"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"
}
}
]
}Neben der Tatsache, dass diese Datei für das Autotest-Projekt der Integration erforderlich ist, handelt es sich auch um eine zusätzliche Konfigurationsdatei für SMIT. Wenn Sie Informationen zu Umgebungen in SMIT aktualisieren möchten, wird eine HTTP-Anforderung an die API unseres Bitbucket gesendet, wo wir das Projekt mit automatischen Integrationstests speichern. Auf diese Weise erhält SMITH den aktuellen Inhalt der Konfigurationsdatei vom Hauptzweig.
Ausführen von Tests
Eines der Ziele bei der Erstellung von SMIT war es, das Verfahren zum Starten von Autotests für die Integration so weit wie möglich zu vereinfachen. Betrachten wir anhand eines Beispiels, was wir am Ende erhalten haben:
Auf der Seite Systemtests (in diesem Beispiel System 3) können Sie eine Liste der Systeme auswählen, mit denen Sie die Integration überprüfen möchten. Nachdem Sie die erforderlichen Integrationen ausgewählt und auf die Schaltfläche „Test starten“ geklickt haben, wird SMITH:
1. Eine Warteschlange bilden und die entsprechenden Jenkins-Jobs nacheinander starten .
2. überwacht die Auftragsausführung;
3. ändert den Status der entsprechenden Probleme in Jira:
- Wenn der Job erfolgreich abgeschlossen wurde, wird die Aufgabe in Jira automatisch geschlossen, ein Link zum Allure-Bericht und ein Kommentar werden angehängt, der besagt, dass bei dieser Integration keine Fehler gefunden wurden.
- Wenn der Job fehlerhaft ist, bleibt die Aufgabe in Jira offen und wartet auf eine Entscheidung des für die Integration verantwortlichen Mitarbeiters, der die Ursache für die fehlgeschlagenen Tests ermitteln kann. Die für die Integration verantwortliche Person ist auf der Integrationskarte zu sehen.
Ausgabe
SMITH wurde entwickelt, um das Risiko von Integrationstests zu minimieren, aber als Team wollten wir mehr! Einer der Wünsche war insbesondere, dass mit einem Klick auf die Schaltfläche Autotests mit der richtigen Testumgebung gestartet wurden, alles in den erforderlichen Integrationsübereinstimmungen überprüft wurde und Aufgaben in Jira zusammen mit Berichten geöffnet und geschlossen wurden. Eine solche Utopie von Autotestern: Sagen Sie dem System, was zu überprüfen ist - und trinken Sie Kaffee :) Fassen
wir zusammen, was wir implementiert haben:
- Visueller Veröffentlichungskalender mit der Möglichkeit, Versionen aller Systeme an einem bestimmten Datum anzuzeigen;
- UI , , ;
- ;
- UI ;
- Epic Task Jira, Allure ;
- Bitbucket.
Derzeit wird das System unter direkten Mitgliedern des Integrationstestteams einem Closed Beta-Test unterzogen. Wenn alle gefundenen Mängel beseitigt sind und das System seine Funktionen stabil ausführt, öffnen wir den Zugang zu Mitarbeitern verwandter Teams und Produktbesitzern, damit diese unsere Tests unabhängig durchführen und das Ergebnis untersuchen können.
In einem idealen Szenario müssen Sie lediglich zur SMIT-Weboberfläche wechseln, das erforderliche System über diese aktualisieren, alle Kontrollkästchen aktivieren und die Tests ausführen und dann überprüfen, ob alle erfolgreich abgeschlossen wurden, um zu überprüfen, ob das System die Integrationsanforderungen erfüllt. Aufgaben werden automatisch erstellt, Allure-Berichte werden ausgefüllt, die entsprechenden Status werden diesen Aufgaben zugewiesen.