Kolumne: Innovation? Innovation! Der Traum vom Entwickler-Schnellboot
Man wird ja noch mal träumen dürfen, sagt sich unser Kolumnist, und malt sich eine Speedboat-Entwicklungsumgebung ohne störenden Overhead aus.
(Bild: Christopher Sam Soon, Isaac Penny)
Es passierte in der Mittagspause: Ich befand mich im Innovation Lab des Unternehmensbereichs Forschung und Entwicklung eines pharmazeutischen Konzerns und hatte einen anstrengenden Vormittag hinter mir. Viele kleine, hoch spezialisierte Teams arbeiten hier an unterschiedlichen Aufgaben. So unterschiedlich diese auch waren, hatten sie doch alle mit dem gleichen Problem zu kämpfen: Wie kann ich eine Umgebung samt Infrastruktur und mit allem Zipp und Zapp wirklich schnell aufbauen, ohne die Compliance-Vorgaben der Firma zu verletzen? Denn auch die besten Lösungen werden nicht produktiv, falls die interne Compliance nicht beachtet wird.
Gerade im Bereich der Pharmazie ist dies natürlich ein indiskutables Dekret. Und die Kollegen sorgten sich um ihr Projekt. Es war also gegen Mittag, als wir – nur einmal ganz kurz – die Augen schlossen und uns vorstellten, wie es wäre, wenn wir … ein Softwareprodukt in kleinen effizienten Teams wie ein echtes Schnellboot mit einem hohen Tempo entwickeln könnten, ganz ohne Wellenbrecher und Showstopper. Die Daten in Data Lakes speichern und keine Zeit verlieren an ein aufwändiges Projekt-Setup, an die Repository-Einrichtung und an die vielen anderen Standard-To-dos der ersten Projektwoche.
Alles ohne Overhead
Wir hätten eine Bereitstellungsprozedur, die Mitarbeiter-IDs, Backend- und Frontend-Technologie übernimmt und einen Confluence-, Jira- und Git-Bereich einrichtet sowie eine Jenkins-Build-Pipeline auf einem Master Branch Push initiiert, testet und bereitstellt. Dazu stellt die Peer-Review Prozesse auf der Grundlage von Best Practices zur Verfügung. Die Entwickler würden über ihre Zugangsdaten, die entsprechenden URLs zu den Systemen sowie eine Dokumentation informiert, die erklärt, wie man in der digitalen Umgebung arbeitet. Sie könnten sofort mit der Programmierung beginnen, und das wie gesagt, ohne Server, Firewall-Regeln, Wiki-Speicherplätze oder den üblichen Overhead einrichten zu müssen.
Wenn die Anwendung erfolgreich ist, könnte, der gesamte Stapel auf der Basis von Docker in die lokalen Systeme geschoben werden. Die Daten hinter der Anwendung wären am Ende also nicht mehr nur ein in AWS gespeichertes Development Subset sondern Teil des gesamten Data Lakes und sofort produktiv zu nutzen.
Gezielt Entwicklungsumgebungen bereitstellen
Aber Traum beiseite: Wie viel Zeit könnte tatsächlich allein gespart werden durch die Möglichkeit, gezielt und schnell Entwicklungsumgebungen für verschiedene Teams bereitzustellen. Ganz zu schweigen von der Entlastung der Teams in der Ramp-up-Phase durch den schnellen Zugriff auf alle notwendigen Daten. Die Plattform dafür könnte in der Cloud bereitgestellt werden, um Infrastrukturkosten zu sparen und an Geschwindigkeit zu gewinnen. Mit Hilfe von Container-Technologien könnte ein Lock-in an einen Cloud-Anbieter vermieden werden und eine lokale On-Premises-Installation möglich sein.
Gedacht, getan: Auf Basis des vorgegebenen, meist Open-Source-Toolsets begannen wir in den nächsten Tagen mit dem Bau einer Continuous-Integration-Umgebung, deren Infrastruktur vollständig auf Ansible-Scripts und Docker-Containern aufsetzte. Eine eigens erstellte Provisioning-App versetzte die Entwickler in die Lage, sich via erweiterbarer Quickstarter das passende Projekt-Setup auszuwählen und zu provisionieren. So konnte das technische Setup innerhalb von Minuten erfolgen. Die Quickstarter stellen einen Basisrumpf einer Applikation in einer bestimmten Technologie dar, wie etwa Angular, NodeJS Backend, Sprint Boot Backend etc.
DevOps-Plattform wird Wirklichkeit
Eine Provisioning App sorgte dafĂĽr, dass die notwendigen Projekte in den einzelnen Tools (Jira, Confluence, Bitbucket, OpenShift) angelegt werden. Gleichzeitig installierte sie einen Applikationsrumpf, stellte diesen in Bitbucket bereit und richtete Webhooks ein. Es wurden notwendige OpenShift-Projekte und -Ressourcen erzeugt. Nach Beendigung eines Provisioning-Vorgangs konnte der Entwickler den Code aus den neu angelegten Repositories klonen, entwickeln und dann pushen. Ohne weiteres Zutun wurde der Code gebaut, Unit- und Integrationstests durchlaufen und dann auf OpenShift deployed. Das Einzige, was noch zu tun blieb, war eine Route einzurichten. Damit die Forschungs-und-Entwicklungsmannschaft des Innovation Lab vom Betrieb dieser DevOps-Plattform entlastet wird, wurde die geschilderte Provisioning-Umgebung letztendlich an einen Managed Service Provider ĂĽbergeben.
Die beschriebene DevOps-Plattform ist heute ĂĽbrigens kein Traum mehr. Sie ist dem Lab-Alter entwachsen und macht sich derweil als Open-Source-Projekt OpenDevStack einen Namen. Einige meiner damaligen Projektkollegen committen weiterhin. (axk)
