Diese von David Clarke, verfasste Workday Story wurde erstmals auf Englisch im Workday-Blog veröffentlicht. Unsere lokalen Leser finden im Folgenden eine deutsche Version des Beitrags.
Warum wir die Entwicklung bei Workday auf eine Single Codeline umgestellt haben
Bei Workday haben wir von Anfang an das Prinzip „Power of One“ geglaubt. Da die Entwicklungs- und Supportteams von Workday nur eine einzige Version betreuen, können alle Kräfte für die Weiterentwicklung dieser Version eingesetzt werden. Damit entfällt der unnötige Arbeitsaufwand, der zwangsläufig mit dem Support mehrerer Versionen verbunden ist. Der erforderliche Aufwand für die Betreuung mehrerer Versionen ist der größte Nachteil für Softwareanbieter, die mit dem Cloud-Modell konkurrieren.
Wir haben vor Kurzem Anpassungen an unserem Entwicklungsprozess vorgenommen, die das Prinzip des „Power of One“ unterstreichen. Sie ermöglichen es uns, durchgängiger aktuelle Neuerungen bereitzustellen, und den Kunden, umfangreiche Anwendungsupdates leichter durchzuführen.
Bis Ende 2013 hatten wir Änderungen und neue Funktionen in Batches zusammengefasst, um sie unseren Kunden in Form von drei groß angelegten Updates pro Jahr bereitstellen zu können. Wir haben außerdem wöchentlich Patches für die Behebung kritischer Fehler veröffentlicht und diese dann in das nächste planmäßige Update integriert. Dieses Modell funktionierte jahrelang sehr gut, als aber Workday und die Software expandierten, begannen wir, diesen Ansatz zu überdenken.
Er hatte vor allem im Hinblick auf Updates bestimmte Nachteile: Erstens konnten wir unseren Kunden Softwareänderungen nicht durchgängig und phasenweise, sondern nur im Rahmen groß angelegter Updates bereitstellen.
Zweitens lief der Branching-Ansatz darauf hinaus, dass wir den Kunden neue Funktionen nicht außerhalb der regulären Updates zugänglich machen konnten und bestimmte Funktionen unter Umständen erst Monate nach der Entwicklung eingeführt wurden. Auch die getrennte Implementierung von Bugfixes im „aktuellen Produktivzweig“ unserer Kunden und dem separaten Entwicklungszweig für das „nächste Update“ war umständlich.
Drittens hatten wir kein einheitliches Verfahren, um vorgeschlagene Neuerungen oder Verbesserungen fortlaufend von Kunden testen zu lassen und ihre Rückmeldungen dazu einzuholen. Wir haben uns zu einer agilen Bereitstellung verpflichtet. Das Echtzeitfeedback unserer Kunden zur laufenden Entwicklung ist daher äußerst wertvoll.
Und schlussendlich haben wir in den letzten Jahren massiv in die Umstellung auf einen durch und durch agilen Entwicklungsprozess investiert, der auf kontinuierlicher Integration und einer besonders umfangreichen Automation von Funktions- und Leistungstests basiert. Wir gelangten also allmählich zu der Überzeugung, qualitative Verbesserungen in der Produktivumgebung nicht nur dreimal jährlich im Rahmen groß angelegter Updates, sondern kontinuierlich bereitstellen zu können.
Für einen Anbieter von SaaS-Lösungen sind Verzögerungen bei der Bereitstellung vorhandener Funktionen in etwa mit der Aufstockung von Lagerbeständen in der Fertigungsindustrie vergleichbar. Sie ermöglicht keine effiziente Nutzung wertvoller Ressourcen (in unserem Fall der Entwicklungszeit) und deutet auf Probleme in der Lieferkette hin (in unserem Fall waren es nur drei Releases mit neuen Funktionen pro Jahr).
Unsere Entwicklung wurde darüber hinaus von verbraucherorientierten Internet-Trends beeinflusst, bei denen das gesamte „Release“-Konzept weitgehend überholt ist. Google und Facebook nummerieren ihre Versionen nicht. Sie führen Änderungen und Funktionen perzeptiv und schrittweise ein, verbessern die Kundenerfahrung fortwährend und vermeiden Rückcodierungen. Warum sollte es bei Enterprise-Software in der Cloud anders sein? An dieser Stelle sollten wir auf die außerordentlich aufschlussreichen Gespräche mit unseren Kollegen bei LinkedIn verweisen, die vor etwa 18 Monaten eine ähnliche Umstellung durchliefen.
Dementsprechend führten wir im Januar nach umfangreicher interner Planung und Entwicklung unser neuestes Update Workday 21, den Nachfolger von Workday 20, ohne Branching ein. Mit anderen Worten: Von diesem Tag an hatte Workday nur noch eine einzige Zeile Programmcode. Sämtliche Änderungen werden in diese Codezeile eingepflegt und jeden Freitag aus dem Trunk in die Produktivumgebung übernommen.
Um diesen Ansatz zu ermöglichen, mussten wir in Bezug auf die Erstellung der Builds, das Testen und die Bereitstellung von Workday umdenken. Das grundlegende Konzept für unsere Entwicklungsstruktur waren von nun an Vertrauensbereiche. Wir haben davon drei: den internen, die Vorschau und die Produktivumgebung. Einer dieser Vertrauensbereiche wird jeder Änderung zugewiesen. „Interne“ Änderungen erscheinen nur in unseren internen Entwicklungs- und Testsystemen. „Vorschau“-Änderungen sind nur Kunden in ihrer eigenen Vorschau-Sandbox zugänglich – auf diese Weise können sie die Änderungen testen, bevor sie in die Produktivumgebung einfließen. Und „Produktivänderungen“ werden in die Live-Systeme eingespielt und allen Kunden immer freitags bereitgestellt.
Wie lange es dauert, bis die einzelnen Änderungen die Vertrauensbereiche durchlaufen, hängt von ihrer Dringlichkeit und Priorität ab. Diese Entscheidungen werden von einem Produkt-Scrum-Team getroffen. Pro Woche nehmen wir über 1.000 Änderungen an der Codezeile vor. Ein Großteil sind interne Änderungen, der Rest verteilt sich auf die Bereiche „Vorschau“ und „Produktivumgebung“.
Unsere neue Benutzeroberfläche
Ein Beispiel eines Features, das wir im Rahmen dieses Ansatzes bereitgestellt haben, war unsere neue Benutzeroberfläche. Sie wurde Anfang Januar als Vorschau in der Sandbox bereitgestellt und ist seit Anfang Februar in der Produktivumgebung verfügbar. Durch die Interaktion mit unseren Kunden im „Vorschaumodus“ konnten wir Probleme mit der Bedienbarkeit und weiteren Aspekten beheben und so die allgemeine Kundenerfahrung in der Produktivumgebung entscheidend verbessern.
Den Code wöchentlich vom Trunk in die Produktivumgebung zu pushen, stellt unser Continuous-Integration-System stark auf die Probe, trägt aber zur ordnungsgemäßen Durchführung der Test- und Automatisierungsabläufe bei. Jeder Änderung eines Entwicklers wird in allen Vertrauensbereichen (intern, Vorschau und Produktivumgebung) fortlaufend in umfassenden Modul- und Systemtest-Pipelines von Workday geprüft. Dafür zu sorgen, dass diese Pipelines immer „grün“ testen, ist die beste Qualitätsgarantie und macht eine Rückcodierungen überflüssig. Es ist außerdem ein hervorragender Indikator für das Niveau unseres Entwicklungsprozesses. Wir bringen über eine Million Rechenstunden pro Monat auf – nur für die Ausführung der Test-Pipelines und auf ein positives Ergebnis. Für uns ist das eine erstklassige Investition.
Wir haben auch massiv in Technologie investiert, die eine Konvertierung im Hintergrund ermöglicht, damit wir Änderungen an der Datenstruktur vornehmen können, die keinerlei Auswirkungen auf die Kunden haben. Wir haben ferner die stufenweise Einführung von Funktionen in die Produktivumgebung neu durchdacht, um die Zuverlässigkeit zu maximieren und Risiken zu minimieren.
Nur weil wir jederzeit Änderungen in der Produktivumgebung vornehmen können, heißt das selbstverständlich noch lange nicht, dass wir es auch tun sollten. Wir haben präzise „Funktionsregeln“ definiert, die uns dabei helfen, zu entscheiden, wann eine Offline-Funktion in die Vorschau oder Produktion gehen soll. Einige Änderungen haben potenziell weitreichende Auswirkungen oder sind besonders auffällig. Daher stellen wir sie lieber im Rahmen eines formellen Updates bereit, die wir nun nicht mehr dreimal, sondern nur noch zweimal jährlich durchführen. Kunden müssen diesen Änderungen womöglich etwas Zeit widmen und sich darauf vorbereiten. Mit weniger Updates ist daher insgesamt auch ein geringerer Zeitaufwand verbunden.
Aber andere Änderungen – etwa jene, die die Leistung oder Skalierbarkeit verbessern – können und sollten wöchentlich durchgeführt und im Vorfeld besonders strengen Tests unterzogen werden. Als Cloudanbieter haben wir den Vorteil, tiefe Einblicke in sämtliche Bereiche zu erhalten, in denen unsere Dienste genutzt werden. Deshalb können wir uns bei der Beurteilung der Risiken und Vorteile von Softwareänderungen in einem bestimmten Bereich auf Daten stützen.
Das bedeutet, dass Updates für Workday kein technisches „Big Bang“-Szenario mehr sind, sondern vielmehr eine Einführung von Funktionen, mit denen die Kunden dank der Vorschau-Sandbox bereits gründlich vertraut sind. Und einige Funktionen werden selbstverständlich über die wöchentlichen Serviceupdates in die Produktivumgebung eingespielt. Auch wenn Workday jetzt nur noch zwei formelle Updates pro Jahr durchführt, ist unser Entwicklungs- und Bereitstellungsprozess dank des trunkbasierten Entwicklungsmodells jetzt von Grund auf kontinuierlich und inkrementell. Wir glauben, dass dieser Ansatz für uns und unsere Kunden vorteilhafter ist und die auf dem Prinzip „Power of One“ basierende Geschäftspartnerschaft vertieft.
Wir investieren nach wie vor verstärkt in eine Reihe proprietärer und Open-Source-Tools und -Technologien, um unseren Entwicklungs- und Bereitstellungsansatz weiter zu optimieren. Falls Sie sich für die kontinuierliche Integration und Bereitstellung interessieren, umfassende Erfahrung in diesem Bereich mitbringen und nach Karrieremöglichkeiten suchen, nehmen Sie doch Kontakt zu uns auf.