Eine Einführung in die kontinuierliche Integration, Bereitstellung und Bereitstellung

Eine der wichtigsten Methoden bei der kontinuierlichen Integration ist es, kleine Veränderungen zu fördern. Entwickler sollten üben, größere Arbeiten in kleine Stücke zu zerlegen und diese frühzeitig zu begehen. Spezielle Techniken wie das Verzweigen nach Abstraktion und Feature-Flags (siehe unten) helfen dabei, die Funktionalität des Hauptzweigs vor laufenden Codeänderungen zu schützen.

Kleine Änderungen minimieren die Möglichkeit und die Auswirkung von Integrationsproblemen. Durch die frühestmögliche Einbindung in den gemeinsamen Zweig und die kontinuierliche Weiterentwicklung werden die Integrationskosten gesenkt und die nicht zusammenhängende Arbeit regelmäßig synchronisiert.

Bei der stammbasierten Entwicklung wird in regelmäßigen Abständen im Hauptzweig des Repository gearbeitet oder wieder in das gemeinsam genutzte Repository integriert. Kurzlebige Feature-Zweige sind zulässig, sofern sie geringfügige Änderungen darstellen und so bald wie möglich wieder zusammengeführt werden.

Die Idee hinter der stammbasierten Entwicklung besteht darin, große Commits zu vermeiden, die gegen das oben diskutierte Konzept kleiner, iterativer Änderungen verstoßen. Der Code steht Peers frühzeitig zur Verfügung, damit Konflikte gelöst werden können, wenn ihr Umfang gering ist.

Freigaben werden vom Hauptzweig oder von einem speziell für diesen Zweck aus dem Trunk erstellten Freigabezweig durchgeführt. In den Veröffentlichungszweigen findet keine Entwicklung statt, um den Fokus auf den Hauptzweig als einzige Quelle der Wahrheit zu behalten.

Jeder der Prozesse basiert auf automatisiertem Erstellen und Testen, um die Richtigkeit zu überprüfen. Da die Erstellungs- und Testschritte häufig ausgeführt werden müssen, müssen diese Prozesse unbedingt optimiert werden, um den Zeitaufwand für diese Schritte zu minimieren.

Erhöhte Build-Zeiten sollten als Hauptproblem behandelt werden, da die Auswirkungen durch die Tatsache, dass jedes Commit einen Build startet, noch verstärkt werden. Da kontinuierliche Prozesse die Entwickler dazu zwingen, sich täglich auf diese Aktivitäten einzulassen, lohnt es sich, die Reibung in diesen Bereichen zu verringern.

Wenn möglich, können verschiedene Abschnitte der Testsuite parallel ausgeführt werden, um den Build schneller durch die Pipeline zu bewegen. Es sollte auch darauf geachtet werden, dass der Anteil jedes Testtyps sinnvoll ist. Unit-Tests sind in der Regel sehr schnell und erfordern nur minimalen Wartungsaufwand. Im Gegensatz dazu sind automatisierte System- oder Abnahmetests häufig komplex und bruchanfällig. Um dies zu berücksichtigen, ist es oft eine gute Idee, sich stark auf Komponententests zu verlassen, eine angemessene Anzahl von Integrationstests durchzuführen und sich dann von der Anzahl späterer, komplexerer Tests abzuwenden.

Da eine Continuous Delivery- oder Bereitstellungsimplementierung die Freigabeberechtigung testen soll, ist es wichtig, die Konsistenz während jedes Schritts des Prozesses aufrechtzuerhalten - des Builds selbst, der Bereitstellungsumgebungen und des Bereitstellungsprozesses selbst:

Die Trennung der Bereitstellung von Code von der Freigabe für Benutzer ist ein äußerst wichtiger Bestandteil der kontinuierlichen Bereitstellung. Code kann für die Produktion bereitgestellt werden, ohne ihn zunächst zu aktivieren oder für Benutzer zugänglich zu machen. Anschließend entscheidet die Organisation, wann neue Funktionen oder Features unabhängig von der Bereitstellung freigegeben werden sollen.

Dies gibt Organisationen ein hohes Maß an Flexibilität, indem Geschäftsentscheidungen von technischen Prozessen getrennt werden. Befindet sich der Code bereits auf den Servern, ist die Bereitstellung kein heikler Teil des Freigabeprozesses mehr, wodurch die Anzahl der Personen und der Arbeitsaufwand zum Zeitpunkt der Freigabe minimiert werden.

Es gibt eine Reihe von Techniken, mit denen Teams den für eine Funktion verantwortlichen Code bereitstellen können, ohne ihn freizugeben. Feature-Flags richten bedingte Logik ein, um zu prüfen, ob Code basierend auf dem Wert einer Umgebungsvariablen ausgeführt werden soll. Durch Verzweigung nach Abstraktion können Entwickler Implementierungen ersetzen, indem sie eine Abstraktionsschicht zwischen Ressourcenkonsumenten und -anbietern platzieren. Eine sorgfältige Planung, um diese Techniken zu integrieren, gibt Ihnen die Möglichkeit, diese beiden Prozesse zu entkoppeln.

Bei Rauchprüfungen handelt es sich um eine spezielle Art von Erstprüfungen, mit denen eine grundlegende Funktionalität sowie einige grundlegende Implementierungs- und Umgebungsbedingungen sichergestellt werden sollen. Rauchtests werden im Allgemeinen zu Beginn eines jeden Testzyklus als Plausibilitätsprüfung durchgeführt, bevor eine vollständigere Testsuite ausgeführt wird.

Die Idee hinter dieser Art von Test ist, zu helfen, große rote Fahnen in einer Implementierung zu erkennen und auf Probleme aufmerksam zu machen, die darauf hindeuten könnten, dass weitere Tests entweder nicht möglich oder nicht sinnvoll sind. Rauchtests sind nicht sehr umfangreich, sollten aber extrem schnell sein. Wenn eine Änderung einen Rauchtest nicht besteht, ist dies ein frühes Signal dafür, dass wichtige Behauptungen gebrochen wurden und dass Sie keine Zeit mehr für Tests aufwenden sollten, bis das Problem behoben ist.

Zu Beginn jeder neuen Phasenprüfung können kontextspezifische Rauchprüfungen durchgeführt werden, um sicherzustellen, dass die Grundannahmen und -anforderungen erfüllt sind. Beispielsweise können Rauchtests sowohl vor dem Integrationstest als auch vor der Bereitstellung auf Staging-Servern verwendet werden. Die zu testenden Bedingungen sind jedoch von Fall zu Fall unterschiedlich.

Unit-Tests sind dafür verantwortlich, einzelne Code-Elemente isoliert und zielgerichtet zu testen. Die Funktionalität einzelner Funktionen und Klassen wird eigenständig getestet. Alle externen Abhängigkeiten werden durch Stub- oder Mock-Implementierungen ersetzt, um den Test vollständig auf den fraglichen Code zu konzentrieren.

Unit-Tests sind unerlässlich, um die Korrektheit einzelner Codekomponenten auf interne Konsistenz und Korrektheit zu prüfen, bevor sie in komplexere Kontexte gestellt werden. Der begrenzte Umfang der Tests und die Beseitigung von Abhängigkeiten erleichtern die Fehlersuche. Es ist auch die beste Zeit, um eine Vielzahl von Eingaben und Code-Zweigen zu testen, die später möglicherweise nur schwer zu erreichen sind. Häufig sind Unit-Tests nach Rauchprüfungen die ersten Tests, die ausgeführt werden, wenn Änderungen vorgenommen werden.

Unit-Tests werden in der Regel von einzelnen Entwicklern auf ihrem eigenen Arbeitsplatz ausgeführt, bevor Änderungen übermittelt werden. Continuous Integration Server führen diese Tests jedoch fast immer wieder aus Sicherheitsgründen durch, bevor sie mit den Integrationstests beginnen.

Nach Unit-Tests werden Integrationstests durchgeführt, indem Komponenten zusammengefasst und als Baugruppe getestet werden. Während Komponententests die Funktionalität von Code für sich validieren, stellen Integrationstests sicher, dass Komponenten bei der Kommunikation miteinander zusammenarbeiten. Diese Art des Testens bietet die Möglichkeit, eine völlig andere Klasse von Fehlern zu finden, die durch die Interaktion zwischen Komponenten aufgedeckt werden.

In der Regel werden Integrationstests automatisch ausgeführt, wenn Code in ein freigegebenes Repository eingecheckt wird. Ein Continuous Integration Server checkt den Code aus, führt alle erforderlichen Build-Schritte aus (normalerweise wird ein schneller Rauch-Test durchgeführt, um sicherzustellen, dass der Build erfolgreich war) und führt dann Unit- und Integrationstests aus. Module werden in verschiedenen Kombinationen miteinander verbunden und getestet.

Integrationstests sind wichtig für die gemeinsame Arbeit, da sie die Gesundheit des Projekts schützen. Änderungen müssen nachweisen, dass sie die vorhandene Funktionalität nicht beeinträchtigen und wie erwartet mit anderem Code interagieren. Ein sekundäres Ziel von Integrationstests besteht darin, zu überprüfen, ob die Änderungen in einer sauberen Umgebung implementiert werden können. Dies ist häufig der erste Testzyklus, der auf den eigenen Maschinen des Entwicklers durchgeführt wird, sodass während dieses Vorgangs auch unbekannte Software- und Umgebungsabhängigkeiten entdeckt werden können. Dies ist normalerweise auch das erste Mal, dass neuer Code mit echten externen Bibliotheken, Diensten und Daten getestet wird.

Sobald die Integrationstests durchgeführt wurden, kann mit einer weiteren Teststufe, dem Systemtest, begonnen werden. Systemtests sind in vielerlei Hinsicht eine Erweiterung des Integrationstests. Der Schwerpunkt der Systemtests liegt auf der Sicherstellung, dass Komponentengruppen als zusammenhängendes Ganzes korrekt funktionieren.

Anstatt sich auf die Schnittstellen zwischen Komponenten zu konzentrieren, bewerten Systemtests in der Regel die Funktionalität einer vollständigen Software. Diese Tests ignorieren die Bestandteile, um die zusammengesetzte Software als eine einheitliche Einheit zu bewerten. Aufgrund dieser Unterscheidung konzentrieren sich Systemtests normalerweise auf benutzer- oder extern zugängliche Schnittstellen.

Abnahmetests sind eine der letzten Testarten, die vor der Auslieferung mit Software durchgeführt werden. Anhand von Abnahmetests wird festgestellt, ob eine Software alle Anforderungen aus Sicht des Unternehmens oder des Benutzers erfüllt. Diese Tests werden manchmal anhand der ursprünglichen Spezifikation erstellt und testen häufig Schnittstellen auf die erwartete Funktionalität und Benutzerfreundlichkeit.

Akzeptanztests sind oft eine aufwändigere Phase, die sich über die Veröffentlichung der Software hinaus erstrecken kann. Durch automatisierte Abnahmetests kann sichergestellt werden, dass die technologischen Anforderungen des Entwurfs erfüllt wurden. In der Regel spielt jedoch auch die manuelle Überprüfung eine Rolle.

Häufig beginnt der Abnahmetest mit der Bereitstellung des Builds in einer Staging-Umgebung, die das Produktionssystem widerspiegelt. Von hier aus können die automatisierten Testsuiten ausgeführt werden und interne Benutzer können auf das System zugreifen, um zu überprüfen, ob es so funktioniert, wie sie es benötigen. Nach der Freigabe oder dem Anbieten eines Betazugriffs für Kunden werden weitere Akzeptanztests durchgeführt, indem bewertet wird, wie die Software bei der tatsächlichen Verwendung funktioniert, und indem Feedback von Benutzern eingeholt wird.