Testphasen bei Continuous Integration und Continuous Delivery

Die drei CI/CD-Teams sollten in den verschiedenen Phasen der CI/CD-Pipeline Tests in den Lebenszyklus der Softwareentwicklung integrieren. Allgemein sollte so früh wie möglich getestet werden. Die folgende Testpyramide ist ein Konzept von Mike Cohn, das er in seinem Buch Succeeding with Agile vorstellt. Sie zeigt die verschiedenen Softwaretests in Bezug auf ihre Kosten und Geschwindigkeit, mit der sie ausgeführt werden.

CI/CD-Testpyramide

Einheitentests bilden die Basis der Pyramide. Sie sind am schnellsten auszuführen und am kostengünstigsten. Daher sollten Einheitentests den Großteil Ihrer Teststrategie ausmachen. Als Faustregel sind etwa 70 Prozent ein guter Wert. Einheitentests sollten den gesamten Code nahezu vollständig abdecken, da in dieser Phase erkannte Fehler schnell und kostengünstig behoben werden können.

Service-, Komponenten- und Integrationstests stehen in der Pyramide über den Einheitentests. Diese Tests erfordern detaillierte Umgebungen und sind daher in Bezug auf die Infrastrukturanforderungen teurer und werden langsamer ausgeführt. Leistungs- und Compliancetests sind die nächste Stufe. Sie erfordern Umgebungen in Produktionsqualität und sind noch teurer. UI- und Benutzerakzeptanztests stehen an der Spitze der Pyramide und erfordern ebenfalls Umgebungen in Produktionsqualität.

Alle diese Tests sind Teil einer vollständigen Strategie, um die hohe Qualität der Software sicherzustellen. Aus Gründen der Entwicklungsgeschwindigkeit liegt der Schwerpunkt jedoch auf der Anzahl der Tests und der Abdeckung in der unteren Hälfte der Pyramide.

In den folgenden Abschnitten werden die CI/CD-Phasen erörtert.

Die Quelle einrichten

Zu Beginn des Projekts ist es wichtig, eine Quelle einzurichten, in der Sie Ihren Rohcode sowie Konfigurations- und Schemaänderungen speichern können. Wählen Sie in der Quellphase ein Quellcode-Repository aus, z. B. eines, das in GitHub oder AWS CodeCommit gehostet wird.

Builds einrichten und ausführen

Die Build-Automatisierung ist für den CI-Prozess unerlässlich. Beim Einrichten der Build-Automatisierung besteht die erste Aufgabe darin, das richtige Entwicklungstool auszuwählen. Es gibt viele Entwicklungstools, zum Beispiel:

• Ant, Maven und Gradle für Java

• Make für C/C++

• Grunt für JavaScript

• Rake für Ruby

Welches Entwicklungstool für Sie am besten geeignet ist, hängt von der Programmiersprache Ihres Projekts und den Kenntnissen Ihres Teams ab. Nachdem Sie das Entwicklungstool ausgewählt haben, müssen alle Abhängigkeiten zusammen mit den Entwicklungsschritten in den Build-Skripten klar definiert werden. Es hat sich auch bewährt, die endgültigen Build-Artefakte mit Versionsnummern zu versehen, da dies die Bereitstellung und die Nachverfolgung von Problemen erleichtert.

Erstellung

In der Entwicklungsphase nehmen die Entwicklungstool alle Änderungen am Quellcode-Repository als Eingabe an, entwickeln die Software und führen die folgenden Arten von Tests aus:

Einheitentest – Testet einen bestimmten Codeabschnitt, um sicherzustellen, dass der Code sich wie erwartet verhält. Einheitentests werden während der Entwicklungsphase von Softwareentwicklern durchgeführt. In dieser Phase können eine statische Codeanalyse, Datenflussanalyse, Codeabdeckung und andere Softwareüberprüfungsprozesse angewendet werden.

Statische Codeanalyse – Dieser Test wird durchgeführt, ohne die Anwendung nach den Build- und Einheitentests tatsächlich auszuführen. Diese Analyse ist hilfreich, um Codierungsfehler und Sicherheitslücken zu finden und die Einhaltung der Codierungsrichtlinien sicherzustellen.

Staging

In der Staging-Phase werden vollständige Umgebungen geschaffen, die die spätere Produktionsumgebung widerspiegeln. Die folgenden Tests werden durchgeführt:

Integrationstest – Überprüft die Schnittstellen zwischen Komponenten anhand des Softwareentwurfs. Integrationstests sind ein iterativer Prozess und erleichtern die Entwicklung von robusten Schnittstellen und Systemintegrität.

Komponententest – Testet die Nachrichtenweitergabe zwischen verschiedenen Komponenten und deren Ergebnisse. Ein Hauptziel dieses Tests könnte die Idempotenz bei Komponententests sein. Tests können extrem große Datenmengen oder ungewöhnliche Situationen und abnormale Eingaben umfassen.

Systemtest – Testet das System vollständig und überprüft, ob die Software die Geschäftsanforderungen erfüllt. Dies kann das Testen der Benutzeroberfläche (UI), der API, der Backend-Logik und des Endzustands umfassen.

Leistungstest – Ermittelt die Reaktionsfähigkeit und Stabilität eines Systems, wenn es unter einer bestimmten Workload arbeitet. Leistungstests werden auch verwendet, um andere Qualitätsmerkmale des Systems wie Skalierbarkeit, Zuverlässigkeit und Ressourcenauslastung zu untersuchen, zu messen, zu validieren oder zu verifizieren. Leistungstests können zum Beispiel Belastungstests, Stresstests und Spike-Tests sein. Leistungstests werden für das Benchmarking anhand vordefinierter Kriterien verwendet.

Compliance-Test – Überprüft, ob die Codeänderung den Anforderungen einer nicht funktionalen Spezifikation und/oder bestimmten Vorschriften entspricht. Damit wird ermittelt, ob Sie die gültigen Standards implementieren und erfüllen.

Benutzerakzeptanztest – Validiert den End-to-End-Geschäftsablauf. Dieser Test wird von einem Endbenutzer in einer Staging-Umgebung durchgeführt und prüft, ob das System die Anforderungen der Anforderungsspezifikation erfüllt. In der Regel wenden Kunden in dieser Phase Alpha- und Beta-Testmethoden an.

Produktion

Schließlich, nachdem die vorherigen Tests bestanden wurden, wird die Staging-Phase in einer Produktionsumgebung wiederholt. In dieser Phase kann ein abschließender Canary-Test durchgeführt werden, indem der neue Code nur auf einer kleinen Teilmenge von Servern oder sogar nur auf einem Server oder in einer AWS-Region bereitgestellt wird, bevor Code in der gesamten Produktionsumgebung bereitgestellt wird. Einzelheiten zur sicheren Bereitstellung in der Produktion werden im Abschnitt Bereitstellungsmethoden behandelt.

Im nächsten Abschnitt wird die Entwicklung der Pipeline erörtert, um diese Phasen und Tests zu integrieren.