© Liashko/Shutterstock.com
Entwickler Magazin
Eine Geschichte über DevOps

Zehn Releases am Tag

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.

Thomas Schissler, Uwe Baumann


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-ReleasesDas 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-...

Entwickler Magazin
Eine Geschichte über DevOps

Zehn Releases am Tag

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.

Thomas Schissler, Uwe Baumann


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-ReleasesDas 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-...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang