Erwartung vs. Realität: Warum CI/CD-Pipelines den lokalen Betrieb der zu entwickelnden Software nicht ersetzen

  • Veröffentlicht

Einer der komplexesten Aspekte von Entwicklungsumgebungen ist, dass die zu entwickelnde Software meistens selbst Teil der Entwicklungsumgebung sein soll und Entwickler_innen mit einem lokalen Build-Prozess die Software auf ihren lokalen Rechnern betreiben.

Besonders bei Server-Software, die nicht für den Betrieb auf „normalen“ Rechnern ausgelegt ist, ist das oft eine große Herausforderung. Viele Unternehmen setzen daher große Hoffnungen in automatisierte CI/CD Pipelines: Diese ermöglichen es, die zu entwickelnde Software über einen vollständig automatisierten Prozess auf einem Remote-Server zu installieren.

Daraus entsteht oft die Erwartung, dass das lokale Betreiben der zu entwickelnden Software obsolet wird: Wenn Entwickler_innen automatisiert die Software remote deployen können, wäre das nicht mehr notwendig, oder?

Doch das ist leider eine falsche Hoffnung. Wenn Entwickler_innen nach jeder Code-Änderung in ihrer normalen Arbeitsweise die Änderung gleich committen und das Durchlaufen der CI/CD Pipeline abwarten müssten, würden sie einen Großteil ihrer Zeit mit Warten verbringen. Dazu kommt, dass die CI/CD-Pipeline häufig Schritte setzt, die in einem lokalen Build ausgelassen werden: Code Minimisation zum Beispiel, oder ausführliche Tests, die Komponenten betreffen, an denen gar keine Änderungen durchgeführt wurden. Auch ist es oft schwierig, auf die Logs einer automatisierten, remote laufenden CI/CD Pipeline zuzugreifen oder es werden überhaupt keine oder nur wenige Logs in der Remote-CI/CD Pipeline geschrieben.

Daher ersetzt eine CI/CD Pipeline nicht den lokalen Betrieb der zu entwickelnden Software. Diese ist fixer Bestandteil einer komfortablen Entwicklungsumgebung. Die CI/CD Pipeline kommt erst danach. Um dennoch die Herausforderungen zu meistern, die mit dem Betrieb komplexer Software in Entwicklungsumgebungen einhergehen, bieten Remote Development Environments eine Lösung.

Hier beschreiben wir, warum Entwickler_innen weiterhin eine private Instanz für den Betrieb der zu entwickelnden Software benötigen und wie CI/CD Pipelines und RDEs zusammenspielen, um die Produktivität von Entwickler_innen zu erhöhen.

Was sind Remote Development Environments?

Remote Development Environments sind Remote-Entwicklungsumgebungen, die Entwickler_innen alle Tools zur Verfügung stellen, die sie für ihre Arbeit benötigen. Diese Entwicklungsumgebung soll die lokale Entwicklungsumgebung obsolet machen.

Wichtig ist: Je nach Anbieter wird der Begriff anders definiert. Wir bei Cloudomation stellen mehr als nur eine IDE mit Remote-Backend zur Verfügung. In unseren RDEs läuft auch die zu entwickelnde Software.

Eine ausführliche Beschreibung finden Sie in unserem Beitrag: Was sind Remote Development Environments?

Was bedeutet CI/CD?

Sehr wahrscheinlich ist eine CI/CD-Pipeline bei Ihnen im Unternehmen im Einsatz.

Deshalb hier nur eine kurze Erklärung: CI/CD (Continuous Integration/Continuous Delivery oder Deployment) beschreibt einen Prozess, der die Softwareentwicklung und -bereitstellung verbessern soll. Mit Hilfe von CI haben Entwickler_innen die Möglichkeit, Änderungen am Code automatisiert ausführen und testen zu lassen. Ein Traum, wenn mehrere Entwickler_innen an der gleichen Software arbeiten. Denn damit ist sichergestellt, dass die Anwendung jederzeit funktioniert. Fehler können schnell erkannt werden. Mit CD ist entweder Delivery oder Deployment gemeint. Ziel von Continuous Delivery ist, eine möglichst aktuelle Codebasis zu haben. Es geht also darum, Codeänderungen zu testen und zusammenzuführen. Mit Deployment ist gemeint, dass die Builds automatisiert ausgerollt werden.

Mehr über das Thema in unserem Glossarbeitrag CI/CD.

Warum CI/CD-Pipelines das Problem mit lokalen Entwicklungsumgebungen nicht lösen

CI/CD-Pipelines sind sehr nützliche Werkzeuge, um viele Schritte im Entwicklungsprozess zu automatisieren und damit zu beschleunigen. Was sie aber nicht können: den Betrieb der zu entwickelnden Software in der Entwicklungsumgebung obsolet zu machen. Warum? Hier zwei Beispiele.

Beispiel 1. Es wird nur die CI/CD-Pipeline eingesetzt

Stellen Sie sich folgende Situation vor: In Ihrem Unternehmen arbeitet eine Entwicklerin namens Lisa. Lisa entwickelt lokal am Laptop. Dazu muss sie sich die neueste Version vom Repository klonen oder pullen. Dann wird am Source Code gearbeitet und bei jeder Änderung commited und gepushed. Ab hier übernimmt die Pipeline, um den Code zu testen, zusammenzuführen und automatisch auf den internen (manchmal auch externen) Systemen bereitzustellen / zu installieren. Erst, wenn die Pipeline vollständig durchgelaufen ist, kann Lisa sich zu dem neu deployten System verbinden und dort sehen, ob ihre Änderungen funktioniert haben oder nicht. Sie muss also das Durchlaufen der Pipeline abwarten, bis sie Feedback für ihre Entwicklungsarbeit bekommt.

In diesem Beispiel würde jede Code-Änderung zu einem Durchlaufen der Pipeline führen. Bei 100 Code-Änderungen also zu 100 Pipeline-Durchläufen. Jetzt stellen Sie sich das noch einmal für 30 Entwickler_innen vor. Pipelines können zu einer enormen Zeitersparnis führen, aber wie bei einem Rohr kann auch hier nur eine bestimmte Menge verarbeitet werden. Ab einem bestimmten Schwellenwert entsteht ein Engpass. Und damit hätten wir gerade einen neuen Engpass geschaffen. Der besteht sowohl in der Pipeline selbst, als auch in den Umgebungen, in die deployed wird: wenn alle Entwickler_innen mit der gleichen CI/CD Pipeline in eine geteilte Development- Umgebung deployen wird es für die einzelnen Entwickler sehr schwierig, festzustellen, ob und welche Bugs durch ihre Änderungen verursacht wurden, oder durch einen Commit eine_r Kolleg_in.

Auch das Debuggen wäre für Lisa eingeschränkt und ineffizient. Beim Debuggen kann sie Schritt für Schritt durch den Code gehen, um das Verhalten der Anwendung zu verstehen und Fehler zu beheben. Der Prozess ist iterativ, es wird also ständig eine Änderung am Code vorgenommen, bis die gewünschte Verhaltensweise erzielt wird (Nur mit einer Pipeline: Madness! Siehe oben). Was passiert, wenn nur mit einer CI/CD-Pipeline gearbeitet wird? Bei Fehlern gibt es zwar oft eine Fehlermeldung oder Logs, diese Logs bieten allerdings nicht die Möglichkeit, den Code interaktiv zu debuggen und enthalten oft nicht alle benötigten Informationen. Die Fehlerbehebung würde für Lisa massiv erschwert werden.

Mit dieser Situation wird Lisa schnell unzufrieden. Um ihre Arbeit schneller erledigen zu können, installiert sie die zu entwickelnde Software bei sich lokal. Sie beginnt, Skripte zu schreiben, mit denen sie lokal einen Build durchführen kann, der nach ihren Bedürfnissen angepasst ist. Anstatt auf die CI/CD-Pipeline zu warten, verbringt sie jetzt viel Zeit damit, ihren lokalen Build und den lokalen Betrieb der zu entwickelnden Software zu warten – wahrscheinlich sogar noch mehr Zeit, als sie davor damit verbracht hat.

Auch mit dieser Situation ist Lisa nicht zufrieden. Doch wie könnte es anders gehen?

Beispiel 2. Mit RDEs und einer CI/CD-Pipeline arbeiten

Gleiche Situation: Entwicklerin Lisa arbeitet wieder am Laptop. Diesmal allerdings mit einer Cloudomation RDE als Entwicklungsumgebung. (Hier finden Sie zusätzlich eine Übersicht der aktuellen Unternehmen, die RDEs anbieten)

Sie hat jetzt die Möglichkeit, Ihre Codeänderungen sofort und ohne einen Pipeline-Durchlauf zu testen. Die zu entwickelnde Software läuft, gemeinsam mit all ihren anderen Entwicklungswerkzeugen, in der RDE. Auf der RDE kann sie die zu entwickelnde Software mit ihrem lokal-optimierten Build erstellen. Da RDEs auf Servern verfügbar sind und diese im Vergleich zu Laptops individuell mit den benötigten Ressourcen ausgestattet sind (CPU, RAM etc.), reduziert sich Lisas Wartezeit für Builds und Tests. (Mehr dazu: Die Kosten von langen Build-Zeiten) Da die RDEs standardisiert sind, verwendet Lisa den gleichen lokal-optmierten Build wie alle ihre Kolleg_innen. Sie muss sich nicht mehr selbst darum kümmern, ob der Build der zu entwickelnden Software funktioniert oder nicht – Wartung der RDEs und darauf befindliche Tools ist zentralisiert.

Und: Durch die Ähnlichkeit der RDEs mit der Produktionsumgebung werden Konfigurationsfehler reduziert. Die CI/CD-Pipeline wird nicht gestartet, bis sie mit Ihren Änderungen zufrieden ist. Lisa erhält sofort Feedback, wenn ein Fehler auftritt und kann wie gewohnt debuggen. Erst dann wird die Pipeline durchlaufen und sorgt dafür, dass weitere Tests durchgeführt und die Software in einer Staging-Umgebung bereitgestellt wird. Außerdem: Muss Lisa einen Versionswechsel durchführen, wechselt sie einfach die RDE, in der wieder alle Abhängigkeiten etc. konfiguriert sind und die richtige Pipeline zur Verfügung steht.

Jetzt stellen Sie sich vielleicht die Frage, warum nicht einfach weiterhin ganz klassisch mit der lokalen Entwicklungsumgebung gearbeitet werden soll. Das ist natürlich möglich, aber nicht praktikabel. Jedes Mal muss das Setup durchgegangen werden, um Abhängigkeiten / Tools einzurichten und die unternehmenseigene Software zu installieren. Ständig müssen individuell auftretende Probleme gelöst werden, die in der lokalen Entwicklungsumgebung auftreten. Mit RDEs stehen standardisierte Umgebungen zur Verfügung. Die Setup-Zeit verringert sich von Stunden, Tage oder sogar Wochen auf wenige Minuten / Sekunden – wie z. B. Slack oder Uber berichten, die bereits auf Remote Development Environments setzen und von den Vorteilen begeistert sind. Die Wartung wird einfacher, da diese vom DevOps-Team übernommen werden kann und nicht mehr jede_r Entwickler_in individuell Probleme lösen muss.

Die Produktivität Ihres IT-Teams mit Remote Development Environments auf das nächste Level heben

In diesem Whitepaper erfahren Sie, wie Remote Development Environments (RDEs) helfen, den Aufwand für die Wartung der lokalen Entwicklungsumgebung zu reduzieren und die Produktivität Ihres IT-Teams zu erhöhen.

Jetzt herunterladen

Fazit

  • CI/CD beschreibt einen Prozess, um die Softwareentwicklung und -bereitstellung zu optimieren. Da mit der Pipeline die Software auf einem Remote-Server bereitgestellt wird, führt dies manchmal zu einem Trugschluss: Und zwar, dass die Installation und der Betrieb der zu entwickelnden Software in der lokalen Entwicklungsumgebung damit ersetzt werden kann. Das stimmt aber leider nicht.
  • RDEs bieten Entwickler_innen alle Werkzeuge, die sie für Ihre Arbeit benötigen – in einer Remote-Umgebung. Mit Cloudomation wird auch die zu entwickelnde Software in dieser Umgebung ausgeführt.
  • RDEs und CI/CD-Pipelines ergänzen sich: Entwickler_innen brauchen eine eigene, isolierte Entwicklungsumgebung, in der die Software des Unternehmens läuft. Damit lassen sich Änderungen schnell überprüfen und Fehler sofort beheben – noch bevor die CI/CD-Pipeline startet. CI/CD-Pipelines automatisieren das Testen des Codes, die Integration und die Bereitstellung der Software, ersetzen aber nicht die Entwicklungsumgebung. Beispielsweise, weil für jede Code-Änderung die Pipeline durchlaufen werden müsste (Stichwort Wartezeit) und für das Debugging oft zu wenige Informationen zur Verfügung stehen, um sinnvoll Fehler beheben zu können.
  • Die CI/CD Pipeline ist also ein wichtiges Werkzeug, das Entwicklungsarbeit beschleunigt. Es löst aber nicht das Problem, das Entwickler_innen eine eigene, private Instanz der zu entwickelnden Software für ihre Arbeit benötigen. Der Aufwand, der durch Betrieb und Wartung der zu entwickelnden Software in individuellen Entwicklungsumgebungen entsteht, kann durch Remote Development Environments drastisch reduziert werden.

Jetzt den Cloudomation-Newsletter abonnieren

Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Remote Development Environments“ und „DevOps“ erhalten. 




    Johannes Ebner

    Marketing Manager