End-to-End-Pipeline-Automatisierung und Governance (Teil 2 von 2)

Dieser Blog-Beitrag ist der zweite Teil einer Serie, die darauf abzielt, eine Reihe von Herausforderungen vorzustellen, mit denen Unternehmen im Zusammenhang mit der modernen Integrationsentwicklung konfrontiert sind, und zu zeigen, wie Sie diese Herausforderungen mit SnapLogic leicht bewältigen können. Sie finden Teil 1 dieser Serie finden Sie hier.

In diesem Artikel erfahren Sie, wie die SnapLogic-Plattform Ihnen hilft, effizient

• Durchführung von Qualitätskontrollen mit Einheitstests und Einhaltung von Richtlinien
• Zusammenführungsantrag verwalten
• Förderung von Änderungen in der Produktion und Benachrichtigung der Beteiligten

Erstellung von Merge-Anfragen

Nachdem ein Integrator eine Lösung für ein Problem gefunden hat, muss er in einem letzten Schritt Integrator einen Antrag auf Zusammenführung in GitLab, um zu beantragen, dass die Änderungen vom Master-Zweig in den Prod-Zweig zusammengeführt werden.

Hinweis: Dieser Blogeintrag wird direkt von der Master-Verzweigung in die Prod-Verzweigung verschoben, d. h., die Assets werden von der Entwicklungsumgebung in die Produktionsumgebung übertragen. Dies entspricht nicht notwendigerweise den Best Practices für die Organisationsstrukturen und Richtlinien aller Kunden.

Prüfungen von Zusammenführungsanträgen

Nach der Erstellung der Zusammenführungsanforderung führt GitLab automatisch eine CI/CD-Pipeline die aus zwei Jobs besteht; runTests und runChecks. Damit dies funktioniert, muss der CI/CD-Ingenieur (bitte lesen Sie den Teil 1 in dieser Serie) eine GitLab CI/CD-Konfigurationsdatei erstellt. Die CI/CD-Konfigurationsdatei (siehe unten) führt die folgenden Aufgaben aus:

• runTests
  • Läuft nur für Merge Requests
  • Läuft in der ersten Stufe namens Test
  • Führt das Skript runTests.sh aus
• runChecks
  • Läuft nur für Merge Requests
  • Läuft in der zweiten Stufe namens prüft
  • Führt das Skript runChecks.sh aus
• runPromotion
  • Läuft nur für Änderungen im Prod-Zweig
  • Läuft in der dritten Stufe namens fördern
  • Führt das Skript runPromotion.sh aus

 

Hinweis: In diesem Blog-Beitrag werden zwar die Funktionen von GitLab für CI/CD verwendet, es ist jedoch wichtig zu verstehen, dass aufgrund der REST- und JSON-Unterstützung der SnapLogic-Plattform die Erstellung ähnlicher Aufträge in anderen Tools wie Azure DevOps, GitHub, Bamboo usw. der gleichen Logik und Technik folgt. 

Wie bereits erwähnt, ist der CI/CD-Ingenieur nur zwei Jobs konfiguriert, die bei der Erstellung eines Merge Request ausgeführt werden: runTest und runChecksund sie werden in dieser Reihenfolge ausgeführt. Untersuchen wir zunächst, was passiert, wenn der erste Auftrag (runTests) ausgeführt wird und das Skript runTests.sh (siehe unten) ausgeführt wird. Zunächst wird ein SnapLogic Triggered Task namens RunUnitTests Task ausgeführt. Anschließend wird geprüft, ob das Ergebnis erfolgreich war oder nicht, und je nach Ergebnis wird die gesamte CI/CD-Pipeline entweder bestanden oder nicht bestanden.

Der RunUnitTests-Task führt eine Pipeline namens RunUnitTests aus, wie unten dargestellt. Diese Pipeline führt Folgendes aus

1. Listet alle Pipelines im betroffenen Projekt auf
2. Filtert Pipelines aus, die nicht Gegenstand von Einheitstests sind
3. Führt für jede Pipeline die Pipeline 01_UnitTestingTemplate mit dem Pipeline-Ausführungs-Snap aus (gekennzeichnet als Run test)
4. Filtert erfolgreich getestete Ergebnisse heraus
5. Vergleicht die Anzahl der erfolgreichen Tests mit der Anzahl der gesamten Tests und erstellt dann eine Antwort an den Kunden, in der die Anzahl der abgeschlossenen und fehlgeschlagenen Tests angegeben ist.

Wie bereits erwähnt, ermittelt die RunUnitTests-Pipeline, welche Pipelines getestet werden sollen, und sendet die Testergebnisse an den Client zurück, führt die Tests aber nicht selbst aus. Stattdessen ruft sie die Pipeline 01_UnitTestingTemplate für jede zu testende Pipeline auf. Diese Pipeline ist unten zu sehen. Sie führt Folgendes aus.

1. Reads the expected results (parameterized as <Pipeline_name>_result.json) – in our case from the file CustomerToSalesforce_result.json (see previous chapters). 
2. Read the input test data (parameterized as <Pipeline_name>_input.json) – in our case from the file CustomerToSalesforce_input.json (see previous chapters). 
3. Executes the target Pipeline (parameterized as <Pipeline_name>_target) – in our case from the file CustomerToSalesforce_target (see previous chapters) using the Pipeline Execute Snap (labelled as Test Pipeline)
4. Verwendet die Diff-Snap um die erwarteten Ergebnisdaten mit den tatsächlichen Ergebnissen auf der Grundlage der ausgeführten Pipeline zu vergleichen (CustomerToSalesforce_target mit den CustomerToSalesforce_input.json-Testdaten). Der Diff-Snap gibt jede Zeile entweder als Löschung, Einfügung, geändert oder nicht geändert aus. Nur wenn alle Zeilen nicht geändert wurden (als Erfolg gekennzeichnete Ansicht), gilt der Test als bestanden.
5. Gibt das Ergebnis des einzelnen Tests an die übergeordnete Pipeline zurück (RunUnitTests)

Der obige Prozess und die Pipelines wurden von der Testleitung und CI/CD-Ingenieur sowie dem gesamten Integrationsteam auf der Grundlage der Anforderungen und Richtlinien in ACME vereinbart. Es kann auch andere Tests geben - wie Leistungstests und funktionale Tests, die für diesen Posten nicht in Frage kommen.

Hinweis: Das Ergebnis der Unit-Tests und der Qualitätsprüfungen werden Sie später in diesem Blogbeitrag sehen.

Wenn alle Tests bestanden sind und das Skript runTests.sh erfolgreich war, wird der nächste Schritt und Auftrag (runChecks) in der GitLab CI/CD-Konfiguration ausgeführt, indem das Skript runChecks.sh aufgerufen wird. Das runChecks Job wurde zwischen dem CI/CD-Ingenieur und dem Sicherheitschef. Die Sicherheitschef verlangt, dass eine Reihe von Regeln und Richtlinien auf die Pipelines und andere SnapLogic-Assets angewandt werden, die in Betrieb genommen werden sollen. Diese Richtlinien könnten Folgendes umfassen

• Namenskonventionen für Pipelines, Fangbeschriftungen oder andere Eigenschaften
• Verbotene Schnappschüsse
• Verbotene Einstellungen in Snaps

Für ACME stellt der Sicherheitsverantwortliche die folgenden Richtlinien zur Verfügung (definiert im JSON-Format)

[

    {

        "class": "com-snaplogic-snaps-transform-recordreplay",

        "bedingt": false

    },

    {

        "class": "com-snaplogic-snaps-binary-aesencrypt",

        "bedingt": wahr,

        "Einstellungen": [

            {

                "Name": "cipherMode",

                "allowedValue": "CBC"

            }

        ]

    }

]

Mit der oben genannten Politik wird Folgendes beabsichtigt

• Vermeiden Sie jegliche Verwendung des Record Replay Snap in der Produktions-Organisation. ACME ist ein stark geprüftes Unternehmen, das es nicht zulassen kann, dass Kundendaten auf einem dauerhaften Speicher abgelegt werden. 
• Vermeiden Sie die Verwendung des AES-Verschlüsselung Snap wenn die Einstellung des Verschlüsselungsmodus nicht auf CBC eingestellt ist. ACME hat eine unternehmensweite Sicherheitsrichtlinie, die besagt, dass beim Verschlüsseln nur der CBC-Modus verwendet werden darf.

Diese Richtlinie bedeutet, dass alle Record Replay-Snaps oder alle AES Encrypt-Snaps (ohne CBC als Verschlüsselungsmodus) in der Produktion nicht zulässig sind. Um dies zu erreichen, ruft das runChecks.sh-Skript einen SnapLogic Triggered Task auf, um die betroffenen Pipelines mit dem Richtliniendokument zu vergleichen und den Job fehlschlagen zu lassen, wenn er gegen die Richtlinien verstößt. Das runChecks.sh-Skript ist unten zu sehen.

Der durch das Skript runChecks.sh ausgelöste Task RunQualityChecks führt die RunQualityChecks-Pipeline aus, die unten zu sehen ist. Ihre Logik ähnelt der der zuvor gezeigten RunUnitTests-Pipeline.

1. Listet alle Pipelines im betroffenen Projekt auf
2. Führt für jede Pipeline die Pipeline 01_QualityCheck mit dem Pipeline-Execute-Snap aus (gekennzeichnet als Check Quality)
3. Berechnet die Anzahl der erfolgreichen Pipelines
4. Vergleicht die Anzahl der erfolgreichen Prüfungen mit der Anzahl der gesamten Prüfungen und erstellt dann eine Antwort an den Kunden, die die Anzahl der abgeschlossenen und der fehlgeschlagenen Prüfungen sowie den Grund für das Fehlschlagen der Tests enthält.

Ähnlich wie unsere Unit-Test-Pipelines ermittelt die RunQualityChecks-Pipeline, für welche Pipelines Prüfungen durchgeführt werden sollen, und sendet die Prüfergebnisse an den Client zurück, führt aber die Qualitätsprüfungen selbst nicht aus. Stattdessen ruft sie die Pipeline 01_QualityCheck für jede Pipeline auf, für die Qualitätsprüfungen durchgeführt werden sollen. Diese Pipeline ist unten zu sehen. Sie führt Folgendes aus.

1. Liest die Pipeline, die einer Qualitätskontrolle unterliegt
2. Extrahiert alle Snaps, die in der Pipeline verwendet werden. Da SnapLogic eine native JSON-Plattform ist, sind die Snaps und ihre Eigenschaften einfach JSON-Objekte.
3. Liest und parst das ACME Policy JSON Dokument, das von der Sicherheitsbeauftragten.
4. Verbinden Sie die Snaps mit den Snaps in der Richtlinie, um sicherzustellen, dass nur Snaps geprüft werden, die in der Richtlinie übereinstimmen. 
5. Prüft, ob ein Snap erlaubt ist oder nicht
6. Prüft, ob ein Snap bedingt erlaubt ist oder nicht (z.B. die Einstellungen sind erlaubt)
7. Erstellt eine Antwort mit den Ergebnissen zurück an die übergeordnete Pipeline

Wenn die Qualitätsprüfungen bestanden sind (nachdem die Einheitstests bestanden wurden), kann der Zusammenführungsantrag genehmigt werden.

Genehmigung von Zusammenführungsanträgen

Die Architekt ist nun für die Überprüfung des Merge Request verantwortlich. Wenn die Änderungen sinnvoll sind und die automatischen Einheitstests und Qualitätsprüfungen bestanden wurden, wird der Architekt die Anfrage genehmigen und zusammenführen. Er beginnt mit dem Öffnen des Merge Request (siehe unten), der gerade angehoben wurde, um die Zusammenfassung des Inhalts zu sehen

• Der Titel der Zusammenführungsanforderung wurde auf den Titel der einzelnen Git-Übertragung festgelegt.
• Der Merge Request enthält eine einzelne Übergabe
• Der einzelne Commit enthält drei Änderungen; 1 geänderte Datei und 2 Ergänzungen
• Eine CI/CD-Pipeline mit einer Zusammenführungsanforderung wird gerade ausgeführt (angezeigt durch das blaue Fortschrittssymbol)
• Es gibt eine Option zur Zusammenführung der Anfrage, wenn die Pipeline erfolgreich war 

Bevor die Änderungen des Zusammenführungsantrags geprüft werden, wird die Pipeline mit der folgenden Zusammenfassung der Phasen/Aufgaben abgeschlossen. Wie zu sehen ist, werden die runTetsts Job erfolgreich abgeschlossen. Die anschließenden runChecks Auftrag nicht. Wir können beide Aufträge untersuchen, um zu verstehen, was passiert ist.

Öffnen wir zunächst die Datei runTests Auftrag, um die Zusammenfassung zu sehen. Wie Sie unten sehen können, wurden die Tests erfolgreich abgeschlossen.

Zweitens wollen wir uns die Zusammenfassung des Auftrags runChecks ansehen. Im Gegensatz zur runTests-Zusammenfassung ist dieser Auftrag nicht vollständig. Er besagt, dass die Qualitätsprüfungen nicht erfolgreich abgeschlossen wurden. Von den drei geprüften Pipelines (CustomerToSalesforce, CustomerToSalesforce_target und CustomerToSalesforce_test) ist eine der Pipelines fehlgeschlagen - die CustomerToSalesforce_target Pipeline. Wenn Sie sich das Design dieser Pipeline ansehen, das weiter oben in diesem Beitrag gezeigt wurde, können Sie erkennen, dass wir einen Record Replay Snap verwendet haben, um uns bei der Entwicklung zu helfen. Gemäß den Richtlinien, die vom Sicherheitschefist dies in der Produktion nicht erlaubt.

Die Architekt kann sich nun mit dem Integrator synchronisieren, um das Problem durchzugehen - falls es nicht bereits vom Integrator durch eine Warnung. Da der Änderungsprozess bereits in diesem Blog-Beitrag behandelt wurde, gehen wir nun davon aus, dass eine neue Iteration mit einer geänderten Übergabe und einem aktualisierten Merge Request durchgeführt wurde, wobei der Record Replay Snap entfernt wurde. Die Ausgabe des runChecks-Jobs sieht nun wie folgt aus.

Schließlich ist der Architekt die Änderungen mit zwei Methoden überprüfen. Bei der ersten Methode kann er die Änderungen in der JSON-Struktur zwischen den beiden Versionen der CustomerToSalesforce-Pipeline überprüfen und verstehen, welche Snaps und Eigenschaften geändert wurden. Zweitens kann er mit der SnapLogic Pipeline vergleichen Funktion verwenden, um einen visuellen Vergleich zwischen der alten und der neuen Version der Pipeline zu erhalten. Wie in der Abbildung unten zu sehen ist, wurde ein Pipeline Execute Snap hinzugefügt, um die Transformations- und Validierungslogik von der Pipeline selbst zu abstrahieren und so Unit-Tests zu ermöglichen.

Nach der Überprüfung der Änderungen und der Bestätigung, dass die Einheitstests und Qualitätsprüfungen bestanden wurden, wird der Architekt die Änderungen zu genehmigen und den Merge Request zusammenzuführen. Als Ergebnis werden die neuesten Änderungen nun in den Prod-Zweig verschoben.

Beförderung zur Produktion + Ticket aufgelöst

Als letzter Schritt im Rahmen des ACME-End-to-End-Szenarios sollten die neuen Pipeline-Änderungen, die im Prod-Zweig zusammengeführt wurden, nun automatisch in den SnapLogic Produktion Umgebung übertragen werden. Wie bereits erwähnt, kann das direkte Verschieben von einer Entwicklung zu einer Produktionsumgebung Umgebung zu wechseln, ist nicht unbedingt der beste Ansatz, da in der Regel empfohlen wird, zuvor eine Staging-Umgebung wie eine QA- oder Testumgebung zu verwenden. Für die Zwecke dieses Blogbeitrags bewegen wir uns jedoch von der Entwicklung auf Produktion direkt. Wenn die Änderungen in die Produktionwollen wir auch das Ticket automatisch schließen und dabei hervorheben, wie das Problem gelöst wurde. Alle diese Schritte wurden gemäß der Vereinbarung zwischen dem CI/CD-Ingenieur und Betrieb.

Die GitLab-Pipeline verfügte über einen dritten Auftrag namens runPromotion. Zur Auffrischung: Er erledigt folgende Aufgaben:

• runPromotion
• • Läuft nur für Änderungen im Prod-Zweig
  • Läuft in der dritten Stufe namens fördern
  • Führt das Skript runPromotion.sh aus

Da die Merge Request Merge-Aktion, die vom Architekt die Änderungen in den Prod-Zweig verschoben hat, wird die runPromotion Job automatisch ausgeführt. Wenn er ausgeführt wird, sieht der komplette Ablauf des Merge Request wie unten dargestellt aus. Die folgenden Schritte sind in der Abbildung unten zu sehen.

1. Ein Antrag zum Verschieben von Änderungen zwischen Master- und Prod-Zweig wurde erstellt
2. Eine CI/CD-Pipeline hat sich bewährt (dabei wurden Unit-Tests und Qualitätsprüfungen durchgeführt)
3. Der Antrag wurde von der Kommission genehmigt und zusammengeführt. Architekt
4. Eine weitere CI/CD-Pipeline hat bestanden (dies ist die Beförderungspipeline)

Prüfen wir nun die Ausgabe des letzten Promotionsauftrags, der das Skript runPromotion.sh ausführt. Wie Sie unten sehen können, hat der Job die 3 Pipelines erfolgreich in die Produktion org. Eine von ihnen wurde aktualisiert, während die beiden anderen noch nicht existierten und neu erstellt werden mussten. Wenn es sich um neu entwickelte Pipelines gehandelt hätte, wäre in allen Ergebnissen "Created" angegeben worden.

Wie haben sich die Pipelines eigentlich von der Entwicklung zur Produktion Umgebung? Werfen wir einen Blick auf den Inhalt des Skripts runPromotion.sh. Es führt den RunPromotion Triggered Task aus und übergibt die Commit-Nachricht der eigentlichen Übergabe - in unserem Fall enthält diese Commit-Nachricht die JIRA-Ticket-Referenznummer.

Die Aufgabe RunPromotion Triggered Task ruft die RunPromotion-Pipeline auf, die unten zu sehen ist. Sie führt die folgenden Schritte aus.

1. Liest den aktuellen Platz (ACMEissues) in der Entwicklung Umgebung (wo sich die neuen Pipelines befinden) sowie das aktuelle Projekt (CRM_MIGRATION)
2. Wenn dieser Raum und dieses Projekt nicht in der Produktion Umgebung existieren, werden sie erstellt
3. Listet alle Pipelines im Quellprojekt auf und ruft die Pipeline 01_PromotePipeline für jede Pipeline auf, wobei der Pipeline-Ausführungs-Snap verwendet wird (als Promote Pipeline beschriftet)
4. Erstellt eine Antwort an den Client, wenn die Pipeline 01_PromotePipeline erfolgreich war
5. Übergänge und Aktualisierungen des zugehörigen JIRA-Tickets (das mithilfe eines regulären Ausdrucks aus der Commit-Nachricht des GitLab-Commits extrahiert wurde)
6. Sendet eine E-Mail an Betrieb mit dem Ergebnis

Wie bereits erwähnt, wird für jede Pipeline, die im Quellprojekt gefunden wird, 01_PromotePipeline aufgerufen. Diese Pipeline ist unten zu sehen und führt Folgendes aus

1. Liest die Pipeline aus dem Quellprojekt (in der Entwicklung Umgebung)
2. Erzeugt es im Zielprojekt (in der Produktion Umgebung), wenn es nicht existiert
3. Oder aktualisiert es im Zielprojekt (in der Produktion Umgebung), wenn es bereits existiert
4. Formatiert eine Antwort zurück an die übergeordnete Pipeline

Damit wurden die Änderungen nun in die Produktion Umgebung übertragen und das JIRA-Ticket wurde geschlossen. Die folgende E-Mail wurde automatisch an die Betriebmit einem Link zu dem aktualisierten Ticket.

Als Teil von SnapLogic wurde das Problem in die Erledigt Status überführt, wird dem Ticket automatisch ein Kommentar hinzugefügt, der angibt, welche Pipelines an der Lösung des Problems beteiligt waren.

Zusammenfassung

In diesem Blog-Beitrag wurde gezeigt, wie ein fiktives ACME-Unternehmen und Personas effizient Automatisierungs-, Versionierungs- und Helpdesk-Tools von Drittanbietern nutzen können, um ein durchgängiges SnapLogic Pipeline-Lebenszyklusmanagement bereitzustellen. 

Da dies ein langer Beitrag ist, hier die Themen und Prozesse, die wir in diesem Blogbeitrag behandelt haben. 

Mit der SnapLogic-Plattform können Sie

• Automatische Erfassung von Fehlern in der Produktionspipeline
• Automatische Erstellung von Helpdesk-Tickets mit detaillierten Informationen über den Fehler
• Lassen Sie Integratoren und Architekten gemeinsam an der Versionskontrolle und Überprüfung der Arbeit in mehreren SnapLogic-Umgebungen arbeiten.
• Automatisierung von Einheitstests und Qualitätsprüfungen zur Einhaltung der Unternehmensrichtlinien
• Automatisieren Sie Migrationen und Promotionen, um sicherzustellen, dass die richtigen Assets in den SnapLogic-Umgebungen des Unternehmens bewegt werden.
• Die Nutzung einer nativen REST- und JSON-Plattform hilft, jeden Aspekt des Lebenszyklus zu automatisieren und zu steuern.

Die Personas, Prozesse, Richtlinien und Tools, die in diesem Blogbeitrag vorgestellt werden, lassen sich leicht an die Bedürfnisse jedes Unternehmens anpassen. Wenn Ihr Unternehmen noch keinen Zugang zur SnapLogic Intelligent Integration Platform hat, melden Sie sich für eine kostenlose Testversion noch heute!