Noch vor 15 Jahren hat sich niemand darüber beschwert, dass Software-Features zu oft ausgeliefert werden. Heute haben dieselben Unternehmen eine andere Herausforderung: Die Software-Teams rollen neue Funktionen schneller als je zuvor aus; so schnell, dass es anderen Teams und dem Rest des Unternehmen schwer fällt, Schritt zu halten.

Früher war die Veröffentlichung eines neuen Features eine große Nummer. Das ganze Unternehmen wusste Bescheid und alle Teams waren direkt oder indirekt am Launch beteiligt. In jeder Zeit beschwerten sich Kunden und Stakeholder darüber, dass Produkte zu langsam ausgeliefert bzw. weiterentwickelt wurden. Und die Entwicklungsteams taten alles Menschenmögliche, um die Deadline des großen Launch-Events mit aller Macht zu erreichen. Die Ergebnisse waren oft langsam, verbuggt und Budget-überschreitend.

Der Fokus auf Geschwindigkeit hat ein neues Problemfeld eröffnet

Später hatte sich die Software-Industrie auf Geschwindigkeit ausgerichtet. Schnelligkeit zählte. Teams wurden immer schneller und erwarben die Fähigkeit, hundert oder tausende Male im Jahr auszuliefern. Als Analogie dazu ,wie oft ein Team deployen kann, ging es in erster Linien darum, wie schnell das Auto fahren kann und wie viel PS der Motor hat. Doch zu selten wurde der Fokus auf den Rest des Fahrzeugs und auf die Leute darin gerichtet:

• Die Bremsen, die uns durch Kontrolle letztlich schneller vorankommen lassen.
• Die Armaturen, die uns die richtigen Informationen zu richtigen Zeit auf einen Blick bieten.
• Die Fenster, durch die wir sehen können, was draußen auf der Straße passiert.
• Die Indikatoren, die eine Kommunikation zwischen den Teams ermöglichen, um ihnen dabei zu helfen, bei hohen Geschwindigkeiten besser zusammenzuarbeiten.

Continuous Delivery und die Konzentration auf Geschwindigkeit haben ein eigenes Problemfeld eröffnet. Teams, die fortgeschrittene CD-Praktiken nutzen, und ihre Stakeholder haben häufig Probleme, all die Arbeit, die durch die Deployment-Pipeline geht, wirklich akkurat zu tracken. Noch unerfahrene Teams machen sich darüber Sorgen, unter dem Geschwindigkeitsdruck mehr Fehler in kürzerer Zeit zu machen. Und nicht nur die Entwickler sind von den Auswirkungen betroffen.

• Entwickler committen Änderungen, anschließend reviewen sie diese und mergen sie in den Master-Branch, aber sie wissen nicht, wann (und wohin) diese Änderungen deployt werden.
• QS-Mitarbeiter wissen nicht, ob eine Änderung in der Testumgebung verfügbar ist.
• Product Owner wissen, dass die Entwicklung eines bestimmten Features teilweise komplett ist, aber nicht, welche Teile fertig sind und an welchen noch gearbeitet werden muss.
• Die Vertriebs- und Marketing-Teams wissen nicht, wann sie Änderungen ankündigen oder Kampagnen starten sollen. Das neue Feature kann live sein, ehe sie davon hören.
• DevOps-Engineers, die für das Deployen von Änderungen verantwortlich sind, können nicht genau sehen, was sie gerade an Kunden ausliefern, und fahren teils blind.

Doch Teams bereiten sich auf die Geschwindigkeit der Zukunft vor, indem sie die Tools und Praktiken von gestern zusammenflicken. Sie werfen mehr Tools und Integrations auf den Problem, dann tappen sie herum und suchen die Informationen, die sie brauchen.

Es gibt bereits separate Deolyment-Produkte. Aber die Probleme bleiben. Deshalb hat Atlassian für Bitbucket Deplyoments entwickelt.

Neu: Bitbucket Deployments

Nun wird der Deployment-Status im direkten Kontext des Quellcodes in Bitbucket sichtbar gemacht. Bitbucket Deployments ist ein Kernbestandteil von Bitbucket Cloud, der Teams in die Lage versetzt, ihre Deployments mit Selbstvertrauen zu tracken, in der Vorschau anzusehen und zu promoten.

Mit Bitbuckt Deployments können Nutzer eine Zusammenfassung mit den aktuellen Status jeder Umgebung einsehen, eine komplette Historie für jedes Deployment und eine Übersicht mit den Änderungen, die in dieses Deployment eingeflossen sind. Zudem gibt es eine Option, um manuelle Schritte in die Pipeline einzubauen – etwa wenn ein Deployment in die Staging- oder die Produktiv-Umgebung geht.

Wenn das Maß an Sicherheit und Selbstvertrauen zunimmt, wenn die Verlässlichkeit steigt, wirkt sich das auf die Fähigkeit zur Beschleunigung aus. Schnellere Releases, wenn der Markt und die Kunden es verlangen. Mehr Automatisierung adaptieren, wenn der Markt und die Kunden es verlangen. Oder etwas Verlangsamung, um sicherzustellen, dass die Pipelines genau so laufen, die die Teams es brauchen.

Eine höhere Geschwindigkeit sollte nicht der einzige Aspekt sein, wenn es um moderne Software-Entwicklung geht. Bessere, nutzerfreundlichere und sinnvollere Software sind ebenfalls hehre Ziele.

Bleibt die Frage, ob und wann auch Server-Kunden von diesen Möglichkeiten profitieren werden können - vielleicht in Form künftiger Bamboo-Features. Dazu haben wir zurzeit leider keine Infos und Atlassian hält sich hier etwas bedeckt, wie analog dazu diese Kundenfrage zu Bitbucket Pipelines zeigt. Wir halten Sie hier auf Laufenden.

Bamboo Server einführen und/oder lizenzieren? Wir sind Ihr Partner!

Interessieren Sie sich für Bamboo von Atlassian als Integrations-Server? Wir sind Atlassian Platinum Solution Partner und einer der größten Atlassian Experts weltweit: Gerne beraten wir Sie und unterstützen Sie bei der Lizenzierung sowie bei allen Aspekten der erfolgreichen Einführung und produktiven Nutzung. Bitte sprechen Sie uns unverbindlich an.

Ausführliche Infos über Bamboo, seine Features und sein Lizenzmodell in unserer Infothek
Bamboo: Wie viele Build Agents braucht mein Projekt?
Continuous Integration: Zehn Argumente für Bamboo
Tipps für Bamboo in DVCS-Teams