Vor nicht allzu langer Zeit wurde bei einem der Projekte unseres Unternehmens beschlossen, die Verwendung von Subversion zum Speichern und Versionsverwaltung von Code endgültig zugunsten von Git aufzugeben.
Die Hauptziele des Übergangs waren:
- Verbesserung der Transparenz des Entwicklungsprozesses.
- Implementierung des obligatorischen Codeüberprüfungsverfahrens vor dem Aktualisieren von Updates für Testumgebungen.
- Implementieren Sie eine kontinuierliche Integration, um Updates nach der Codeüberprüfung zu erstellen und in Testumgebungen zu installieren.
Voraussetzung für die Erreichung dieser Ziele war die Verwendung von GitLab (dieser Git-Server wurde bereits vom Kunden verwendet und es gab dort bereits Code, der zur Vorderseite der Lösung gehörte) und Jira (ebenfalls bereits vom Kunden verwendet).
Es wurde vorgeschlagen, Git Flow als Zielentwicklungsmodell zu verwenden und einen Überprüfungscode hinzuzufügen. Dieses De-facto-Entwicklungsmodell ist zum Standard in der Open-Source-Softwareentwicklung geworden und wird von den meisten Branchenriesen verwendet. Aus diesem Grund ist die Unterstützung in viele beliebte Tools für die Arbeit mit Git integriert. Es wurde eine große Anzahl von Materialien zum Thema seiner Verwendung geschrieben, von denen ich die erfolgreichsten für die erste Einarbeitung zitieren werde: eins und zwei .
Dieses Modell bietet an sich nur allgemeine Prinzipien für die Codepflege, wobei die mit dem Schreiben verbundenen Prozesse weggelassen werden. Daher hängt die Implementierung von allem anderen, einschließlich des Überprüfungscodes, vom jeweiligen Git-Server ab. In dieser Hinsicht ist GitHub am bequemsten: Es wurde ursprünglich als Plattform für die Zusammenarbeit einer großen Anzahl unabhängiger Entwickler entwickelt und ermöglicht es Ihnen, die Rechte zum Senden von Commits (Push) im Repository einzuschränken und Anforderungen zum Senden von Code zu erstellen. Darüber hinaus bietet GitLab einen eigenen Workflow für die Verwaltung von Code namens GitLab Flow, der auf die Verwendung von GitLab CI zugeschnitten ist. Daher ist in GitLab die Funktionalität zum Erstellen von Anforderungen zum Senden von Code nicht implementiert, und es wird vorgeschlagen, Verzweigungsanführungsanforderungen zum Überprüfen des Änderungscodes zu verwenden. Zum Erstellen und Installieren von Artefakten im Projekt wurde bereits Jenkins verwendet, mit dem Sie flexibel Assembly- und Bereitstellungsaufgaben erstellen und konfigurieren können. Es wurde beschlossen, nicht auf GitLab CI zu wechseln, und gleichzeitig die Idee der Verwendung von GitLab Flow abzulehnen.
Ich stelle auch fest, dass für das Projekt Integrationen in Jira und Git konfiguriert wurden. In Jira wurde im Git-Plugin ein Repository hinzugefügt, das zum Speichern von Quellcode zum Nachverfolgen erstellt wurde, und in GitLab wurde dieses Repository für die Integration mit Jira im Abschnitt "Integrationen" des Repositorys konfiguriert.
Um dieses Problem zu lösen, wurde ein Workflow für die Arbeit mit Code entwickelt, der in seiner Struktur Git Flow ähnelt, es Ihnen jedoch ermöglicht, den Code jedes Mal zu überprüfen, wenn Sie mit GitLab Änderungen an den Hauptprozesszweigen (Entwickeln, Release-n und Master) vornehmen. Als nächstes werden der resultierende Prozess sowie die Stufen der kontinuierlichen Integration und Softwarebereitstellung für die angrenzenden Zeichenfolgen beschrieben. In Klammern stehen die entsprechenden auszuführenden Befehle.
Das zum Speichern des Quellcodes erstellte Repository wird in das lokale Repository (Git-Klon) hochgeladen und darin Git Flow (Git-Flow-Init) initialisiert. Zusätzlich zum Hauptzweig (zum Erstellen von Tags zum Speichern stabiler Releases) wird der Entwicklungszweig erstellt (der Hauptentwicklungszweig in) (die Funktionszweige, Releases und Fixes integriert), Masken für Funktionszweige, Releases und Fixes werden gesetzt, und es wird auch ein Übergang zum Entwicklungszweig vorgenommen.
Als nächstes wird der aktuelle Quellcode-Zweig von Subversion in die Arbeitskopie übertragen, der Code wird in den Entwicklungszweig des lokalen Repositorys übertragen (git add -A + git commit -m "Commit message") und in das Remote-Repository hochgeladen (git push origin development). Danach können Sie mit Git neue Funktionen entwickeln, um den Code zu versionieren.
Während der Entwicklung wird die aktuelle Version des Entwicklungszweigs heruntergeladen und daraus Zweige für die Entwicklung neuer Funktionen (Git Flow Feature Start MYFEATURE) gemäß den Jira-Taskcodes erstellt, in denen die Entwicklung durchgeführt wird.
Ein Übergang zum erstellten Zweig (git checkout MYFEATURE) wird automatisch durchgeführt, die geplante Funktionalität wird entwickelt und Änderungen werden in den lokalen MYFEATURE-Zweig übernommen (git commit -m "Commit message"). Beachten Sie, dass für die korrekte Integration von Git und Jira der Festschreibungscode in Jira, für den dieser Fix gilt, in den Festschreibungsnachrichten angegeben werden sollte. Diese Commits werden dann in den entsprechenden Aufgaben sowie im Abschnitt „Git-Commits“ des Projekts angezeigt, mit deren Hilfe Sie eindeutig feststellen können, was in einer bestimmten Version enthalten ist.
Wenn die Funktionalität der ausgewählten Aufgabe entwickelt und bereit ist, an die Testumgebung gesendet zu werden, werden die erstellten Commits in den gleichnamigen Remote-Zweig hochgeladen (git push -u origin MYFEATURE) und eine Anforderung zum Zusammenführen des heruntergeladenen Zweigs mit dem Entwicklungszweig an den Teamleiter oder dessen handelnde Aufgaben gerichtet.
Um eine Zusammenführung anzufordern, löst der Entwickler Zusammenführungskonflikte (falls vorhanden) und der Leiter des Entwicklungsteams (oder das Handeln) erstellt eine Codeüberprüfung, bei der zusätzliche Festschreibungen (git commit -m „Festschreibungsnachricht“) mit Korrekturen an den empfangenen Kommentaren erstellt werden können während der Codeüberprüfung in einem Zweig mit neuen Funktionen und dem Senden an das zentrale Repository (git push -u origin MYFEATURE). Nach erfolgreichem Abschluss der Überprüfung bestätigt der Teamleiter (oder das Handeln) die Fusion der Niederlassungen. Hier ist es nicht überflüssig, das Flag zum Löschen eines Zweigs nach dem Zusammenführen zu setzen - andernfalls kann die Anzahl der Zweige schnell zu unanständigen Maßstäben ansteigen.
Um eine kontinuierliche Integration in das GitLab-Repository sicherzustellen, wird im Abschnitt "Integrationen" ein Web-Hook konfiguriert, der Jenkins-Tasks aufruft, um neue Funktionen in der Testumgebung zu erstellen und zu installieren. Jenkins verwendet ein Plug-In für die Arbeit mit Git, lädt den Quellcode herunter, ruft den Namen der Aufgabe ab und fordert mithilfe der Jira-API eine Liste der Komponenten an, die geändert wurden und zusammengesetzt werden müssen, startet den Erstellungsprozess, führt die Komponententests aus und lädt die erstellten Artefakte, wenn sie erfolgreich bestanden wurden bei Sonatype Nexus und installiert sie in einer Testumgebung. Wenn in einer der Phasen ein Fehler auftritt oder Unit-Tests fehlschlagen, wird das Entwicklungsteam mithilfe des Telegramm-Plug-Ins über das Build-Ergebnis informiert. Wenn die Installation erfolgreich war, wird das QA-Team benachrichtigt, dass die Aufgabe zum Testen bereit ist.
Wenn Fehler auftreten, wird die aktuelle Version des Entwicklungszweigs heruntergeladen und aus dem Zusammenführungs-Commit des MYFEATURE-Zweigs mit dem Entwicklungszweig wird der Hotfix-MYFEATURE-Zweig erstellt (Git-Checkout [BASECOMMIT] -b Hotfix-MYFEATURE).
Beim Erstellen wird automatisch ein Checkout für den erstellten Zweig durchgeführt, Korrekturen vorgenommen und Änderungen am lokalen Zweig-Hotfix-MYFEATURE (git commit hotfix-MYFEATURE -m "Commit message") festgeschrieben. Wenn die Korrektur abgeschlossen und bereit ist, an die Testumgebung gesendet zu werden, werden sie an einen Remote-Zweig mit demselben Namen (git push -u origin hotfix-MYFEATURE) gesendet und eine Zusammenführungsanforderung mit dem Entwicklungszweig erstellt.
Um eine Zusammenführung anzufordern, löst der Entwickler Zusammenführungskonflikte (falls vorhanden) und führt eine Codeüberprüfung durch, bei der zusätzliche Commits mit Korrekturen an den empfangenen Kommentaren erstellt werden können. Nach erfolgreichem Abschluss der Überprüfung werden die Zweige zusammengeführt. Unmittelbar nach der Übertragung des Patches in den Entwicklungszweig ruft der Web Hook auch die Aufgabe in Jenkins auf, um zu erstellen, Unit-Tests auszuführen, die erstellten Artefakte in Sonatype Nexus zu laden und den Patch in der Testumgebung zu installieren. Ein ähnlicher Benachrichtigungsmechanismus funktioniert für Korrekturen.
Wenn alle Fehler behoben sind, wird die aktuelle Version des Entwicklungszweigs heruntergeladen und vom Zusammenführungs-Commit des Hotfix-MYFEATURE-Zweigs zum Entwicklungszweig wird der Release-Mn-Zweig erstellt (Start des Git-Flow-Releases RELEASENAME [BASECOMMIT]).
Durch das Erstellen eines Release-Zweigs wird auch der Start eines Web Hooks zum Aufrufen einer Aufgabe in Jenkins initialisiert, der den Quellcode von Git herunterlädt, den Namen des Release-Zweigs von Git abruft und mithilfe der Jira-API die Liste der Komponenten abfragt, die im Rahmen der Release-Aufgaben geändert wurden, und die aktuellen Versionen von Sonatype Nexus herunterlädt und setzt sie auf eine Regressionstestumgebung. Nach der Installation der Version in der Regressionstestumgebung werden Skripts ausgeführt, um die Umgebung für das Testen vorzubereiten (Neustart der Anwendung, Bereinigen der Datenbank usw.), und die Regressionstests werden ausgeführt, um den Betrieb der Hauptsystemfunktionalität zu überprüfen. Dies führt zu einem Bericht mit dem Allure Reports-Plugin für Jenkins. Nach der Installation wird das QA-Team in Telegram über die Ergebnisse des Autotest-Laufs und die Bereitschaft der Version für manuelle Regressionstests informiert.
Wenn während des Regressionstests Fehler auftreten, wird die aktuelle Version des Release-Mn-Zweigs heruntergeladen und ab dem letzten Commit wird der Hotfix / BUGNAME-Zweig mit dem Namen des Fehlers in Jira erstellt (Git Checkout -b Hotfix / BUGNAME [BASECOMMIT]).
Der erstellte Zweig wird automatisch ausgecheckt, notwendige Korrekturen vorgenommen und Änderungen am lokalen Zweig-Hotfix / BUGNAME (git commit hotfix / BUGNAME -m "Commit message") festgeschrieben. Wenn die Korrektur abgeschlossen ist und zur Übermittlung an die Regressionstestumgebung bereit ist, werden sie an einen gleichnamigen Remote-Zweig (git push -u origin hotfix / BUGNAME) gesendet und eine Zusammenführungsanforderung mit dem Zweig release-mn erstellt
Um eine Zusammenführung anzufordern, löst der Entwickler Zusammenführungskonflikte (falls vorhanden) und führt eine Codeüberprüfung durch, bei der zusätzliche Commits mit Korrekturen an den während der Codeüberprüfung erhaltenen Kommentaren erstellt werden können. Diese Commits werden auch an den lokalen Zweig-Hotfix / BUGNAME (git commit-Hotfix / BUGNAME -m „Commit-Nachricht“) gesendet und an einen Remote-Zweig mit demselben Namen (git push -u origin hotfix / BUGNAME) gesendet. Nach erfolgreichem Abschluss der Überprüfung werden die Zweige zusammengeführt. Durch die Zusammenführung wird der Start des Web-Hooks initialisiert, um die Aufgabe in Jenkins aufzurufen, ähnlich wie beim vorherigen, jedoch anders, da der Code von Git heruntergeladen, der Name des Fehlers abgerufen und mithilfe der Jira-API eine Liste der Komponenten angefordert wird, die im Rahmen des Fixes geändert wurden. Sammeln Sie diese Komponenten. lädt auf Sonatype Nexus herunter und installiert sie in einer Regressionstestumgebung. In Analogie dazu wird die Umgebung für das Autotesting vorbereitet, die Regressionsautotests werden ausgeführt und ihre Ergebnisse werden benachrichtigt.
Wenn alle Fehler behoben sind, wird die Version in einer produktiven Umgebung installiert. Führen Sie dazu den Zweig release-mn mit den Zweigen Develop und Master zusammen und erstellen Sie ein Release-Tag.
Wenn es erstellt wird, wird der Start des Web Hook gestartet, um die Aufgabe in Jenkins aufzurufen. Dabei wird der Quellcode von Git heruntergeladen, die Versionsnummer abgerufen und mithilfe der Jira-API die Liste der Aufgaben abgefragt, die in der Version enthalten waren, sowie die Komponenten, die im Rahmen dieser Aufgaben geändert wurden Dadurch wird die aktuelle Version von Artefakten aus Sonatype Nexus herausgepumpt und in einer produktiven Umgebung installiert.
Bei Hotfixes für den Verkauf wurde beschlossen, einen ähnlichen Prozess wie beim Release zu verwenden. Andernfalls gehen die Testphasen der vorgenommenen Änderungen verloren.
Bei der Implementierung des Prozesses wurden auch Schulungen für Mitarbeiter durchgeführt, die keine Erfahrung mit Git und GitLab hatten, für die ein geeignetes Schulungsprogramm entwickelt wurde. Damit können Sie selbst Schulungen zur Verwendung von Source Tree und Intellij IDEA für die Arbeit mit Git sowie GitLab zur Durchführung von Codeüberprüfungen durchführen. Im nächsten Beitrag werde ich sie mit Illustrationen ergänzen.