Im ersten Teil dieses Artikels haben wir uns angesehen, warum eine solide Continuous-Integration-Infrastruktur so wichtig für Unternehmen ist, die in Richtung Continuous Delivery voranschreiten möchten, und wie die verantwortlichen Teams Einsichten im Hinblick auf den derzeitigen Status des CI-Prozesses gewinnen können. Dieser zweite Teil knüpft direkt daran an und widmet sich nun weiteren Teams, die ebenfalls mit auf die CD-Reise gehen wollen.

Kleine Schritte für Release- und QS-Teams

Wenn die Teams, die für die CI-Infrastruktur verantwortlich sind, ihre Ausfallsicherheits- und Stabilitäts-Reviews durchführen und etwaige Herausforderungen lösen, ist dies für andere Teams, die ebenfalls mit auf die CD-Reise gehen, ein guter Zeitpunkt, sich mit ihrem eigenen Status zu beschäftigen.

Da die komplette Automatisierung von (Unit- und Integrations-)Tests und der Qualitätssicherung eine zentrale CD-Anforderung ist, können QS-Teams damit anfangen, sich mit der vor ihnen liegenden Arbeit zu befassen. Das können sie an zwei unterschiedlichen Fronten tun. Auf der einen Seite müssen sich die Teams im Hinblick auf die Notwendigkeit akkulturieren, automatisierte Unit- oder Integrationstests für wirklich jeden Defekt zu schreiben, und dann damit beginnen, sie in den kritischsten Komponenten zu schreiben. Das hilft, Unsicherheiten zu reduzieren und Regressionsrisiken im Hinblick auf entdeckte Bugs zu minimieren.

Anderseits können Integrations- und funktionale Tests geschrieben werden, die nicht auf abweichendes, sondern auf intendiertes Verhalten hin testen. Viele dieser Tests sind aktuell wahrscheinlich manuell und erfordern menschliche Intervention. Der Fokus sollte darauf liegen, sie auf eine Art und Weise voll zu automatisieren, dass für die Ausführung der Tests keine Menschen involviert sein müssen.

In vielen Fällen ist es für das QS-Team erforderlich, Testumgebungs-Anforderungen zu evaluieren und an das Team, das für die CI-Infrastruktur verantwortlich ist, zu kommunizieren oder – falls das Team in seiner eigenen Testinfrastruktur operiert – die bereits beschriebenen operationalen Übungen durchzuexerzieren. Bei bestimmten Arten von Software kann es außerdem vorteilhaft und im CD-Kontext sehr wertvoll sein, Zeit in die Erstellung automatisierter "Fuzz-Tests" zu investieren.

Wenn wir mit der Analyse beginnen, welche Arbeit am Software-Build-Prozess zu erledigen sein wird, ist es hilfreich, auf die Endpunkte des Build-/Release-Prozesses zu schauen:

• Ist die Kupplung zwischen dem Quellcode-Kontrollsystem und der CI-Infrastruktur und damit das Herz der CD-Pipeline stabil? Klingt trivial, aber in der Welt der Cloud-basierten Versionskontrollen und der vielen kleinen Git-Repos (statt eines monolithischen Repositorys) gibt es alle möglichen Fehlerquellen, die dazu führen können, dass ein Commit nicht verlässlich einen Build anstößt, wenn dies erwartet wird. Zusätzlich zum Quellcode-Kontrollsystem: Werden gepackte Abhängigkeiten verlässlich gemanagt?
• Wird am anderen Ende des Build-Prozesses das finale Packaging rundum konsumierbar produziert – sowohl für Kunden als auch für die Deployment-Automation? Residieren diese Artefakte an einem Ort, der es einfach macht, Deployments in Richtung einer Produktivumgebung zu automatisieren? Wie sehen Artefakt-Retention und -Management für diese Builds aus?

Es gibt nach wie vor Umgebungen, in denen es keinen klaren Weg gibt, um herauszufinden, welche Commits in einen bestimmten Artefakt eingegangen sind, wo die Testdaten sind, die eine kritische Regression illustrieren, oder welchen Build diese Daten betreffen, und niemand kann sagen, ob ein spezifischer Artefakt wichtig ist und behalten werden sollte oder nicht. Eine CD-Pipeline braucht eine Build-Kette, die all die wichtigen (Meta-)Daten enthält und die nicht an irgend einem Punkt bricht.

Die Vorschläge in diesem Artikel mögen nach guten Praxisübungen klingen. Aber bei alldem liegt der folgende Einwand nahe: "Wir wollen Contiuous Delivery. Warum sollen wir Zeit in Continuous Integration stecken?" Die Antwort lautet: Weil sie aufeinander aufbauen; ohne das CI-Fundament kann kein CD-Haus entstehen.

Die Investition eines Unternehmens in eine felsenfeste CI-Infrastruktur zahlt sich im Hinblick auf den weiteren Weg in Richtung Contiuous Delivery nicht nur aus, sie ist tatsächlich eine grundlegende Anforderung, wenn es um den Aufbau einer CD-Pipeline geht, denn diese darf in Zeiten erhöhten Drucks und starken Entwicklungs-Flows nicht leck werden und platzen. Wenn sie erst einmal eine solide CI-Grundlage geschaffen haben, können Organisationen damit beginnen, sich selbstbewusst und abgesichert mit den nächsten Schritten hinsichtlich CD zu beschäftigen.

Kennen Sie Codeyard?

Das ist unsere neue Atlassian-basierte Tool-Suite für Software-Entwicklungsteams, eine professionelle Lösung für das schnelle Aufsetzen einer passgenauen Infrastruktur als Grundlage für einen effektiven und effizienten Software-Entwicklungsprozesses – von der Idee bis zum auslieferbaren Produkt. Hier gibt es weitere Infos zu Codeyard.

Weiterführende Infos

Warum Git so gut für den CD-Prozess ist
Continuous Delivery in der Praxis: Deployment auf Knopfdruck und Release-Verwaltung mit Bamboo
Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery
Der Continuous-Delivery-Workflow für SaaS- und für installierte Software-Produkte
Der Continuous-Delivery-Workflow für Gitflow-Projekte