• Release Management in der Softwareentwicklung – im Projekt und im Betrieb

  • Am Beispiel eines Webshops wird dargestellt, wie sich das Releasemanagement unterscheidet, je nach dem, ob der Webshop sich noch in der Entwicklung befindet oder bereits im produktiven Betrieb ist.

    In der Software-Entwicklung wird heutzutage selten nur ein Stück Software ausgeliefert und danach nicht mehr weiter entwickelt. Nach dem die Software schon einen gewissen Entwicklungsstand hat, kommt die Phase, in der die Software meist eher schrittweise vorangetrieben wird. Das gilt für Webportale genauso wie für Apps, Services oder Betriebssysteme. Es kommt also der Punkt, an dem die Software vom Entwicklungs-Projekt in den Betrieb überführt wird. Und das ist auch der Punkt, an dem sich das Releasemanagement den neuen Bedingungen anpassen muss. In welcher Weise soll hier beleuchtet werden. Die zu beantwortende Frage ist also:

    Was unterscheidet das Release Management in den Phasen „Projekt“ und „Betrieb“?

    Vorab erst einen kurzen Blick darauf, was Release Management überhaupt bedeutet:

    Eine kurze aber treffende Definition von „Release Management“:

    „Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.“

    Oder wie ITIL in der Version 3 definiert (die das Release Management als eine der ersten Theorien zurecht als eigenständige Disziplin außerhalb des Change Managements gesehen haben):

    „ITIL Release & Deployment Management ist verantwortlich dafür, zu planen, festzulegen und zu kontrollieren, wie ein Release getestet und in die Live-Umgebung ausgerollt wird. Das primäre Ziel von Release Management und Deployment Management besteht darin, sicherzustellen, dass die Integrität der Live-Umgebung geschützt wird und dass nur zuvor geprüfte Komponenten ausgerollt werden.“

     

    Wie sieht das jetzt in der Praxis aus? Nehmen wir als konkretes Beispiel einmal einen Webshop. Das Unternehmen entscheidet sich, einen Shop auf die Beine zu stellen, erstellt die Konzepte, entwickelt den Projektplan, wählt die Software und den Dienstleister und los geht’s. Das anschaulichste Beispiel ist die Entwicklung in einem agilen Projekt (z.B. nach Scrum). Hier werden ständig neue Versionen des Shops erstellt und an Stakeholder ausgeliefert. Für diese Versionen wird an allen Ecken entwickelt: Frontend, Backend, Schnittstellen zum CRM, ERP, Payment-Dienstleistern, Social Media, etc. Als Release Manager übernehme ich die Aufgabe, die Entwicklungen sinnvoll zum richtigen Zeitpunkt und in einem qualitätsgesicherten Zustand zusammenzufassen und auszuliefern. Der Shop entwickelt sich iterativ weiter. In dieser Zeit entwickelt man meist noch unter Ausschluss der Öffentlichkeit und die neuen Versionen können in der Regel ohne penible Qualitätsprüfung ausgeliefert werden, um die Weiterentwicklung nicht auszubremsen. Die durchgerutschten Fehler können ja direkt wieder beseitigt werden. Wir sind als Unternehmen ja agil…

    Dann kommt der Tag des GoLives! Unser Shop steht und wir wollen unsere Ware an die Frau und den Mann bringen. Wir gehen „in Betrieb“.

    Das heißt aber nicht, dass wir ab jetzt daneben stehen und nur ein wenig auf die Server aufpassen. Wir müssen unseren Shop Up-to-Date halten mit Bugfixes, Frontend-Anpassungen, Klein-Projekten wie Promotions, UX-Verbesserungen, neue Produktkategorien, Schnittstellenanpassungen und vielem mehr.

    Ab diesem Zeitpunkt stellen sich auf einmal ganz andere Anforderungen an das Release Management. Ab jetzt werden die meist kleineren Weiterentwicklungen in den einzelnen Bereichen zusammengefasst und jeweils live in die aktuelle Software eingespielt (deployed). Die Abwägung zwischen Geschwindigkeit und Qualität, die ich als Release Manager ja schon während des Projektes treffen musste, verschiebt sich nun mehr Richtung Qualität.

    Natürlich möchte ich unsere neuen Ideen und Verbesserungen so schnell wie möglich unseren Kunden mit einem neuen Release zur Verfügung stellen. Nur kann ich das jetzt erst erlauben, nachdem ich sicher bin, dass die neue Software auch funktioniert. Fehler werden jetzt nicht mehr so einfach verziehen und können ggf. richtig Geld kosten, wenn wir z.B. Fehler im Checkout einbauen. Das ist der große Unterschied zwischen den Releases im Projekt und denen in Produktion. Wir arbeiten jetzt sozusagen „am offenen Herzen“.

    Ich stehe jetzt zusammen mit allen Stakeholdern des Produkts vor der Frage: wie oft möchte ich in Zukunft ein Update meiner Software / meines Shops zur Verfügung stellen? Also wie eng gestalte ich meinen Release-Zyklus? Was unternehme ich, damit ich bei hoher Update-Geschwindigkeit einen höchstmöglichen Qualitätsstandard einhalte?

    Unternehmen beantworten die Frage sehr unterschiedlich: Die einen zielen auf 4-6 Releases pro Jahr und gehen hiermit größere und sicherere Schritte. Die anderen entscheiden sich für Zyklen von ggf. nur zwei Wochen bis hin zu „Continous Delivery“.

    Entscheiden sich die Unternehmen zu Gunsten der Sicherheit für große Release-Zyklen, sind die Neuerungen, die in jedem einzelnen Release gesammelt werden, umfangreicher und müssen ausgiebiger getestet werden, bevor sie live gehen. Der Releasemanager hat mehr Zeit, den Release zu planen, braucht diese aber auch, da das Zusammenspiel der einzelnen Weiterentwicklungen in den verschiedenen Bereichen koordiniert und getestet werden muss. Die gesamte Software muss sich in unterschiedlichen Umgebungen beweisen (Entwicklungsumgebungen, Testumgebungen, Deploymentumgebungen, Stagingsystemen, …). Die Software wird oft noch in ausgiebigen Regressions- und Integrationstests „per Hand“ von QAlern getestet.

    Viele Shops bewegen sich auch in Bereichen mit großer Konkurrenz. Sie sind einem großen Innovationsdruck ausgesetzt. Es gelten Schlagwörter wie „Time to Market“. Hier ist eine schnelle Weiterentwicklung wichtig. Man muss auch schnell auf Neuerungen der Konkurrenz reagieren können. Stellt mein Konkurrent neue Zahlungswege bereit, bietet er Einkaufshilfen (wie einen Geschenkefinder) oder hat er ein neues Loyalty System (wie HME)? In diesen Fällen sollten wir nicht drei Monate oder länger auf unsere Innovationen warten. Wir brauchen kürzere Release-Zyklen und das stellt an das gesamte System hohe Anforderungen. Wollen wir nämlich bei aller Geschwindigkeit unsere Qualität weiter sichern, benötigen wir Automatismen, die es uns ermöglichen, alle Schritte, die wir sonst sorgfältig manuell durchgeführt haben, schnell und effektiv zu erledigen.

    Wir sind als Unternehmen dadurch gezwungen, auf Mittel wie permanente Integration (continous integration), automatisiertes Testing und automatisierte Deploymentprozesse zurückzugreifen. Das bedeutet einen hohen Aufwand bei der Implementierung eines solchen Systems. Die einzelnen Umgebungen (Development, Test, Staging, Live) müssen penibel auf einander abgestimmt werden.

    Meine Aufgaben als Release Manager sind aber nach wie vor dieselben: stelle sicher, dass ein sinnvolles Paket von Fixes und neuen Features in einer hohen Qualität in das Produktivsystem eingespielt wird, ohne Schaden anzurichten. Wie erreiche ich das, obwohl die Zyklen immer schneller werden? Antwort: ich hole mir Hilfe. So wie der Entwicklungsprozess automatisiert wird, kann ich auch meinen Release-Prozess automatisieren. Die Details hierzu sprengen leider den heutigen Rahmen. Nur ein kleiner Tipp: eine Liste von unterstützenden Tools findet sich hier: the ultimate list of rm tools

    Gehen wir davon aus, dass die technische Basis und die notwendigen Prozesse gut vorbereitet sind und damit mehr Raum für die Auseinandersetzung mit den Inhalten bleibt. Der Releasemanager wird immer mehr zum Koordinator und Vermittler. Er stellt die Kontakte zwischen Stakeholdern her und moderiert bei Konflikten. Soziale Kompetenzen bekommen in dieser Position einen hohen Stellenwert.

    Diese Wandlung habe ich in meinen Projekten immer als sehr spannend empfunden. Es ist eine große Herausforderung, seine Rolle im Laufe der Zeit so zu interpretieren und Weiterzuentwickeln, dass ich mich auch innerhalb des Unternehmens neu aufstelle und ein ganz neues Standing erhalte. Das ist die Phase, in der man vom technischen Koordinator zum echten Release Manager wird.