Drei Zutaten für großartige Software-Releases

Irgendwann in deiner Karriere – wenn es nicht sogar schon geschehen ist – wirst du es mit einem monolithischen Software-Release zu tun bekommen. Also einem Software-Release mit hartnäckigen Bugs und Interdependenzen, bei dem das gesamte Team rund um die Uhr gefragt ist. Ganz zu schweigen von der Anzahl an Patches, die nötig sein wird, sobald er in die Produktion geht.

Die Auslieferung von Code – der Software-Release – ist ein guter Indikator der Agilität von Softwareentwicklern. Jede Bemühung, die Planung, das Programmieren und das Testen zu beschleunigen, ist vergebens, wenn der Release nicht reibungslos vonstattengeht. Deshalb nutzen Agile- und DevOps-Teams Automatisierung und bringen Programmierer und das Operations-Team schon zu Beginn der Entwicklungsphase zusammen, um auf Continuous Integration zu setzen und Probleme sofort anzugehen.

Den Code immer in Release-fähigem Zustand zu halten, ist das Gütesiegel der Agile-Entwicklung. Schlanke Planung und ein iterativer Entwicklungsansatz sind bedeutungslos, wenn der Code nicht in dem Moment ausgeliefert werden kann, in dem du entscheidest, dass er bereit ist.

Bei jedem Softwareprogramm ist es am besten, einfache, häufige Software-Releases auszuliefern. Ein Team kann Releases durch den Aufbau (oder eine Überarbeitung in Richtung) einer modularen Architektur zu einem selbstverständlichen Teil seiner Agile-Kultur machen. Einer einzigen großen Anwendung (wie dem oben erwähnten Monolith) ist eine frühzeitige Modularisierung in mehrere Teile vorzuziehen.Gruppiere ähnliche Features zu kleineren Anwendungen oder Komponenten, und sorge für klare API-Verträge zwischen allen Anwendungen und Komponenten. Diese APIs können mit jedem Build automatisch getestet werden, um so die Kompatibilität sicherzustellen und Risiken beim Software-Release zu minimieren.

Durch eine modulare Architektur muss nicht der gesamte Software-Stack auf einen Schlag veröffentlicht werden und die API-Verträge erleichtern die Aktualisierung von Komponenten und gewährleisten die Kompatibilität der verschiedenen Versionen. Kurz, in modularen Releases werden weniger Teile bewegt. Und dies sorgt für einfachere Releases.

Softwareentwicklung findet selten im Vakuum statt. Tatsächlich ist bei großartiger Softwareentwicklung das gesamte Team vom Produktmanagement bis zum Bereich Operations eingebunden. Das Operations-Team ist zum Beispiel ein Schlüsselpartner bei der Auslieferung der Software an die Produktion, da es die Software zum Endanwender bringt.

Entwicklungsteams können Operations-Teams anhand dieser Techniken informieren und unterstützen:

• Lege die Materialliste für jeden Software-Release offen. Operations-Teams verfügen nicht immer über dasselbe Hintergrundwissen zum Release wie das Entwicklungsteam.
• Verlinke jedes gelöste Problem des Release mit deinem Issue Tracker und Quellcodemanagementsystem, damit das Operations-Team auf demselben Wissenstand ist, wenn während der Bereitstellung auftreten sollten.
• Manchmal treten Probleme auf, wenn der Code von der Entwicklungsumgebung in die Staging-Umgebung übergeht. Benenne diese Probleme eindeutig, da sie während der Produktionsphase wieder auftreten könnten.
• Bei der Bereitstellung kann es zu Pannen kommen, statte deshalb das Operations-Team immer mit einem klaren Eskalationspfad aus, um die Probleme reibungslos lösen zu können.

Operations-Teams können ihre Kollegen im Bereich Entwicklung mit diesen Vorschlägen unterstützen:

• Wenn Probleme in der Produktion auftreten, nimm dir Zeit, die Ursachen und Lösungen zu verstehen. Diese Probleme lassen sich so in Zukunft vermeiden (oder eleganter beheben).
• Migriere Konfigurationsdaten von der Produktion zurück in die Staging- und Entwicklungsumgebungen, um Konfigurationsverschiebungen zu vermeiden.

Bei der Migration von Code von der Entwicklung zum Staging migrieren wichtige Konfigurations- und Nutzerdaten in entgegengesetzte Richtung: Von der Produktion über das Staging zur Entwicklung. Durch diese bidirektionale Beziehung kann die Entwicklungsumgebung die Produktionsumgebung genau nachbilden. Dies führt zu weniger Bugs und Überraschungen am Tag des Release.

Automatisieren, automatisieren, automatisieren!

Die Automatisierung von Software-Releases ist die beste Art, eine Release-Kultur zu verbessern. Wenn Software-Releases bisher noch nicht automatisiert wurden, beginne mit einer Automatisierung der Software-Releases in einer Staging-Umgebung. Sobald alle gesehen haben, wie einfach dies funktioniert, ist natürlich der nächste Schritt, nämlich die Bereitstellung für die Produktion, ebenfalls zu automatisieren.

Wenn Releases schwierig sind, solltest du dir häufige Software-Releases zur Gewohnheit machen – selbst wenn es nur Releases in die Staging-Umgebung sind. Wenn sich das Entwicklungsteam den Problembereichen von Releases bewusst wird, beflügelt das dessen Innovationsgeist, und es wird nach Wegen suchen, die Releases problemloser zu gestalten (und zu automatisieren).

Automatisierte Tests und Continuous Integration sind Schlüsseldisziplinen für großartige Releases. Achte darauf, dass die Build- und Testdauer so kurz wie möglich ist, und denke daran, dass Builds, die einfach zu validieren sind, auch einfacher zu veröffentlichen sind, weil sich der Validierungszyklus stärker am Team orientiert.

Den Code immer in releasefähigem Zustand zu halten, ist das Gütesiegel agiler Entwicklung.

Für Softwareentwickler sollte der Software-Release den Höhepunkt unseres Innovationszyklus darstellen. Wir bekommen zu sehen, wie die Kunden mit dem Code, den wir geschrieben haben, interagieren und welches Feedback sie uns geben. Juhu! Wenn Releases ein selbstverständlicher Teil deines Arbeitstags sind, ist es leichter, Code in die Produktion zu geben, und du hast die Genugtuung, sagen zu können: "Das ist mein Code!"