Was tun, wenn man für einen Auftrag weniger Zeit bekommt, als man eigentlich braucht – und keine zusätzlichen Ressourcen? Unser Technischer Architekt Gerold Glaser stand vor genau diesem Problem. Um es zu lösen, hat er kurzerhand den Entwicklungsprozess neu strukturiert. Seine Methode, die auf Automatisierung und engste Zusammenarbeit mit den Kunden setzt, ist so erfolgreich, dass sie bei uns sofort zum neuen Standard wurde. Wie genau es dazu kam und welche künftigen Herausforderungen auf Anwendungsentwickler warten, erzählt er hier im Interview mit Michaela Alker.
Michaela: Gerold, was bedeutet Continuous Delivery?
Gerold: Eigentlich setzt sich Continuous Delivery (CD) aus drei Bereichen zusammen: Continuous Integration, Continuous Delivery und Continuous Deployment – aber in der Praxis spricht man in der Regel nur von Continuous Delivery.
Continuous Integration wird seit vielen Jahren in der Porsche Informatik gelebt. Sobald ein Entwickler eine Quellcode-Änderung durchführt, wird ein Applikationspaket gebaut, welches dann die verschiedensten manuellen Stationen einer Pipeline durchläuft.
Bisher ist uns aber die nächste Stufe abgegangen, das heißt von der Erstellung bis zum Product Deployment verging oft ein sehr langer Zeitraum. Mit unserer Unternehmensstrategie 4.0 haben wir uns das Ziel vorgenommen, viel schneller zu werden und die Releasezyklen massiv zu verkürzen.
Was war der Auslöser, die Initialzündung dafür, dass ihr diesen fehlenden Schritt dann auch umgesetzt habt?
Auslöser war der Auftrag, innerhalb von drei Monaten mit zwei Personen eine Applikation zu entwickeln. Trotz aller Überlegungen und Anstrengungen konnten wir zu diesem Zeitpunkt dem Auftraggeber jedoch nur eine Umsetzung innerhalb von fünf Monaten zusagen. Da der Auftraggeber aber nicht von seiner Zielvorgabe abgehen wollte, habe ich firmenintern den Auftrag erhalten, mir eine Lösung zu überlegen, um diese Aufgabenstellung umzusetzen.
Hat dich das nicht enorm unter Druck gesetzt?
Zu Beginn schon, weil ich zuerst nicht genau wusste, wo ich ansetzen musste. Es war ja eine Prozesskette zu erfüllen. Aber mir wurde relativ schnell klar, dass man diese Vorgabe mit herkömmlicher Denkweise und der Verwendung von traditionellen Mitteln nicht erfüllen kann. Der Zeitplan und das Budget waren vorgegeben. Das hieß also, ich musste mit den vorhandenen Ressourcen auskommen.
Nach einiger Zeit intensivster Anstrengung entwickelte ich dann folgende Idee: Eine Zeitersparnis war nur zu erreichen, wenn wir mit dem Auftraggeber eine neue Form der Zusammenarbeit etablieren und ein Teil der manuellen Pipeline in eine weitestgehende Automatisierung überführt wird. Daraus entstand die Co-Creation, bei der wir uns wöchentlich mit dem Kunden abstimmen.
Wie war das bisher, mit welchem Zeitfenster hatte man als Auftraggeber zu rechnen von der Idee bis zum Finish?
Früher vergingen manchmal vom Auftrag bis zur Freigabe ein bis zwei Jahre.
Als du diese Idee geboren hast, war dir klar, wie viel Zeit du mit dieser neuen Arbeitsweise einsparen kannst?
Zuerst nicht, denn wir mussten zuerst mit dem Auftraggeber gemeinsam ausloten, wie wir unsere Arbeitsweise gemeinsam optimieren können und welche zeitintensiven Schritte man weglassen kann, ohne dabei einen Qualitätsverlust zu haben.
Welches Mittel habt ihr zur Umsetzung eingesetzt und was war für den Kunden die massivste Neuerung in diesem Prozess?
Zum Einsatz kam die OpenShift/Docker-Architektur. Im Kernprozess muss gewährleistet sein, dass es keine manuellen To-dos mehr gibt und die einzelnen Arbeitspakete von hoher Qualität sind. Auch der Freigabeprozess seitens des Kunden musste geändert werden.
Neu ist beispielsweise, dass der Auftraggeber selbst die Änderungen in der Entwicklungsumgebung digital abnimmt und dann den Deploymentprozess selbst startet. Der Einsatz der neuen Version auf der Produktivumgebung wird dann von selbst und voll automatisiert gestartet.
Mittels Browserstack wird so voll automatisiert der Kernprozess von Applikationen auf verschiedenen Endgeräten und mit diversen Browsern getestet. Wenn auf allen Geräten alles okay ist, sprich alle Tests durch sind, dann kommen die Applikationspakete auf die QA-Umgebung zur Abnahme durch den Auftraggeber selbst.
Funktioniert das auch bei sensiblen Systemen zuverlässig?
Selbstverständlich haben wir in weiterer Folge auch ein Sicherheitsnetz installiert: ein sogenanntes A/B-Deployment. Nur ein gewisser Anwenderkreis beim Kunden bekommt einen neuen Teil der Applikation, das heißt, es gibt immer zwei Versionen am Markt. Bei Internetapplikationen gibt es einen prozentuellen Schlüssel – 10% der Apps erhalten die neueste Version. Läuft diese gut, erhalten sie automatisch auch alle anderen Anwender. Wird sie nicht angenommen oder reagiert ein gewisser Nutzerkreis nicht gut auf die Änderungen, erfolgt keine weitere Ausspielung.
Bei unseren Handelsapplikationen wie VU2, CROSS oder Retailer Apps gibt es immer ein dreistufiges Pilotprogramm, da es sich hier um sehr kritische Applikationen handelt. Damit wird vermieden, dass eine Änderung gleich ein ganzes Land oder eine gesamte Kundengruppe stilllegt. Wichtig ist ja außerdem immer, dass unsere Applikationen ständig verfügbar sein müssen, das heißt: Zero Downtime!
Als ihr dann einen Konsens gefunden hattet, wie schnell seid ihr dann tatsächlich in der Umsetzung gewesen?
Mit der Etablierung einer Co-Creation, wöchentlichen Abnahmezyklen und durch einen hohen Automatisierungsgrad bei sich wiederholenden Schritten waren es im Endeffekt 50% Zeitersparnis. Wir waren dann so schnell, dass wir sogar einige Wochen vor der Zielvorgabe fertig waren!
Wow, Gratulation! Aber legt so ein Ergebnis nicht für alle weiteren Entwicklungen die Messlatte ganz schön hoch?
Wenn man sich erstmal an die neue Arbeitsweise gewöhnt hat und so intensiv mit den Auftraggebern zusammenarbeitet, eigentlich nicht. Durch die laufenden Abstimmungen und den hohen Automatisierungsgrad geht es einfach viel schneller als vorher.
Von welcher Seite habt ihr Unterstützung bekommen? Wurde deine Idee innerhalb der Firma gefördert?
Die Geschäftsführung war von Anfang an voll überzeugt und hat das Thema auch weiter vorangetrieben und etabliert. Wenn eine Idee einen Mehrwert für den Kunden hat, damit die Time-to-Market verkürzt wird und dies dann auch zu noch mehr Kundenzufriedenheit führt, bekommt man klarerweise die volle Unterstützung – und dann wird auch eine Erfolgsstory daraus.
Eine echte Erfolgsgeschichte – gekrönt mit dem Change Award in der Kategorie „Quality“.
Wie hat sich diese Änderung auf deine eigene Arbeitsweise ausgewirkt, oder welche Auswirkungen hat dies generell auf die Rolle eines Entwicklers?
Ein Anwendungsentwickler muss künftig die Fähigkeit haben, sich voll und ganz in den Kunden hineinzuversetzen, und er muss gleichzeitig das volle technische Verständnis haben. Das heißt, Softskills, Wissen, Kreativität und Ideenfindung werden in die klassische Rolle eines Anwendungsentwicklers einfließen müssen.
Ein Anwendungsentwickler wird immer die Zukunft im Auge haben müssen, denn wenn eine Applikation gut ist und sehr gut angenommen wird, dann muss diese auch, wenn der Markt sie intensiv nutzt, jederzeit nach oben unendlich skalierbar sein. Man muss zudem immer flexibel auf den Markt reagieren können: Wenn es keine Zugriffe mehr auf eine Applikation gibt, dann muss man die Anwendung auch downgraden können, sie muss also auch nach unten skalierbar sein, und viele kleine Änderungen dürfen keine globalen Auswirkungen haben.
Das Ganze nennt man dann BizDevOps – die Verschmelzung der Entwicklung mit Business und Operation.
Wenn ihr so schnell geworden seid, heißt das, man benötigt künftig weniger Mitarbeiter?
Auch wenn wir mit der Time-to-Market fünfmal so schnell geworden sind wie vorher, brauchen wir noch jede Menge Mitarbeiter, denn die Kundenanforderungen gehen uns nicht aus!
Und wie sieht eure Vision für die Zukunft aus?
Künftig setzen wir AI (Artificial Intelligence) und VR/AR (Virtual und Augmented Reality) ein, um Kundenbedürfnisse noch besser und effizienter umzusetzen. Ein weiteres Beispiel ist die Google Vision: Künftig wird man Software nicht mehr programmieren, sondern man trainiert sie quasi, wie man einen Hund trainiert. Anwendungsentwickler werden möglicherweise Bausteine trainieren, anstatt sie selbst zu entwickeln.
Das heißt, ein Anwendungsentwickler wird in der Zukunft die Herausforderung haben, immer am Ball zu bleiben, um Tools wie AI/VR/AR als Unterstützung in der Applikationsentwicklung zielgerichtet und zeitsparend einsetzen zu können. Mit Tools wie Google Glasses und Co. können weitere Bedienelemente in unsere Applikationen integriert werden.
