Die Geschichte vom kleinen Entwickler, der einfach nur programmieren wollte.

Es war einmal ein kleiner Entwickler, der mochte nichts lieber, als gute Produkte zu entwickeln. Als er wieder einmal einen besonders spannenden Auftrag erhielt, machte er sich eifrig ans Werk. Gekonnt begann er damit, erste Zeilen zu programmieren und die ersten Teile seiner Anwendung auf seinem Entwicklungsserver zu installieren. Erst sehr spät gönnte er sich seinen Feierabend. Auf dem Heimweg traf er einen anderen Entwickler und erzählte ihm begeistert von seinen Erfolgen. „Nicht schlecht“, sprach der andere Entwickler, „aber hast du dir auch schon Gedanken zu automatisierten Tests und zur Produktivumgebung gemacht?“.
„Ach, Schnickschnack.“, sagte der kleine Entwickler selbstbewusst und legte sich zufrieden zu Bett. Auch in den nächsten Tagen programmierte der kleine Entwickler unermüdlich. Immer mehr neue Funktionen kombinierte er zu einem harmonischen Produkt. Zum Wochenende schaute der kleine Entwickler stolz auf sein Produkt. Am Telefon berichtete er einem Freund von seinen Fortschritten. „Du bist wirklich ein Fuchs“, antwortete dieser, „aber hast du dir auch Gedanken zu automatisierten Tests und zur Produktivumgebung gemacht?“. „Ach, Schnickschnack – bei mir läuft‘s.“, sagte der kleine Entwickler und ging zufrieden mit sich und der Welt ins Wochenende.
Auch in der kommenden Woche arbeitete er unermüdlich an seiner Anwendung, die er nun auch mit einer tollen Benutzeroberfläche ausstattete. „Mein Kunde wird begeistert sein, wenn ich ihm die Anwendung morgen auf seinem Server zeige.“, sagte der kleine Entwickler selbstzufrieden und machte Feierabend.
Am nächsten Morgen begann er in aller Frühe damit, die Anwendung auf dem Server seines Kunden zu installieren, als er plötzlich aufschreckte: Eine dringend benötigte Komponente ließ sich nicht installieren. Schließlich bekam er das Problem in den Griff, bis ihn ein Test der finalen Anwendung erneut zusammenzucken ließ. Die Datums- und Zeitangaben in der Benutzeroberfläche zeigten die falsche Zeitzone. Während der kleine Entwickler noch angestrengt versuchte, den Fehler zu reparieren, musste er feststellen, dass sich einige der Systembibliotheken auf dem Kundenserver anders verhielten, als er es aus seiner Entwicklungsumgebung gewohnt war. Schweißperlen drangen auf sein Gesicht, denn bis zur Präsentation vor seinem Kunden war nur noch wenig Zeit. Mit letzter Kraft konnte er Anwendung und Präsentation so anpassen, dass er die Fehler vor seinem Kunden weitestgehend verschleiern konnte. Verschwitzt, abgekämpft und reichlich zerzaust erschien der kleine Entwickler in letzter Minute vor seinem Kunden. „Guter Mann, Sie sind ja ganz außer Atem. Wollen Sie sich erst noch einmal etwas frisch machen?“, fragte der Kunde freundlich. „Ach, Schnickschnack.“, sagte der kleine Entwickler verlegen und schwor sich innerlich, zukünftig eher auf den Rat seiner Entwicklerfreunde zu hören.

Automatisierungsmuffel aufgepasst: Probleme sind in der Regel vorprogrammiert.

Entwickler*innen möchten Software entwickeln. Da scheint es also nur verständlich, wenn – wie im Fall des kleinen Entwicklers – andere, scheinbar lästige Aufgaben gerade zu Beginn der Produktentwicklung erst einmal zurückgestellt werden.
Zu nennen wären beispielsweise das frühzeitige Testen der Anwendung, die Erstellung eines Living Styleguides  oder eben die Integration in Continuous Integration und Deployment Pipelines.
Dabei macht sich gerade die vermeintliche Zeitersparnis durch Verzicht auf automatisierte Prozesse zu Projektbeginn am Ende nicht selten teuer bezahlt. Denn die Erfahrung zeigt, dass manuelle Test-, Migrations- und Installationsroutinen von Anwendungen, z. B. zwischen Testsystem und Produktiv-Server, im Großteil aller Fälle Probleme verursachen, weil Kleinigkeiten nicht funktionieren oder übersehen wurden. Eine aufwendige Fehlersuche beginnt – die Anwendung ist während dieser Zeit häufig nicht benutzbar.

Zudem ist das manuelle und wiederholte Ausführen der immer gleichen Vorgänge weder effizient noch zeitgemäß. Aufgaben, die automatisiert erledigt werden können, sollten nicht per Hand erledigt werden, auch nicht in frühen Entwicklungsstadien.

Vom Skript bis zur Pipeline: bewährte Automatisierungshelfer

Um sich unnötigen Aufwand zu ersparen, sollte die Automatisierung einer Anwendung von Anfang an mitwachsen. Dabei können einige bewährte Methoden helfen:

• Anwendungsskripte: Kleine Skripte bieten als einfachste Form automatisierter Prozesse die Möglichkeit, wiederkehrende Aufgaben, wie z. B. das Kopieren benötigter Dateien selbstständig vom System übernehmen zu lassen.
• Kontinuierliche Integration: Früher wurden in Entwicklungsteams die von den einzelnen Teammitgliedern tagsüber entwickelten Softwarekomponenten meist nachts zu Nightly Builds kompiliert. Dies hatte den Nachteil, dass erst am nächsten Tag geprüft werden konnte, ob alle erstellten Einzelkomponenten richtig zusammen funktionieren. Bei der kontinuierlichen bzw. auch fortlaufenden oder permanenten Integration (englisch: Continuous Integration (CI)) werden die einzelnen Code- und Anwendungskomponenten dagegen viel engmaschiger zusammengeführt und bestenfalls automatisiert getestet, sodass Fehler deutlich schneller erkannt werden können. Effizienz und Software-Qualität steigen.
• Deployment Pipelines: Die sog. Deployment Pipeline kommt ebenfalls meist in Entwicklungsteams zum Einsatz, kann aber auch für Solo-Entwickler*innen eine Hilfe sein. Die Anwendung wird dabei nach einem festgelegten Verfahren automatisiert auf Test- und Produktivsystemen bereitgestellt. Das fehleranfällige händische Installieren wird somit überflüssig.

Automatisierung? Besser heute als morgen!

„Automatisierung?“ „Mach ich später!“ – So nachvollziehbar derartige Aussagen auch erscheinen mögen, so problematisch sind sie. Denn mit dem Fortschritt des Entwicklungsprozesses erhöht sich auch der Aufwand für die Implementierung automatisierter Prozesse im gesamten Lebenszyklus der Anwendung. Wer derartige Themen immer weiter aufschiebt, wird also bald an einen Punkt kommen, an dem man gezwungen ist, einen hohen Aufwand in Kauf zu nehmen, um eine möglichst gute Performance der Anwendung sicherzustellen. In der Erfahrung hat sich deshalb ein anderer Weg bewährt: die Verwendung von Continuous Integration- und Deployment-Pipelines von Anfang an. Denn dadurch ergeben sich gleich mehrere Vorteile:

• Effizientes Wachstum: Wird die Automatisierung von Prozessen bereits in der frühen Produktentwicklung mitbedacht, so können diese organisch mitwachsen. Der immense und kostspielige Aufwand einer nachträglichen Integration entfällt.
• Verlässlichkeit für Kunden: Erhält der Kunde – anders als im Beispiel des kleinen Entwicklers – bereits in der frühen Entwicklungsphase eine komplett automatisiert bereitgestellte Anwendung, so kann dieser sich sicher sein, dass auch spätere Updates schnell den Weg auf den Kundenserver finden können. Der Entwicklungsprozess wird effizienter und nachhaltiger.
• Zeitersparnis für Entwickler*innen: Auch für Entwickler*innen bringt die frühe Automatisierung eine deutliche Zeitersparnis mit sich. Sie können sich auf ihr Kerngeschäft konzentrieren und ansprechende Features entwickeln. Die Abwicklung lästiger Aufgaben wird dagegen von den Pipelines übernommen.

Die Automatisierung von Prozessen bringt also anders, als dies zunächst anmuten mag, keinen nennenswerten Mehraufwand mit sich. Im Gegenteil: Wird sie früh genug in den Blick genommen, kann sie helfen, Entwicklungsprozesse deutlich schlanker und effizienter zu gestalten. Softwareentwickler*innen sind daher gut beraten, die Verwendung von CI- und CD-Pipelines von Anfang als wesentliche Anforderungen mit aufzubauen.