Eine Geschichte über DevOps

Zehn Releases am Tag
Kommentare

Freitag, früher Nachmittag – der Rollout steht an. Die Anspannung ist beim ganzen Team spürbar. Alle sind da, Manager und Entwickler. Jeder wartet darauf, dass der letzte Build durchläuft. Die Admins bereiten sich darauf vor, die finale Version in die Produktionsumgebung einzuspielen. Denn am Montag muss alles funktionieren. Dann ist der große Tag – unser Release geht live. 

Der Vertrieb hat unsere Kunden informiert, am Montag ist die große Launch-Veranstaltung. Im Anschluss wird die neue Produktversion live geschaltet. Deren Erfolg oder Misserfolg wird über die Zukunft unserer Firma entscheiden. Es muss einfach klappen. Doch wir sind zuversichtlich. Die Arbeit von fast zwei Jahren wird sich auszahlen. Schon zu Beginn war uns klar: wir sind mit unserem Produkt weit hinter unseren Mittbewerbern. Der Vorstand war alarmiert, Gelder wurden genehmigt, das Projekt „Aufholjagd“ gestartet. Für mich bedeutete dies zahllose Überstunden, und in den letzten Wochen hat unser Team an den Wochenenden praktisch durchgearbeitet. Die harte Arbeit hat sich jedoch gelohnt: Wir haben die benötigten Funktionen implementiert. Damit stehen wir sogar besser da als unsere Mitbewerber.

Risiko Big-Bang-Release

Noch ist es jedoch nicht ganz so weit. Wir sind nervös. Alle sagen sich: es wird schon klappen. Wir haben ausgiebig getestet, und außer ein paar kleineren unkritischen Bugs, die wir schon kennen, sollte eigentlich alles rund laufen. Jetzt können wir also nur noch warten – auf Montag, den großen „Big Bang“-Releasetag. Ob alles gut geht, ist schwer zu sagen, wenn man nur alle eineinhalb Jahre ein neues Release präsentieren kann. Wir haben damit einfach keine Erfahrung.

Immer wieder gab es Diskussionen im Team: Wie werden die Kunden auf unsere neuen Features reagieren? Wird der Server auch unter Last gut funktionieren? Einige der neuen Funktionen belasten die Datenbank doch mehr als bisher. Und es ist nicht zu leugnen, dass einige der Features auch heute schon wieder ein wenig angestaubt sind – der Markt hat sich, seit die Anforderungen geschrieben wurden, doch ziemlich verändert. Klar, unsere Firma entwickelt Software noch nach dem klassischen Wasserfallmodell. Anforderungen möglichst komplett erfassen, dann eine lange Implementierungsphase, die Tests und nötige Bugfixes, dann das Release. So war das schon immer bei uns.

Big-Bang-Releases

Das Team arbeitet monate- oder jahrelang an einem Projekt mit der Intention, das entstandene Produkt mit einem „großen Knall“ als Ganzes live zu stellen. Big-Bang-Releases werden oft mit klassischer Wasserfallentwicklung in Verbindung gebracht, aber auch Scrum-Teams können sich dazu gezwungen sehen.

Agilität mit Hindernissen

Meine Gedanken schweifen ab, und ich denke an das Meeting unserer .NET User Group am letzten Mittwoch. Viele Kollegen, die ich dort treffe, arbeiten in ihren Projekten nach agilen Methoden, Start-up-Style. Kurze Zyklen von zwei Wochen. Das gibt ihnen die Möglichkeit, die Anforderungen ständig neu zu priorisieren und schnell auf Veränderungen im Markt zu reagieren.

Am Ende jedes Zwei-Wochen-Sprints liefern die agilen Teams funktionierende, getestete Software aus. So können sie den Nutzern die neuen Features früher in die Hände geben, erhalten früher echtes Feedback und können darauf auch schnell reagieren. Und sie sehen auch gleich, ob die Software im realen Betrieb stabil und performant läuft. Eigentlich also eine prima Sache. In der Theorie.

Die Realität sieht aber oft anders aus. Beim Bier nach dem User-Group-Vortrag erzählte mein Freund Peter ‑ selbst Mitglied eines agilen Teams ‑ von seinem momentanen Hauptproblem: „Es macht schon Spaß, in Sprints zu arbeiten und die Arbeit im Team selbstbestimmt zu organisieren. Cool ist auch, dass man regelmäßig Resultate in Form von fertiger Software sieht – man weiß, was man geleistet hat. Aber dann der Frust mit den Jungs aus der IT …“. Peter seufzte.

Schwachstelle agile Releasepipeline

„Wir liefern alle zwei Wochen Software an unseren Product Owner“, fuhr er fort, „der ist auch meist glücklich. Aber dann geht erst einmal wenig weiter. Denn unsere Admins müssen ja nun die Software auch auf die Server ausrollen – und das kann dauern. Schließlich haben wir immer noch den guten alten Stufenprozess für das Deployment. Du kennst das: Die Bits müssen erst von unserem Development-Server auf den Staging-Server kopiert werden, dabei ist auch noch jede Menge Konfigurationsarbeit nötig. Wenn im Staging alles funktioniert, kann die Software auf dem Produktionsserver installiert werden. Und jedes dieser Deployments muss zwischendrin von verschiedenen Verantwortlichen getestet und freigegeben werden. Die Tests sind zeitaufwändig. Und wehe, da ist mal jemand im Urlaub – dann kommt der ganze Prozess einfach zum Stillstand. Zudem machen die Admins vieles beim Deployment noch manuell. Sie verlangen von uns genaue Change Logs und detaillierte Deployment-Anleitungen, damit sie wissen, welche Files sie wie einspielen müssen und was konfiguriert werden muss. Aber oft passieren trotzdem noch Fehler, dann rufen Sie bei uns an und wir müssen helfen.

Peter nippte nachdenklich an seinem Bier. „Im Endeffekt dauert es dann doch wieder ein halbes Jahr, bis die Nutzer unsere Software wirklich verwenden können. Denn die IT sammelt erst einmal die Ergebnisse von ein paar Sprints, bis sie die Software als Endkundenrelease ausrollen. Sie sagen, das schaffen sie nicht alle zwei Wochen. Und selbst wenn das Deployment schneller ginge: Unsere QA-Abteilung braucht allein drei Wochen für einen kompletten Testdurchlauf. Finden sie einen Bug, wird auf eine neue Version gewartet, die den Bugfix beinhaltet, aber auch die neuesten Funktionen. Und dann wird diese Version getestet. Es ist fast nicht vorhersagbar, wann wir eine Version haben werden, die unsere Testsuite erfolgreich durchläuft.“

Herausforderung Produktivbetrieb

„Wenn die Software dann produktiv läuft, hören wir oft erst wieder was von den Admins, wenn es Fehler gibt. Neulich hatten wir große Probleme, da war die Performance unserer App plötzlich extrem schlecht. Verärgerte User hingen schon bei unserer Hotline in der Warteschleife. In einer solchen Situation klingelt dann bei uns das Telefon Sturm – und wir Entwickler sollen den Fehler sofort beheben. Also haben wir unsere reguläre Arbeit unterbrochen und hektisch versucht, die Anwendung im Produktionsbetrieb zu debuggen – und ihr wisst ja, wie schwierig das ist. Da ist es dann aus mit der agilen Theorie.“

Ich nickte stumm, das Problem kam auch mir sehr bekannt vor. Peter schwieg, schaute auf sein fast leeres Bierglas und winkte der Bedienung, Nachschub zu bringen. Mein Blick fiel auf mein Smartphone.

Zehn Releases am Tag?

„Tja, Facebook, Amazon oder Flickr – da müsste man arbeiten“, meinte ich. „Die können angeblich zehnmal pro Tag oder häufiger neue Funktionen an die Enduser ausliefern. Das ist cool!“ Peter war wenig beeindruckt: „Mit diesen Megakonzernen können wir uns doch nicht vergleichen. Bei uns ist so etwas einfach nicht drin.“ Ich wurde nachdenklich. „Eigentlich geht es doch gar nicht darum, wirklich zehnmal am Tag neue Funktionen bereitzustellen. Das brauchen vielleicht echt nur die Internetgiganten. Aber es wäre schon hilfreich, wenn wir in der Lage wären, sozusagen auf Knopfdruck sehr schnell eine neue Funktionalität in Produktion zu bringen.“

Marie – unser User-Group-Urgestein und leidenschaftliche Webprogrammiererin – hatte sich bis jetzt neben uns ein wenig müde und lustlos an ihrer Cola festgehalten. Jetzt wurde sie aber plötzlich wach. „Erzählt mir was Neues!“, sagte sie resigniert. Peter und ich schauten sie an und Marie klagte uns ihr Leid.

Paradebeispiel Hotfix

„Es hat seinen Grund, dass ich heute Abend so spät zu unserem User-Group-Treffen gekommen bin. Wir hatten in der Firma nämlich den Super-GAU. Ein Kunde hatte durch Zufall ein Sicherheitsloch gefunden, direkt in unserer Kundenverwaltung! Und das, nachdem die Nachrichten voll sind von Datenklauskandalen bei allen möglichen Firmen. Unser Entwicklungsleiter wurde weiß wie Schnee. Wir haben alles liegen gelassen und sofort einen Hotfix zusammengeschustert. Als der fertig war, erhielten wir ausnahmsweise die Erlaubnis, eine Abkürzung für das Deployment zu nehmen – normalerweise haben wir natürlich auch einen Genehmigungsprozess wie bei Peter. Kurz und gut, wir haben eine DLL mit dem Hotfix direkt auf die Produktionsserver kopiert. Es musste ja alles sehr schnell gehen. Damit fingen die Probleme aber erst richtig an, denn die DLL war nicht kompatibel zur bisherigen Version. Jemand hatte inzwischen ein paar Interfaces geändert – und jetzt stand das ganze System! Hätten wir nur unsere Testsuite einmal drüber laufen lassen. Naja, ich mach’s kurz, nach vier Stunden liefen die Server wieder. Das war vielleicht ein Alptraum!“

Marie verstummte und sah Michael an, unseren immer gut gelaunten User-Group-Sunnyboy. „Was gibt‘s denn da zu grinsen? Solche Probleme kennst Du wohl nicht, oder?“

DevOps: nur ein neuer Hype?

„Oh doch!“, gab Michael zurück. „Das kenne ich sehr wohl. Ich wollte auch nicht arrogant wirken. Es ist nur so: bei unserem aktuellen Projekt haben wir in meinem Team einmal versucht, mehr auf DevOps zu setzen. Seitdem ist alles anders.“

„Ja, klar, noch ein hippes Buzzword, das braucht die Welt!“, mischte sich Peter ein. Inzwischen war aus unserem Gespräch eine kleine Diskussionsrunde geworden und es hatten sich sogar Leute von den anderen Tischen dazugesellt. „Sicher wäre es gut, wenn Developer und Admins besser zusammenarbeiten würden. Um das zu verstehen, brauche ich keinen neuen Hype.“

Michael nickte: „Ja, ich dachte auch erst, es geht einfach nur um die Verbesserung der Zusammenarbeit von Entwicklung und Betrieb. Aber als wir uns im Team damit auseinandergesetzt haben, wurde schnell klar: DevOps hat zwar auch mit guter Zusammenarbeit von „Devs“ und „Ops“ zu tun, ist viel aber mehr als das.

Große Worte, ich weiß. Wir haben damit schrittweise angefangen und zuerst unseren gesamten Releaseprozess mit Visual Studio Release Management automatisiert. Wenn wir einen Release-Build durchführen, wird der Build automatisch mit vorgefertigten Skripten erst auf die Dev-Umgebung, dann auf die Staging- und schließlich auf die Produktionsumgebung aufgespielt. Das heißt, wir testen damit nicht nur unsere Software, sondern auch unseren Deployment-Prozess.

Mit Release Management können wir sogar den Genehmigungsprozess für die einzelnen Stufen definieren. Für einige zentrale Vorgänge gibt es einen Verantwortlichen, der den jeweiligen Deployment-Schritt genehmigen und prüfen muss. Das gilt bei uns zum Beispiel für die endgültige Produktionsfreigabe. Die entsprechende Person bekommt vom System eine E-Mail und kann die Freigabe auf einer speziellen Website erteilen oder zurückweisen. Andere Schritte sind automatisiert, werden aber auch automatisch protokolliert. Man sieht jederzeit, welches Release von wem angestoßen wurde, und wer wann was freigeben oder testen muss.“

Grundprinzipien von DevOps

DevOps beschäftigt sich mit dem Thema, wie Software nicht nur besser gebaut, sondern auch bereitgestellt und betrieben wird. Der Begriff ist relativ neu und wird oft nur mit der kontinuierlichen Bereitstellung gleichgesetzt. Doch diese Definition greift zu kurz. In der Praxis erfordert der DevOps-Ansatz, dass die gesamte IT-Organisation in einen vollständigen Lifecycle (ALM) investiert. Ziele dabei sind:

  • Die Durchlaufzeiten zu minimieren (d. h. den Zeitraum vom Beginn der Implementierung eines Features bis zur tatsächlichen Verfügbarkeit für den Anwender zu verkürzen)
  • Die Ressourcen durch automatisiertes Ausrollen von Systemen und Updates zu optimieren
  • Qualität und Verfügbarkeit der Anwendungen mit durchgängigen Tests und Überwachung sicherzustellen

Releaseautomatisierung als Basis

„Die Skripte für den Deployment-Prozess haben wir in Zusammenarbeit mit unseren Admins entwickelt – zusammen mit Rollback-Skripten. Diese versetzen den Server in den ursprünglichen Zustand, falls bei einem Deployment irgendetwas schief geht. So ähnlich wie bei Datenbanktransaktionen. Im Build laufen natürlich Unit Tests, Integrationstests und auch die Coded UI Tests, die bei uns die wichtigsten Funktionalitäten abbilden. So haben wir eine hohe Sicherheit, dass ein neues Deployment keinen Schaden anrichtet.“

Macht Sinn! Hätten wir dieses automatisierte Deployment auch bei uns gehabt, wäre mein Tag anders verlaufen“ meldete sich Marie. „Zum Beispiel hätten die Integrationstests wegen der inkompatiblen DLL Alarm geschlagen – und wir hätten durch die Skripte trotz des Zeitdrucks wahrscheinlich keine Fehler beim Ausrollen des Fixes gemacht.“

Peters Miene erhellte sich: „Also braucht ihr die Admins nicht mehr? Alles wird per Skript installiert?“ „Nein, das würde ich nicht sagen. Die Rolle unserer Admins hat sich verändert. Wir sind jetzt ein Team und arbeiten eng zusammen. Denn das Ganze ist auch eine Kulturfrage. Wir tauschen uns viel mehr und viel früher darüber aus, wie sich eine Applikation installieren, warten und überwachen lässt.“

Kleine Schritte machen

Er hielt kurz inne und überlegte. „Aber es stimmt schon, die Automatisierung hilft und ist ein sehr wichtiger Aspekt. Dadurch, dass unser Deployment jetzt so rund läuft, ergeben sich viele andere Vorteile. Nicht nur beim Einspielen von Bugfixes. Wir liefern jetzt wirklich viel öfter an die Endkunden aus, dafür kleinere Päckchen. Wir können so auch neue Features in der echten Welt testen. Und bei kleinen Schritten ist es einfach unwahrscheinlicher, dass wir einen fatalen Fehler einbauen. Wir haben auch ganz einfach mehr Übung beim Deployment! Das ist für uns kein großes Ding mehr.“

Build, Measure, Learn

Michael blickte in die Runde. Er hatte unsere volle Aufmerksamkeit. „Aber das reicht uns nicht.“, fuhr er fort. „Wir wollen viel genauer verstehen, welche Features wie oft genutzt werden und wie sich unsere Anwendung im realen Betrieb verhält. Mit IntelliTrace in Produktion können wir Fehler im Produktivbetrieb sehr schnell analysieren.

Außerdem testen wir gerade Application Insights. Mit diesem Framework können wir unsere Webanwendung mit wenig Aufwand instrumentieren. Wir erhalten im laufenden Betrieb Echtzeitdaten über alle möglichen Aspekte unserer Applikation – von der Performance über die Häufigkeit, mit der bestimmte Funktionen genutzt werden, bis zu auftretenden Exceptions. Allerdings gibt es im Team noch einige Diskussionen, denn diese Telemetriedaten laufen über den Microsoft-Server. Das möchte nicht jeder. Zudem ist die Technologie momentan erst als Preview verfügbar. Mal sehen, wie sich das entwickelt – ansonsten gibt es auch von anderen Herstellern leistungsfähige Alternativen.

Peter hatte jetzt auch Feuer gefangen: „Wow, also könnt ihr im wörtlichen Sinn morgen sehen, was eure Änderungen von heute bewirken, wie gut sie angenommen werden, aber auch wie gut der Code wirklich läuft!“ „Ja“, ergänzte Michael „eben nach dem Motto ‚Build, Measure, Learn‘. Etwas bauen, dann messen, was passiert, um daraus wiederum zu lernen. Das ergibt einen richtigen Kreislauf der Verbesserung!“

Lohnende Herausforderungen

„Okay, aber ist es nicht eine dumme Idee, neue Features gleich an alle Kunden auszuliefern und diese sozusagen als Versuchskaninchen zu benutzen?“ konterte Marie. „Ziemlich mutig, oder eher unverantwortlich, würde ich sagen.“

Michael grinste: „Ja, da hast du recht. Aber wir sind dabei, unseren Code so umzuschreiben, dass wir neue Funktionen per Konfiguration ein- und ausschalten können. Mit Feature Flags – dafür gibt es übrigens schon einige Frameworks bei NuGet. Der Plan ist, dass wir die neuen Features erst für einige wenige Kunden aktivieren. Falls alles gut läuft, schalten wir immer mehr Nutzer frei. Das sehen wir ja durch die Telemetrie. Das nennt sich Test in Production. Noch haben wir da ein Stück Arbeit vor uns, denn wir müssen dafür die Architektur unserer Anwendung erst noch fit machen. Aber ich denke, der Aufwand lohnt sich. Kommerzielle Services wie Visual Studio Online gehen schon länger so vor.“

Marie war noch immer skeptisch: „Denkt ihr nicht, dass die Kunden verstört reagieren, wenn ständig neue Features einfach so dazukommen, ohne dass man sich wie bisher bei einem großen Release darauf einstellen kann?“

„Ja, das stimmt, die Leute müssen umdenken“ stimmte Michael zu. „Aber diese Art, neue Funktionalität auszuliefern, ist für die Nutzer eigentlich bekannt – schließlich hat so gut wie jeder ein Smartphone. Für die meisten Apps gibt es sehr häufig neue Versionen, die meist ohne Nachfrage automatisch installiert werden. Ich denke sogar, dass diese schnellen Releasezyklen von den Nutzern in Zukunft bei jeder Art von Software erwartet werden – Stichwort ‚Consumerization of IT‘“.

Peter grinste: „Genau! Wäre ja noch schöner, wenn man ein CD-Laufwerk ans Handy anschließen müsste und die Software alle Schaltjahre auf CD geliefert würde. Aber bei vielen klassischen Anwendungen ist das im übertragenen Sinn immer noch so! Bei Webanwendungen oder bei lokalen Anwendern ist das Problem, die Software auszuliefern, ja auch nicht so groß.“

Michael nickte zustimmend. „Dabei gibt es schon lange Möglichkeiten, auch normale Clientsoftware unter Windows einfach und sicher regelmäßig upzudaten. ClickOnce ist der Klassiker unter diesen Frameworks. Aber es gibt mittlerweile auch genügend andere Möglichkeiten, die Funktionalität an die User zu liefern, z. B. per Push-Verteilung über NuGet. Für diese Aufgaben gibt es Open-Source-Bibliotheken. Oder man löst das mit eigenem Code.

Wir haben als Konzeptstudie zum Beispiel einen kleinen Prototyp geschrieben, der das Managed-Extensibility-Framework und Windows Communication Foundation Services nutzt und Softwarekomponenten im laufenden Betrieb austauscht.“

„Könnte man damit sogar Software, die im 24/7-Dauerbetrieb im Einsatz ist, im laufenden Betrieb updaten?“ fragte Peter.

„Das würde gehen! Auch das machen die großen Internetkonzerne ja heute schon. Schließlich können die bei diesen häufigen Updatezyklen nicht immer das System offline nehmen. Aber es gibt schon einige Herausforderungen, wenn man den DevOps-Ansatz konsequent bis auf dieses Niveau verfolgt. Security ist ein Thema, es darf auf keinen Fall möglich sein, dass Angreifer von außen Software in den Releaseprozess einschleusen können. Und wie ich vorher schon gesagt habe: um wirklich voranzukommen, ist es nötig, ganzheitlich zu denken ‑ von der Softwarearchitektur über die richtigen Tools bis zu den Frameworks muss alles passen.

Aber die Chancen, die sich durch DevOps ergeben, sind so groß, dass es sich lohnt, konsequent an den Herausforderungen zu arbeiten. Dann könnte man viele Vorgehensweisen, die in der Welt der Smartphones schon Standard sind, auf andere Applikationen und Anwendungsfälle ausweiten.

Neue Chancen und Geschäftsmodelle

Denkt mal an einen Werkzeugmaschinenhersteller. Dessen Software läuft auf Maschinen, die auf der ganzen Welt verteilt sind. Dort wäre es ein fantastischer Vorteil, wenn diese Software automatisch und ferngesteuert ausgetauscht werden könnte, womöglich ohne die Produktion unterbrechen zu müssen! Da würden sich ganz neue Geschäftsmodelle ergeben, denn die Firma könnte das als zusätzliche Vertragsoption zur Hardware anbieten. Wir haben einige Kunden, die von dieser Idee total begeistert sind! Natürlich ist das bei Industriemaschinen nicht so einfach wie beim Handy, da gibt es neben den erhöhten Security-Anforderungen noch ganz andere Themen, zum Beispiel müssen dort formale Freigabeprozesse eingehalten werden und vieles mehr.“

Die nächste Stufe der Agilität

Die Diskussion war lange noch nicht zu Ende, und wir wurden schließlich vom Wirt der Gaststätte um halb eins hinauskomplimentiert.

Marie brachte es schließlich auf den Punkt: „Jetzt verstehe ich auch, was ich neulich gelesen habe. Jemand meinte, DevOps wäre die nächste Stufe der Agilität. Eigentlich ist es ja eine logische Fortsetzung der agilen Prinzipien: kurze Zyklen, Fokus auf die Realität, immer dazulernen.“

„Tja, apropos Lernen“ meinte Michael noch im Hinausgehen – ich hab da noch einen Lesetipp für Euch: „The Phoenix Project“ – ein spannendes Buch über DevOps, das die ganzen Prinzipien erklärt, und zwar in Form einer fesselnden Geschichte“ (siehe: Kim, Gene; Behr, Kevin; Spafford, George: „The Phoenix Project. A Novel About IT, DevOps, and Helping Your Business Win“, IT Revolution Press, 2013, ISBN 978-0988262591)

Tja, und ich musste zurück in die Realität, zurück in mein Team. Denn am Montag ist der große Releasetag. Big Bang.

Hoffentlich geht alles gut! Und wenn nicht: in Michaels Team ist noch eine Stelle frei …

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -