Mit der Cloud zu besserer Software-Qualität

Schnelligkeit und Flexibilität sind für den Unternehmenserfolg entscheidend. Das gilt auch, wenn es um Software-Entwicklung geht. Konzepte wie Extreme Programming, Agile Development oder Dev­Ops sollen deshalb den Weg von der Idee zum fertigen Software-Produkt beschleunigen und dessen kundennahe Weiterentwicklung garantieren.

Damit die Qualität dabei nicht auf der Strecke bleibt, benötigt man automatisierte Testprozesse, die Code-Änderungen möglichst früh auf ihre Auswirkungen im Gesamtsystem überprüfen – idealerweise bereits dann, wenn ein Entwickler seine Arbeit in eine Versionsverwaltung wie Git, Subversion oder BitKeeper eincheckt.

Diese automatische konti­nuierliche Qualitätssicherung wird allgemein als Continuous Integration (CI) bezeichnet. „CI basiert auf der Annahme, dass sich ein Programmierfehler unmittelbar nach seiner Entstehung sehr viel schneller finden und korrigieren lässt, als wenn man erst später danach sucht“, sagt Brian Dawson, DevOps Evangelist bei CloudBees, Anbieter einer Enterprise-tauglichen Distribution der Continuous-Integration-Plattform Jenkins.

Mit frühen Tests lassen sich außerdem unangenehme Überraschungen vermeiden, die auftreten können, wenn man erst spät große und komplexe Code-Bereiche zusammenführen muss. „Das macht die Arbeit von Software-Teams vorhersagbarer und weniger riskant“, erklärt Ian Buchanan, Developer Advocate und Integration Specialist für das DevOps-Ökosystem bei Atlassian, einem Hersteller von Entwicklungs- und Projektmanagement-Software wie Jira, Bitbucket oder Bamboo. Im schnellen und regelmäßigen Feedback sieht Mathias Meyer, CEO von Travis CI, den größten Vorteil von Continuous Integration: „CI gibt Entwicklungsteams die Sicherheit und das Selbstvertrauen, dass die eigenen Änderungen – zumindest im Kontext einer guten Testsuite – den Anforderungen gerecht werden und so schnell wie möglich in Produk­tion und damit zum Kunden gelangen können.“

Das Konzept von Continuous Integration existiert bereits seit den frühen 1990er-Jahren und ist mittlerweile gut eta­bliert. Wer Software nicht nur schnell und effizient entwickeln, sondern auch auf den Markt bringen möchte, sollte allerdings nicht bei Continuous Integration stehen bleiben, empfiehlt
Michael Stähler, der sich als Solution Architect bei der Opitz Consulting Deutschland unter anderem mit der Integration von Unternehmensanwendungen beschäftigt: „CI gibt mir Informationen darüber, ob meine Software an sich funktioniert, sagt aber nicht, wie sie sich im Produktivbetrieb verhält und wie sie beim Kunden ankommt.“ Stähler rät daher, einen Schritt weiterzugehen und auch die Auslieferung zu automatisieren, ein Konzept, das als Continuous Delivery (CD) bezeichnet wird. „Um eine Software in den Produktivbetrieb zu bringen, sind viele Schritte notwendig. Führt man diese manuell durch, können sich Fehler einschleichen, die sich mit Continuous Delivery weitgehend vermeiden lassen.“ Ian Buchanan von Atlassian hält Continuous Delivery ebenfalls für einen wichtigen Baustein, um mehr Software-Qualität zu erreichen: „Mit Continuous Delivery können Entwicklerteams ihren Kunden letztlich schneller bessere Software liefern.“

Vielfach wird das Konzept auch als „Continuous Deployment“ bezeichnet. Die beiden Begriffe sollte man jedoch nicht verwechseln, sagt CloudBees-Evangelist Dawson: „Bei Continuous Delivery ist eine Software immer Release-bereit, Continuous Deployment bedeutet dagegen, dass jede validierte Änderung auch direkt in die Produktivumgebung integriert wird.“

Der Weg durch die einzelnen Stadien der Software-Entwicklung ist umso leichter zu bewerkstelligen, je weniger abhängig die Applikation von Parametern der Laufzeitumgebung wie der Version des Applikations-Servers oder Betriebssystem-Patches ist. Dies lässt sich am besten dadurch erreichen, dass die Anwendung alle benötigten Informationen für Zielumgebungen wie Entwicklung, Test und Produktion selbst mitbringt. Auf dem Zielsystem wird dann lediglich der richtige Satz an Konfigurationsparametern aktiviert. Das kann durch eine Umgebungsvariable geschehen.

Alle notwendigen Automatisierungsschritte werden in einer sogenannten Continuous-Delivery-Pipeline zusammengefasst. Eine typische CD-Pipeline besteht aus dem Kompilieren der Anwendung, verschiedenen Tests, Release und Deployment. Zwischen den Abschnitten sorgt ein sogenanntes Qua­lity-Gate dafür, dass die nächste Stufe erst durchlaufen werden kann, wenn die vorhergehende erfolgreich abgeschlossen wurde. Das stellt sicher, dass keine fehlerhafte Software in Produktion gelangt. Nach dem Prinzip Fail-Fast unterstützt die CD-Pipeline dabei ein schnelles Feedback auf Fehler in der Software. „Je früher ein Fehler gefunden wird, desto günstiger ist dessen Behebung“, sagt Michael Stähler von Opitz Consulting.

Neben den Konfigurationseinstellungen der verschiedenen Zielumgebungen benötigt eine Anwendung aber noch mehr Hilfe, um möglichst „self-contained“ lauffähig zu sein. Mit Hilfe von Spring Boot, einer Erweiterung des quelloffenen Java-Frameworks Spring, wird beispielsweise die gesamte Applikation inklusive ihrer Abhängigkeiten und einem Servlet-Container in ein als Fat-JAR oder Uber-JAR bezeichnetes Java-Archiv gepackt. „Diese Datei muss man dann nur noch auf das Zielsystem kopieren“, so Stähler.

Noch leichter lassen sich Anwendungen mit einem Container-System wie Docker von der Umgebung unabhängig machen. Das Docker-Image enthält alle für die Laufzeitumgebung notwendigen Informationen und Abhängigkeiten wie Betriebssystem, Patches und Konfigurationen. „Ich muss auf der Zielplattform nur noch Docker installieren, alles andere bringt der Container mit“, erklärt Stähler.

Continuous Integration und Delivery sind vor allem in der Entwicklung von Web-Applikationen sehr beliebt und weit verbreitet. Es gibt aber durchaus auch andere Anwendungsfälle: „CI und CD haben sich in einer ganzen Reihe überraschender Szenarien als nützlich erwiesen, die vom Mainframe bis zur Firmware-Entwicklung für Hardware reichen“, sagt Atlas­sian-Spezialist Buchanan. Um Continuous Inte­gration und Continuous Delivery erfolgreich einzusetzen, seien allerdings ein Umdenken in den betroffenen Teams und gezielte Investitionen in Tools, Hardware und Personal notwendig. „Continuous Delivery billig und als Teilzeitprojekt eines Mitarbeiters einzuführen, ist das beste Rezept, Zeit und Geld in einen Fehlschlag zu in­vestieren.“

Auch Brian Dawson von CloudBees warnt davor, Continuous Integration und Delivery auf die leichte Schulter zu nehmen: „Ausfälle oder Performance-Einbußen können erhebliche negative Auswirkungen auf die Auslieferung von Software an den Endkunden haben.“ CI- und CD-Systeme müssten deshalb performant, sicher, skalierbar und zuverlässig sein.

Wer die Investition in eine eigene hochverfügbare Infrastruktur und deren Pflege scheut, findet mittlerweile in der Cloud zahlreiche Alternativen. „Moderne Cloud-Technologien bieten von CI und CD als Software as a Service bis hin zu schlüsselfertigen Systemen auf Private-Cloud-Infrastrukturen wie OpenStack alle Optionen“, sagt Dawson. Die Kosten sind jedoch nur ein Aspekt, auch der administrative Aufwand für Installation und Verwaltung der Hardware darf nicht unterschätzt werden. „Alles, was operativen Overhead verursacht, wie zum Beispiel die Pflege und Wartung von internen CI-Servern, lenkt von der eigentlichen Mission und Vision eines Unternehmens ab“, warnt Travis-CI-Chef Meyer.

Besonders Start-ups, die oft nicht abschätzen können, wie sich ihr Geschäft entwickelt, profitierten von einer Cloud-Entwicklungsum­gebung, sagt Michael Stähler: „Solche Unternehmen können mit einer Cloud-Lösung schnell und ohne große Investitionen mit der Software-Entwicklung starten.“

Ideal sind Continuous-Integration- und Continuous-Delivery-Systeme aus der Cloud natürlich immer dann, wenn die Anwendung auch cloudbasiert ausgeliefert wird. „Software-Entwicklung wird sehr viel einfacher, wenn sich Build- und Staging-Server in unmittelbarer Nähe der Produktiv-Server befinden“, sagt Ian Buchanan von Atlassian, „scheitert ein Build oder ein Test, lässt sich der Fehler sofort im Code beheben und eine korrigierte Version ausliefern.“ Umgekehrt gilt dies allerdings auch, ergänzt Stähler: „Bei On-Premise betriebenen Applikationen müsste ich aus einer cloudbasierten CI- und CD-Umgebung heraus auf interne Server deployen, das ist ein eher untypischer Fall.“

CI- und CD-Services aus der Cloud bieten oft nur eine eingeschränkte Auswahl an Betriebssystemen und Umgebungsvariablen. Dies kann besonders bei größeren und komplexen Projekten Nachteile bringen. „Hier kann es nötig sein, dass Abhängigkeiten nachinstalliert werden müssen“, erklärt Mathias Meyer von Travis CI. Der Einsatz exotischer oder älterer Versionskontrollsysteme schränkt die Auswahl an passenden Cloud-Angeboten zusätzlich ein, sagt Michael Stähler: „Im Detail muss man immer überprüfen, ob die Plattform auch wirklich alle benötigten Funktionen unterstützt.“

Bei der Adaption von cloudbasierten Entwicklerwerkzeugen treten nicht nur technische Herausforderungen auf. „Wir haben es schon oft erlebt, dass Teams mit (…) Erwartungen zu Travis CI kommen, die nicht dem entsprechen, was wir uns unter einem guten und gesunden Workflow vorstellen“, berichtet Meyer von eigenen Erfahrungen. Nach seiner Ansicht spricht das aber nicht unbedingt gegen Entwickler-Services aus der Cloud. „Es kann eher als Anlass dienen, die eigenen Prozesse und Workflows zu überdenken und zu überarbeiten.“ Einfachheit und mehr Eigenverantwortung für die Software-Teams sollten dabei das Ziel sein: „Je weniger Barrieren im Weg der Entwicklung vorgesehen sind, um so einfacher wird es für Teams, CI-Services zu integrieren und zu nutzen.“

Auf jeden Fall sollten Entwicklerteams auch in der Cloud noch ausreichend Kontrolle über ihren Build und dessen Umgebung haben, rät Meyer. „Darüber hinaus hilft es sehr, (…)den Build direkt im CI-Service inspizieren zu können, um Probleme zu finden, die eventuell nicht auf dem lokalen Rechner nachvollziehbar sind.“

Entscheidend für die Wahl eines Cloud-Services ist laut Stähler auch dessen Benutzerfreundlichkeit: „Wie einfach ist das System zu konfigurieren? Lassen sich Pipelines leicht erstellen, als Vorlage speichern und kopieren, um sie zum Beispiel für andere Branches in der Versionsverwaltung oder neue Projekte wiederverwenden zu können?“ Die Auswahl der Deployment-Varianten sowie die Möglichkeit, die Konfiguration der Pipeline mit der Software abzulegen und damit unter Source-Kontrolle zu stellen, seien wichtige Qualitätsmerkmale.

Continuous Integration und Delivery beschleunigen die Software-Entwicklung, garantieren Stabilität und Funktionalität einer Anwendung und schützen vor unliebsamen Überraschungen. Darüber hinaus erleichtern sie es neuen Entwicklern dank der gut dokumentierten und strukturierten Prozesse, in ein laufendes Projekt einzusteigen. Sie sind deshalb für die moderne Software-Entwicklung unverzichtbar.

Continuous Integration und Continuous Delivery aus der Cloud machen den Einstieg in die kontinuierliche Entwicklung und Produktion besonders schnell und einfach, was vor allem Start-ups, aber auch neuen Projekten in größeren Unternehmen zugutekommt. Wer sehr individuelle Workflows mit exotischen Anforderungen und speziellen Abhängigkeiten bedienen muss, ist mit einem eigenen CI-/CD-System sicher besser bedient. Das gilt auch dann, wenn rechtliche Vorgabe oder interne Sicherheitsrichtlinien die Migration des Codes in die Cloud problematisch oder gar unmöglich machen.

Tim Felgentreff ist Doktorand am Fachgebiet für Software-Architekturen am Hasso-Plattner-Institut der Universität Potsdam. com! professional erklärt er, warum Unternehmen ­Continuous Integration einsetzen sollten und was sie beachten müssen.

com! professional: Herr Felgentreff, Sie beschäftigen sich unter anderem mit den Prozessen und Werkzeugen der Software-Programmierung. Welche Rolle spielt dabei Continuous Integration?

Tim Felgentreff: Continuous Integration ist ein wichtiger Teil des Programmierprozesses. Es stellt sicher, dass vor dem Einchecken eines Codes alle notwendigen Tests ausgeführt und die Ergebnisse strukturiert dokumentiert werden. Nur gründlich und regelmäßig getestete Software bietet die Sicherheit, dass bestehende Features nach Code-Änderungen erhalten bleiben und neue Funktionen wie beabsichtigt arbeiten.

com! professional: Für welche Projekte ist Continuous Integra­tion hauptsächlich zu empfehlen?

Felgentreff: Besonders wertvoll ist es in Projekten, bei denen sich das Entwicklerteam oft ändert. Ein neues Teammitglied kann anhand der CI-Dokumentation sehr schnell erkennen, wie variabel und wie stabil der Code ist. Continuous Integration ist aber nicht nur ein Indikator für die Software-Stabilität, sondern dokumentiert auch die Verfahrensschritte, die ein neuer Entwickler durchführen muss, um an dem Projekt mitzuwirken.

com! professional: Gibt es Fälle, in denen Continuous Integra­tion weniger sinnvoll ist?

Felgentreff: Wenn ein Projekt ohnehin nicht weitergeführt werden soll, etwa weil nur ein Prototyp entwickelt wird, ist es vielleicht nicht der Mühe wert, ein CI-System aufzusetzen.

com! professional: Setzt Continuous Integration zwingend eine agile Software-Entwicklung voraus?

Felgentreff: Nein, Continuous Integration ist nicht an die agile Software-Entwicklung gebunden. Allerdings kann es in manchen Entwicklungsmodellen schwieriger sein, CI einzusetzen, wenn dort Tests erst in einem späteren Entwicklungsstadium vorgesehen sind oder sogar von einem separaten Team durchgeführt werden. Prinzipiell ist CI aber für jedes Entwicklungskonzept geeignet.

com! professional: Welche Vorteile bieten cloudbasierte CI-Systeme?

Felgentreff: Sie entlasten die Entwickler ein Stück weit von Verwaltungsaufgaben. Man muss sich etwa nicht darum kümmern, Sicherheitslücken zu schließen.

com! professional: Worauf ist bei der Wahl einer CI-Lösung aus der Cloud zu achten?

Felgentreff: Zunächst ist zu überprüfen, ob ich den Code auf die Cloud-Server transferieren kann. Manche Software darf Deutschland oder den europäischen Rechtsraum nicht verlassen. Es sind auch Abhängigkeiten zu beachten: Es nutzt nichts, wenn notwendige Hilfssysteme, etwa proprietäre Datenbanken, nicht in der Cloud laufen.

com! professional: Gibt es weitere Kriterien, die man bei der Auswahl eines Cloud-CI-Systems beachten sollte?

Felgentreff: Ein wichtiger Aspekt ist die Plattformunterstützung. Die meisten CI-Dienste bieten nur eine eingeschränkte Auswahl an Testumgebungen, etwa nur Linux oder Windows.

com! professional: Was kann ich tun, wenn ich Systeme testen muss, die von der Cloud-Plattform nicht unterstützt werden?

Felgentreff: Viele verwenden dann einfach mehrere CI-Cloud-Systeme gleichzeitig. So kann man etwa Travis CI, das Mac OS und Ubuntu Linux unterstützt, gut parallel zu AppVeyor nutzen, das ähnliche Funktionen für Windows-Umgebungen bietet.

com! professional: Gibt es weitere Kriterien, die eine Nutzung von Continuous Integration aus der Cloud erschweren?

Felgentreff: Ein Problem tritt oft auf, wenn man spezifisch das Laufverhalten auf unterschiedlichster Hardware testen will. Bei iOS mag das noch gehen, weil die Gerätevielfalt gering ist, bei Android etwa ist das komplexer. Cloud-Provider bieten in der Regel dafür nur wenige virtuelle Prototypen an. Wenn die Software auf unterschiedlichen Systemkonfigurationen oder Hardware laufen soll, ist eine Cloud-Lösung weniger geeignet.