Heute werden wir uns ein Diagramm ansehen. Es stellt das Prinzip der kontinuierlichen Integration bei AT Internet dar:

Kontinuierliche Integration
„Kontinuierliche Integration bei AT Internet“

Die wichtigsten Prinzipien der kontinuierlichen Integration

Es handelt sich um eine Reihe von Verfahren, die entwickelt wurden, um den von Entwicklungsteams erstellten Softwarecode möglichst effektiv zu liefern. Es gibt verschiedene Ziele, darunter:

  • Beschränken manueller Aktionen durch Automatisierung von Builds, Ausspielungen und anderen Bereitstellungsvorgängen. Dies begrenzt das Risiko menschlichen Versagens und ermöglicht es Experten, sich auf ihr Produkt zu konzentrieren, anstatt ständig Zeit in sich wiederholende Operationen zu investieren, die eine Maschine für sie tun kann.
  • Die schnelle Verfügbarkeit von Feedback bietet eine gute Übersicht über die potenziellen Auswirkungen von Änderungen am vorhandenen Code. Jedes Mitglied der Entwicklungsteams kann dann in aller Ruhe Änderungen an der vorhandenen Codebasis vornehmen und sich auf die vorhandene Automatisierung verlassen, um über die ordnungsgemäße Integration des Codes in das Produkt zu informieren.

Dies betrifft die kontinuierliche Integration von neuem Code, die kontinuierliche Bereitstellung von Lieferbestandteilen und die kontinuierliche Bereitstellung von Produkten – aber wie verknüpfen Sie Quellcode, Lieferbestandteile und Umgebungen im Gesamtprozess? Hier sind einige der FAQs:

  • Wenn ich eine „Promotion“ mache, ist es die Promotion meines Codes? Oder die von Deliverables? Oder die der Umgebung?
  • Welche Verbindung besteht zwischen der Bereitstellung in der Produktion und dem Master-Branch des Code-Repositorys?
  • Welche Automatisierung kann ich implementieren, um die Konsistenz zwischen der Lebensdauer meines Code-Repositorys und der meiner Anwendung in verschiedenen Umgebungen sicherzustellen?

Diese Fragen können je nach technischem oder projektspezifischem Kontext, Tätigkeitsbereich oder Reifegrad der Prozesse im Unternehmen unterschiedlich beantwortet werden. In diesem Artikel werde ich daher versuchen, die verschiedenen Konzepte und Prinzipien zu beschreiben, ohne Abhängigkeit von einem bestimmten Werkzeug zu schaffen. Auch wenn einige Tools manchmal das Leben erleichtern können, ist es eher eine Frage des Software-Bereitstellungszyklus, unabhängig von den Mitteln, die für seine Implementierung gewählt werden.

Das Konzept „build once“

Build-once
„Kontinuierliche Intergration: build-once“

Eines der wichtigsten Prinzipien der kontinuierlichen Integration ist „einmal bauen (build once)“ oder mit anderen Worten, nur ein neues Deliverable zu erstellen, wenn der Geschäftscode geändert wurde. Diese Vorgehensweise soll das Risiko verringern, ein anderes Deliverable zu erstellen, wenn es in einer neuen Umgebung bereitgestellt wird. In der Tat muss bei der Auslieferung oft etwas komplett neu gebaut werden, um ein identisches Deliverable zu bekommen.

Aber es gibt während dieses neuen Builds immer noch Risiken (manchmal signifikant):

  • Maschinenprobleme (volle Festplatte, andere…)
  • Netzwerkprobleme
  • Problem im Zusammenhang mit dem Build-Tool (wird gewartet, nicht verfügbar, …)
  • Einbetten einer anderen Version eines der Ableger unseres Produkts
  • Unbeabsichtigte Nutzung einer anderen Version des Codes

Wir können daher, ohne es zu merken, und trotz Vorsichtsmaßnahmen, ein Produkt erhalten, das sich von dem unterscheidet, das die verschiedenen Validierungsphasen unseres Entwicklungszyklus erfolgreich durchlaufen hat. Alle Vorteile der durchgeführten Tests und Überprüfungen gehen dann verloren.

Der beste Weg, dieses Risiko zu vermeiden, besteht darin, das Deliverable nur einmal zu erstellen und es während zukünftiger Bereitstellungen und bis zur endgültigen Produktion, für die Validierungsphasen so zu verwenden, wie es ist – das ist, was als „build once“ bezeichnet wird.

Die Förderung von Deliverables

Deliverables
„Kontinuierliche Integration: Förderung von Deliverables“

Jetzt, da wir unser Deliverable haben, werden wir es einer Reihe von Tests unterziehen wollen, um seine Produktionseinführung zu validieren. Wir brauchen daher verschiedene „Regale“, um unsere Deliverables zu speichern, um sie leicht nach ihren Fortschritten in den Validierungsphasen zu identifizieren.

Diese „Regale“ können je nach Technik unterschiedliche Formen annehmen (Deliverable Manager, Liefer-Ordner, Archivierung von Artefakten, Speicherung von Docker-Images, usw.). Deren Anzahl hängt vom gewählten Lieferzyklus ab. Einige Unternehmen benötigen aus Gründen der Einhaltung bestimmter Standards, komplexer Integrationen usw. mehr Validierungs- und Integrationsphasen als andere.

Bei AT Internet haben wir uns für 4 „Regale“ entschieden um unsere Deliverables (dev, integ, preprod, prod) und eine zusätzliche (Staging) zu organisieren und um dringende Bugfixes zu ermöglichen.

Der Übergang eines Deliverable von einem Regal zum anderen wird durch die ordnungsgemäße Durchführung verschiedener Prüf- und Validierungsphasen geregelt. Wenn alle Bedingungen erfüllt sind, kann das Deliverable in das nächste Regal verschoben werden: das ist die Promotion. Einige werden einfach kopiert (anstatt bewegt); Manche Tools stellen direkt Methoden zur Verfügung um die Deliverables, die sie hosten, weiterzubringen. Wir haben so einen Überblick über die Deliverables und deren Validierungsgrad, einfach indem wir ihren Platz im Repository beobachten. Das Vorhandensein eines Deliverable in einem der Regale beschreibt auch seinen Charakter als Kandidat für eine bestimmte Umgebung. Es ist diese starke Verbindung, die manchmal zum Begriff „Umgebungs-Promotion“ führt.

Interne Umgebungen

Interne Umgebungen
„Kontinuierliche Integration: Umgebungen und deren Tests“

Sobald diese Deliverables eingeholt und irgendwo gelagert wurden, müssen sie sich den verschiedenen Test- und Validierungs-Schritten unterziehen, um entscheiden zu können, ob wir sie freigeben können oder nicht. Es ist dann notwendig, jedes Deliverable in der Umgebung bereitzustellen, für die es geeignet ist. Dann wird das Produkt in einer bestimmten Umgebung in Betrieb genommen, um dynamische Tests durchzuführen. Diese Tests werden als „Black Box“-Tests bezeichnet und sind unabhängig vom Code oder der Technologie, die für die Implementierung verwendet werden.

Entwicklung: die erste Phase der Bereitstellung

Jedes Deliverable wird dann in der Entwicklungsumgebung bereitgestellt und einer ersten Testphase unterzogen. Der erste dieser Tests besteht in der Validierung des Bereitstellungsmechanismus. Das ist das erste Mal, dass wir versuchen, dieses Deliverable irgendwo bereitzustellen. Der erfolgreiche Abschluss der Bereitstellung ist ein erster Schritt, um sicherzustellen, dass wir das Produkt ausliefern können.

Wir werden dann auf dieser Umgebung eine Reihe von Eigenschaften unseres Systems (funktional oder nicht-funktional) aber auch die Gültigkeit einiger Konfigurationen unserer Lieferbestandteile validieren. Wenn alles in Ordnung ist, können wir das Deliverable promoten und es in der nächsten Umgebung für die Integrationsphase bereitstellen.

Integration: Alle Szenarien validieren

In dieser Phase wird das isoliert validierte System mit den anderen Systemen der Softwarelösung in Kontakt gebracht. Es kann dann in der Systemintegrations-Testphase verwendet werden, die darauf abzielt, Use Cases durchzuführen, die mehrere Systeme mit einbeziehen, um die korrekte Verbindung der verschiedenen Elemente der Lösung zu validieren.

Jedes Mal, wenn die Validierung in der Entwicklungsumgebung erfolgreich ist, kann diese Integrationsumgebung aktualisiert werden.

Vorproduktion: Generalprobe

In der Vorproduktion führen wir eine letzte Phase der Tests durch, bevor wir in die Produktion gehen, wobei wir nur die Funktionen bereitstellen, die wir mit der nächsten Version veröffentlichen möchten. Diese Entscheidung ist kein notwendiger Schritt und hängt häufig mit einer Marketing- oder Marktentscheidung zusammen.

In dieser Umgebung handelt es sich häufig um Empfangs- und Abnahmevorgänge, die nicht dazu bestimmt sind, Fehler im Produkt zu erkennen. Wenn Fehler in diesem Stadium gefunden werden, ist dies oft ein Zeichen für einen Mangel an Tests in einem der vorherigen Schritte.

Wenn das Deliverable in der Produktion nicht mit Kundenkommunikations- oder Supporteinschränkungen verknüpft ist, ist es durchaus möglich, statt mehrerer Integrations- und Vorproduktionsumgebungen nur eine „Vorproduktionsumgebung“ zu haben. Wir akzeptieren dann die Einschränkung (oder den Vorteil), dass der gesamte validierte Code direkt in die Produktion geht, wenn er die folgenden Validierungsschritte erfolgreich durchläuft.

Staging

Staging ermöglicht es in der Produktion eine Korrektur schnell zu validieren. Der aktuelle Produktionscode wird in dieser Umgebung bereitgestellt, wobei nur die Korrektur als Änderung vorgenommen wird, um die korrekte Korrektur des festgestellten Problems zu überprüfen. Es wird auch geprüft, ob es bei dieser Produktveränderung auch Nebenwirkungen (Regressionen) gibt.

Produktion

Einige Tests eines anderen Typs können während der Produktion stattfinden, die oft als „Post-Deployment-Tests“ bezeichnet werden. Es geht dabei um Aspekte im Zusammenhang mit der Umgebung, spezifischen Konfigurationen, Überwachungssysteme oder das, was ich funktionale Experimente nennen würde (Schnelltests, A/B-Tests, Feature-Flipping).

In diesem Stadium besteht das Ziel nicht darin, Fehler in einem der beteiligten Systeme zu erkennen (auch wenn dies passieren kann!)

Lieferautomatisierung

Jenkinsfile

Durch diese Maßnahmen soll die Auslieferung eines Software-Produkts systematisch und nach einem einheitlichen Schema ablaufen. Es ist daher normal, darüber nachzudenken, all das zu automatisieren. Natürlich stehen verschiedene Werkzeuge zur Verfügung, um diese Vorgehensweise einzurichten (Jenkins, Travis CI, GitlabCI usw.), aber die Prinzipien sind unabhängig von der Wahl dieses Werkzeugs. Über die wesentlichen Schritte dieser Automatisierung hinaus (rechts auf dem Bild, das mit dem Artikel verknüpft ist) ist es mir wichtig, ein paar Details hervorzuheben:

  • Veröffentlichung: Es ist die Hinterlegung des Deliverable in einem der „Regale“ für seine zukünftige Bereitstellung in einer der Umgebungen. Das gewählte Regal hängt vom in Betracht gezogenen Code-Branch ab. Hier sind die identifizierten Publikationspfade:
    • „develop“ Branch=> Liefert Kandidaten für die „Entwicklungs“-Umgebung“
    • Release‘ Branch => Deliverables für die Vorproduktions-Umgebung
    • Hotfix‘ Branch => Deliverables für die Staging-Umgebung
    • Alle anderen Fälle => keine Veröffentlichung des Deliverable (es kann wenn gewünscht immer noch für Tests aufgerufen werden)
  • Der Schritt der Promotion kann genutzt werden um verschiedene Vorgänge zu automatisieren. (Einige ziehen es vor, die Kontrolle über diese Vorgänge zu behalten oder sie in den nächsten Schritt zu integrieren: die Bereitstellungsphase)
    • Integrations-Promotion > Vorproduktion
      • Zusammenführen des Codes von „develop“ zu „release“
      • die Nebenversion aufwerten und die Patch-Version von ‚0‘ auf ‚entwickeln‘ zurücksetzen.
    • Vorproduktions-Promotion > Produktion
      • Zusammenführen des Freigabecodes zum Master
      • einen Tag auf ‚master‘ anwenden.
    • Promotion-Staging > Produktion
      • Zusammenführen des Codes von „hotfix“ zu „master“
      • einen Tag auf ‚master‘ anwenden.
  • Bei AT Internet verwenden wir Jenkins. In den Teams wird oft folgende Frage gestellt: Sollen wir das alles in einem großen Job oder in mehreren separaten Jobs organisieren? Die Antwort liegt irgendwo dazwischen und hängt von Ihren Fortschritten bei der Umsetzung der verschiedenen Schritte der kontinuierlichen Integration ab. Einige Grundsätze sind jedoch zu beachten:
    • Der Einsatz eines vorhandenen Deliverable muss jederzeit möglich sein, unabhängig von der Entwicklung der Konstruktion dieses Deliverable.
    • Die Einführung bestimmter Tests in einer bestimmten Umgebung muss jederzeit möglich sein, ohne dass man dabei vom Konstruktionsfortschritt und der Promotion der Deliverables abhängig ist.

Diskontinuierliche Integration

Diskontinuierliche Integration: manuelle Aktionen im Fluss“

Der ideale Flow, der eine kontinuierliche Lieferung in die Produktion ermöglicht, erfordert eine bestimmte Anzahl von Automatismen und Werkzeugen. Sie sind Sicherheitsvorkehrungen, die es ermöglichen, Produkte schrittweise zu validieren, bis sie in Produktion gehen. Einige Elemente fehlen oft in der Kette. Damit kann man Skripten und anderen Testrobotern nicht die volle Verantwortung für die „Entscheidung“ übertragen ob etwas in Produktion geht. Hier ist die Reihenfolge, in der diese Elemente während Forschung und Entwicklung oft zu finden sind:

  1. Bau des Deliverable (Build)
  2. Komponententests
  3. Bereitstellungsskripts
  4. Codequalität
  5. Auslösen von Tests
  6. Promotions-Mechanismen

Wenn eines oder mehrere dieser Elemente fehlen, muss der Vorgang manuell durchgeführt werden. Die restlichen Operationen werden dann auch manuell ausgelöst, wenn Automatismen vorhanden sind, um fortzufahren. Wir befinden uns dann in einer Situation, die ich als unkontinuierliche Integration bezeichnen würde.

Bei einer höheren Reifegrad-Ebene sind alle Vorgänge automatisiert, aber wir sind noch nicht bereit, ganz auf manuelle Aktionen zum Auslösen von Produktionsfreigaben zu verzichten. Dies ist häufig der Fall, wenn alle Mechaniken verfügbar sind, aber die Tests auf den verschiedenen Umgebungen zu begrenzt sind. Wir müssen uns noch mit ein paar manuellen Maßnahmen versichern, um unser Vertrauen zu erhöhen. Bis zu dem Tag, an dem wir froh erkennen können, dass wir nur eingreifen, um weitere Operationen auszulösen und das abhängig von dem Status, der von einigen Systemen angezeigt wird. Wir können diese Operation dann mit dem restlichen Ablauf verknüpfen, weil unser Handeln keinen Mehrwert mehr bringt. Um in diese Phase der kontinuierlichen Bereitstellung zu gehen, müssen gute Produktionsüberwachungssysteme auch sicher sein, dass das System widerstandsfähig gegen einen Fehler ist, der die verschiedenen Validierungsschritte durchlaufen hat, ohne erkannt zu werden. Darum können wir uns in einem späteren Artikel kümmern!

Author

Mit über 10 Jahren Erfahrung mit Software-Testing-Strategie und Implementierungen in einem agilen Umfeld ist Alexandre dafür verantwortlich die Entwicklungen bei AT Internet voranzutreiben. Seine tägliche Herausforderung: Unsere Entwicklungsteams bei der Implementierung von Tools und Methoden anzuleiten. Das Ziel ist es regelmäßige Veröffentlichungen mit hoher Qualität für unsere Kunden zu garantieren.

Comments are closed.