Warum sind agile Methoden für Continuous Delivery unverzichtbar?

Eine Auslieferung am Ende jedes Sprints ist durchaus machbar. Hier erfährst du mehr darüber.

Ian Buchanan Ian Buchanan

Agile Methoden können auf zwei Arten betrachtet werden: Rezepte und Sensoren. Erfahrene Softwareentwickler haben Methoden dokumentiert, mit denen sie am produktivsten arbeiten konnten. Darüber hinaus zeigen die Methoden auf, wo wir unproduktiv sind, indem sie die Probleme verdeutlichen.

Continuous Delivery ist sowohl Teil des agilen Rezepts als auch eine hervorragende Methode zum Aufdecken von Ineffizienzen. Um die Vorteile von Agile zu nutzen, musst du in allen Phasen des Lebenszyklus der Softwareentwicklung agil sein. Iterative Planung und Entwicklung zählen nicht viel, wenn deine User Storys und Bugfixes wochenlang in einem Repository versauern, bevor Stakeholder und Kunden sie jemals zu Gesicht bekommen.

Du bist nur so #agil wie deine Fähigkeit, häufig und ohne Probleme auszuliefern.

Agile bedeutet im Wesentlichen "Überprüfung und Anpassung". Du wirst dein Build- und Deployment-System wahrscheinlich nicht unter einem Mikroskop untersuchen müssen, um zu beurteilen, ob es die Agilität deines Teams behindert oder ihm hilft. Die Tatsache, dass du diesen Artikel liest, ist ein gutes Zeichen dafür, dass du dein System bereits als "hemmend" kategorisiert hast. Jetzt ist es an der Zeit, es anzupassen.

Leben mit ständiger Frustration

Software befindet sich häufig in einem Zustand, den ich als "kontinuierliche Frustration" bezeichne. Es ist das Fehlen jeglicher Continuous-Integration- oder Continuous-Delivery-Verfahren. Das fühlt sich folgendermaßen an:

  • Du führst einen Commit in den Haupt-Branch durch und wartest besorgt darauf, dass dich jemand für irgendetwas beschuldigt.
  • Deine Hauptcodezeile ist instabil.
  • Bugs verstecken sich in einem Gewirr von vielen, vielen Codeänderungen, und dir graut vor der Fehlersuche (geschweige denn vor der Behebung), da so viel Zeit vergangen ist, seit du an diesem Codebereich gearbeitet hast.
  • Wenn Tester eine Funktion testen möchten, müssen sie ständig die Entwickler nerven, um den aktuellen Status zu erfahren und einen funktionierenden Build zu finden.
  • Releases erfordern einen Code Freeze. Jemand wird zu einem künstlichen Engpass für Codeänderungen, um den Release zu stabilisieren. In der Zwischenzeit hört niemand wirklich auf zu arbeiten. Es werden nur keine Codeänderungen vorgenommen, was bedeutet, dass ins Repository jede Menge ungeprüfter Code wie ungeklärtes Abwasser einströmt, sobald der Freeze aufgehoben wird.

Fehler | Atlassian CI/CD

Sollte dir dies nur allzu bekannt vorkommen: Es gibt Grund zur Hoffnung.

Denke darüber nach, wie "Überprüfen und Anpassen" deinen Planungsprozess verbessert hat, und übertrage dies auf die Entwicklungs- und Bereitstellungsprozesse. Stell dir vor, du könntest bei jedem Commit, den du durchgeführt hast, die Probleme erkennen. Stell dir dann vor, du könntest Probleme bereits auf deiner lokalen Workstation erkennen, noch bevor du den Commit durchgeführt hast. Dies ist im Wesentlichen der Grund, warum Agile Continuous Delivery benötigt: Entwickler brauchen schnelles Feedback.

Das Gute am Weg zu Continuous Delivery ist, dass es bei dir beginnt. Du musst es niemandem schmackhaft machen oder dein Team davon überzeugen, dass ihr mehr wie Etsy sein solltet. Es gibt eigentlich auch keine Technologie, die so einzigartig ist, dass die grundlegenden Prinzipien, Verfahren und Tools der Continuous Delivery nicht angewendet werden können. Du kannst dir mit einigen einfachen Maßnahmen dein Leben leichter machen.

Beginne mit einem Skript und einem Server

In der Vergangenheit gab es nur Make, aber viele Entwickler hatten Probleme mit Leerzeichen-Bugs. Später hat Ant Leerzeichen durch eckige Klammern ersetzt. Heute kannst du diese früheren Generationen hinter dir lassen. Sicher wirst du immer noch viele Open-Source-Projekte sehen, die Maven oder sogar Ant verwenden. Dies ist einfach auf alte Gewohnheiten zurückzuführen. Du kannst jedoch XML-basierte Build-Sprachen als Plan B verwenden.

Die neueste Generation von Build-Sprachen ist viel einfacher zu erlernen und zu verwenden. In den meisten Fällen kannst du eine Build-Sprache verwenden, die in der gleichen Sprache geschrieben ist, in der du deine Anwendung erstellst, was das Ganze für dich selbst (und dein Team) erleichtert.

Tabelle der Code-Sprache und des entsprechenden empfohlenen Tools | Atlassian CI/CD

"Continuous" bedeutet bei Continuous Delivery, Feedback zu jedem Commit zu erhalten, weshalb Build-Server automatisch dein Repository abhören und einen Build auslösen, wenn sich etwas ändert. "Continuous" bedeutet auch, den Build zu reparieren, wenn er beschädigt ist. Als Entwickler profitierst du von der Isolation der Änderungen. Der beste Weg, um zu verhindern, dass Fehlerbehebungen kompliziert und unhandlich werden, besteht in der Vermeidung einer Anhäufung. Build-Server wie Bamboo sind einfach zu installieren. Zunächst besteht ihr Zweck einfach darin, dein Build-Skript in einer sauberen Umgebung auszuführen. Im Prinzip hilft dir dein Build-Server in erster Linie dabei, Probleme in deinem Build-Skript zu erkennen.

Beginne mit der automatischen Erkennung von Problemen

Du kannst dir wohl vorstellen, dass dein Build-Server viel mehr kann als nur Probleme in deinem Build-Skript zu erkennen. Er verfügt über einfache Funktionen wie das Einschalten von Compiler-Warnungen (für einige Sprachen) und kompliziertere Funktionen, für die sich jeder Agile Coach einsetzen wird, wie z. B. automatisierte Tests. Das liegt daran, dass rein manuelle Tests zu einem Engpass für Continuous Delivery werden. Wenn du gerade erst mit automatisierten Tests beginnst, solltest du die Ebene suchen (Unit, Integration, Akzeptanz oder Benutzeroberfläche), die das schnellste Feedback liefert.

Beenden wir die Kontroverse: Automatisierte Tests sind KEINE Bedrohung für manuelle Tester.

In der Tat sind menschliche Tester wegweisend bei der Entscheidung, was (und was nicht) automatisiert werden soll. Eine intelligente Automatisierungsstrategie hängt von der Frage ab: "Die Erkennung welcher Arten von Problemen wäre am wertvollsten für uns?" Um auf diese Frage eine Antwort zu finden, benötigst du erfahrene Spezialisten für Softwarequalität.

Die Saat der Continuous Delivery

Jeder kann damit anfangen. Aber wenn du alleine bist, wird es niemand als Continuous Delivery erkennen. Der nächste Schritt besteht darin, diese Bausteine in dein Team zu bringen.

Lasse dich von Büchern und Artikeln über Continuous Integration (CI) und agile Tests inspirieren. Später wirst du immer mehr Gründe finden, warum es nützlich ist, jederzeit bereit für ein Deployment zu sein. Dann kannst du dich von Continuous Delivery und Continuous Deployment inspirieren lassen.

Der Ausgangspunkt für alle ist ziemlich ähnlich, aber der Endzustand wird einzigartig für dein Produkt und dein Unternehmen sein.