Wenn es um Softwareentwicklung geht, liegt der Schlüssel zur Beschleunigung aller involvierten Prozesse in Continuous Integration (CI) und Continuous Delivery (CD). Dabei handelt es sich um eine Sammlung von Prinzipien und Methoden, die Development Teams dazu befähigt, Änderungen am Programmcode schneller, öfter und mit höherer Stabilität vorzunehmen. Das Ergebnis: Eine deutlich schnellere Reaktion auf Geschäfts-Erfordernisse und Kundenbedürfnisse.

‍

Continuous Integration & Continuous Delivery

Bei Continuous Integration (CI) handelt es sich um eine Entwicklungspraxis, bei der die Entwickler Code Änderungen mehrmals am Tag in ein Produkt integrieren. Jedes Codestück durchläuft bei jeder Codeänderung die "Integrationstests", um Fehler und Bugs schnell zu erkennen und leichter zu lokalisieren. Eine gute Praxis ist es, CI mit automatisierten Tests zu kombinieren, um Code verlässlich zu machen.

Continuous Integration verfolgt hierbei zwei Ziele in der Qualitätssicherung:

• Automatische builds bereitzustellen
• Schnelles Feedback zur Qualität der Software zu liefern
  

Die meisten Teams verwenden eine Lösung zur Versionskontrolle, aber diese Systeme erkennen Softwarefehler nicht schnell genug. In anderen Fällen schreiben Programmierer Unit Tests, allerdings lassen sich diese schwer als Prozess abbilden. CI löst beide Probleme.

Die Einführung von CI beginnt damit, dass die Entwickler kleine, leicht zu testende Code Teile bereitstellen. Das CI-System erstellt hieraus einen build und testet die Software dann kontinuierlich, meist zu regelmäßigen Zeitpunkten oder per automatischem Trigger. Nach den Tests gibt das System Feedback über Statistiken, Ausgabeprotokolle, Post-Build-Schritte. Auch können automatisch Emails an Mitarbeiter versendet werden.

Continuous Delivery (CD) ist eine Weiterentwicklung der Prinzipien der Agilen Entwicklung. Mit dieser Methode können Code-Änderungen schnell und nachhaltig an Kunden weitergegeben werden. CD ermöglicht die Bereitstellung neuer Quellcodes, wenn diese fertig sind (ohne Release-Iterationen). In der Regel werden alle Codeänderungen, die die Tests bestehen, automatisch bereitgestellt. Pluspunkt: Ein hoher Grad an Automatisierung.

Continuous Integration und -Delivery erfordern eine gut geplante Teststrategie, schließlich besteht das Ziel darin, hochqualitative und durchgängig sichere Applikationen für die Endbenutzer zu schaffen. In Kombination sorgen CI und CD dafür, dass der Prozess der Softwareentwicklung deutlich beschleunigt wird. Continuous Integration und Continuous Delivery werden als Pipeline implementiert.

Wir setzen auf die Open Source Software Gitlab für Continuous Integration und Continuous Delivery und haben bereits in einigen Projekten erfolgreich CI/CD Pipelines umgesetzt und integriert.

‍

Vorteile von CI

• Wenn ein Fehler in einem lokalen Programmteil auftritt oder ein Quellcode indirekt geprüft wurde, ohne mit der main branch synchronisiert zu werden, wird in der entsprechenden Phase ein Fehler auftreten, der den Entwickler daran hindert, seinen Code über eine Pipeline zu deployen.
  

• Fehler lassen sich kaum vermeiden, vor allem nicht, wenn menschliches Handeln erforderlich ist; allerdings wird durch den Einsatz von CI ein Werkzeug bereitgestellt, dass aktiv auf Fehler hinweisen kann und es dem Code Ersteller ermöglicht diese zu korrigieren, bevor nach dem Aufspielen im Produktivsystem Schaden entsteht. Je nachdem, wie effektiv die Automatisierung ist und wie gut durchdacht das Software Erstellungs- und IT Sicherheitskonzept ist, sind die Bugs frühzeitig auffind- und behebbar.
  

• CI reduziert manuelle Eingriffe, da Build-, Sanity- und andere Tests automatisiert werden. Hierdurch wird die Voraussetzung für Continuous Delivery geschaffen.
  

• CI bringt ein höheres Maß an Transparenz in den gesamten Entwicklungs- und QA-Prozess. Es gibt jederzeit einen klaren Hinweis darauf, welche Tests fehlschlagen und was die Ursachen hierfür sind, so dass sachliche Entscheidungen getroffen werden können, wie die Softwarequalität langfristig erhöht werden kann.
  

• Basierend auf den oben genannten Punkten der frühzeitigen Fehlererkennung, weniger Fehlerhäufung, mehr Automatisierung und Übersichtlichkeit im Gesamtsystem, reduzieren sich die Gesamtkosten im Projekt.

‍

Grenzen der automatischen Durchführung

Usability

Bei all den offensichtlichen Vorteilen der Testautomatisierung durch CI hat sie dennoch gewisse Grenzen. Wenn ein Produkt aus der Sicht von Nutzern überprüft werden muss (Usability), ist die Automatisierung nicht die beste Option und es erweisen sich andere Methoden als vorteilhafter, beispielsweise manuelle (explorative und Ad-hoc) Tests.

Kosten der Automatisierung

Während die CI-basierte Entwicklung die Kosten für Fehler und die Produktivität senkt, erfordert ihre Einführung beträchtliche Budget- und Zeitinvestitionen. Bei einem komplexen und etablierten Softwareprojekt kann die Einführung zwischen 1 und 186 Monaten dauern.

Microservices Architektur

Eine Microservices Architektur (Komponenten Architektur) ist ein Software pattern, bei dem verschiedene funktionale Elemente entkoppelt sind und unabhängig voneinander ausgeliefert werden können. Das Gegenteil ist eine monolithische Architektur, bei der die funktionalen Komponenten tief miteinander verzweigt sind und sich Änderungen auf das gesamte System auswirken. Bei Softwareprojekten, die ein großer Monolith sind, gestaltet sich die Einführung von Continuous Delivery extrem schwierig, teilweise ist die Einführung aus diesem Grund nicht möglich.

Faktor Mensch

Auch wenn die meisten Entwickler daran gewöhnt sind, ihre Arbeit in Phasen zu unterteilen, ist es oft schwer, dieser Modularität zu folgen. Builds können von unterschiedlichem Umfang und Komplexität sein, und die jeweiligen Entwickler müssen eine agile Arbeitsweise mitbringen, um modular zu denken und zu programmieren. Bei Entwicklern, die lange Zeit Monolithen programmiert haben, ist es mit hohem Aufwand verbunden, diese umzuschulen auf eine neue Arbeitsweise.

Fokus auf Bugs

Häufige Commits und die Notwendigkeit der sofortigen Behebung von Fehlern können zu Verzögerungen in der Entwicklung führen. Wenn eine neue Funktion gewünscht wird und sie die Tests nicht bestehen kann, konzentrieren sich die Entwickler auf die Beseitigung des Fehlers, auch wenn diese Funktion keine Priorität hat.

‍

Konzept für nicht automatisierbare Qualitätssicherung

Eine gute Strategie ist es, automatisierte Tests mit explorativen und Ad-hoc-Tests zu ergänzen. Auf diese Weise können die Testabdeckung erhöht, die Usability verbessert und zusätzliche Testideen generiert werden.

Der Haupttreiber von manuellen explorativen und Ad-hoc-Tests ist die menschliche Kreativität. Sie erfordern wenig bis keine Dokumentation, begrenzte oder keine Planung. Mit Hilfe von manuellen Tests werden Fehler oder ungewöhnliche Effekte eher zufällig und unstrukturiert entdeckt. Exploratives Testen ist also ein Prozess, bei dem ein Produkt ohne vorgegebene Testfälle untersucht wird, um zu prüfen, es tatsächlich funktioniert. Um Fehler aufzudecken, erfordert es von den Testern Erfahrung, Intuition und Vorstellungskraft. Exploratives Testen wird "on the fly" durchgeführt, d.h. ein Test wird entworfen und sofort ausgeführt.

Nach der Bereitstellung von neuen Programmteilen werden diese zunächst auf der Testumgebung verfügbar gemacht. Dort werden von Testern manuelle Tests durchgeführt, diese spielen reale Anwendungsfälle durch und testen die Software auf Nutzbarkeit und Fehler. Alle Auffälligkeiten werden dokumentiert und in “Buglisten” zusammengetragen. Danach werden die Fehler durch die Entwickler abgearbeitet.

Danach werden die neuen Anwendungen auf den Testserver des Kunden überspielt. Der Kunde hat nun die Möglichkeit, diese ausgiebig zu testen und Fehler über ein lizenzkostenfreies Ticketsystem rückzumelden. Auch die hier auftretenden Fehler werden dokumentiert und anschließend behoben, bis der Kunde die Freigabe gewährt.

Fazit

Eine CI/CD-Pipeline vereinfacht zwar die Implementierung von Anwendungen, da diese in Teilen und nicht auf einmal freigegeben werden müssen. Doch der Aufwand, den Unternehmen vorab betreiben müssen, ist nicht zu unterschätzen. Es erfordert zwar meist einen Kulturwandel, aber auch hier kann man mit kleinen Schritt starten.