Die Kunst, sich an das Continuous-Deployment-Modell zu halten, besteht darin, Features in sehr dünne vertikale Slices zu zerlegen, die in einen kleinen Release-Zyklus passen.
Online-Giganten wie Amazon, Facebook und Google haben ein Modell der kontinuierlichen Entwicklung und Bereitstellung übernommen. Diese Unternehmen sind in der Lage, ihre Produkte, vor allem Online-Websites, durch kontinuierliche Weiterentwicklung kontinuierlich zu verbessern. Facebook kann seine Website, die von mehr als 1 Milliarde Menschen genutzt wird, zweimal täglich aktualisieren.
Diese Welt des frühzeitigen und oftmaligen Versands ist herkömmlicher Unternehmenssoftware fremd, die hinsichtlich Planung und Festlegung eines Release-Termins noch einen mehrjährigen Rhythmus einhält. Bei Qumulo sahen wir dies als Chance. Wir wollten Software der Enterprise-Klasse bereitstellen und sie mit der Geschwindigkeit von Online-Unternehmen bereitstellen.
Dabei wollten wir ein zuverlässiges Dateisystem der Enterprise-Klasse die alle zwei Wochen veröffentlicht wird. Die Gründe dafür lagen auf der Hand: Wir wollten unseren Kunden kontinuierlich einen Mehrwert in Form von neuen Features bieten. Außerdem wollten wir uns schnell an Kunden- und Marktbedürfnisse anpassen, auf die wir in Wochen statt in Jahren reagieren können. Und schließlich ermöglichte uns dieses Modell der kontinuierlichen Bereitstellung eine sehr schnelle Markteinführung unseres Produkts.
Die Veröffentlichung von Software allein ist oft von geringem Wert, es sei denn, Kunden verwenden und implementieren sie. Online-Unternehmen haben die vollständige Kontrolle darüber, wie (und wann) sie ihre Infrastruktur aktualisieren, sowohl die Hardware als auch die Software. Die meisten Softwareunternehmen haben diesen Luxus nicht. Wenn Sie wie wir sind, verlassen Sie sich darauf, dass Ihre Kunden ihre Infrastruktur mit den neueste Software. Daher ist eine wichtige Kennzahl, die wir verfolgen, das Flottenalter, das die Aktualität der von unseren Kunden verwendeten Software-Releases misst.
In den letzten fünf Jahren haben wir gesehen, dass 80 % unserer Kunden einen Build betreiben, der etwa einen Monat alt ist. Die Einhaltung eines Modells der kontinuierlichen Bereitstellung ist leichter gesagt als getan, insbesondere bei Unternehmenssoftware, die vor Ort bereitgestellt wird. Wir haben viele Lehren aus diesem Modell gezogen, die im Folgenden zusammengefasst werden.
Testen ist der Schlüssel
Es versteht sich von selbst, dass die Fähigkeit zur kontinuierlichen Veröffentlichung von Software von der Qualität abhängt. Unser Produkt wird verwendet in geschäftskritische Anwendungen ohne Raum für Fehler. Daher testen wir häufig und auf allen Ebenen des Produkts.
Jeder neue Code wird zunächst einem „Sniff-Test“ unterzogen, der aus Tausenden von Low-Level-Tests besteht, um seine Qualität zu validieren. Der neue Code wird abgelehnt, wenn ein einzelner Test fehlschlägt. Sobald der Code akzeptiert und in unser Revisionskontrollsystem eingeführt wurde, wird er kontinuierlich in unserem Build-System bereitgestellt und validiert. Auch hier können alle Fehler in dieser Phase sofort untersucht und behoben werden.
Dieses Modell eines kontinuierlichen Build-Systems — gekoppelt mit Testen auf allen Ebenen des Produkts — ermöglicht es uns, diese Version der Software jederzeit zu versenden. Wir müssen weder Zeit noch Energie aufwenden, um unseren Release Candidate lieferfähig zu machen; alle Builds sind standardmäßig auslieferbar. Wir sind auch große Fans von „Hundefutter“ unseres eigenen Produkts: Qumulo ist Qumulo's Kunde Nr. 1. Wir betreiben jede Infrastruktur auf Qumulo und aktualisieren auf den neuesten Build, bevor es unsere Kunden tun.
Wenn Sie Ihre Kunden bitten, ihre Infrastruktur alle zwei Wochen zu aktualisieren, sollte der Prozess schmerz- und fehlerfrei ablaufen. Unser Upgrade-Prozess ist unglaublich einfach und dauert ein bis zwei Minuten.
Denke inkrementell
Es ist davon auszugehen, dass die meisten Funktionen nicht in einen zweiwöchigen Release-Zyklus passen. Dies gilt insbesondere für komplexe Unternehmensfunktionen, die viele Monate in Anspruch nehmen. Die Kunst, sich an das Continuous-Deployment-Modell zu halten, besteht darin, Features in sehr dünne vertikale Slices zu zerlegen, die in einen kleinen Release-Zyklus passen. Das Zerlegen von Features in dünne vertikale Slices ermöglicht uns eine frühzeitige und häufige Auslieferung, auch wenn das Feature noch lange nicht vollständig ist. Dieses Modell zum Erstellen dünner vertikaler Schichten hilft Ihren Kunden, die Funktionen Ihres Produkts in einem sehr frühen Stadium zu nutzen und mit ihnen zu interagieren, was zu unschätzbarem Feedback beiträgt. Es sollte auch Ihre Markteinführungszeit verkürzen. Sie werden überrascht sein, wie viele Kunden Ihre Funktion viel früher nutzen werden, als Sie sie für „vollständig“ halten.
Planen Sie nicht zu viel
Einer der Hauptvorteile dieses Modells ist die Anpassungsfähigkeit an Kunden- und Marktbedürfnisse. Wir können auf diese Bedürfnisse in wenigen Monaten statt in Jahren reagieren. Dies erfordert jedoch, dass wir in unserem Planungsprozess anpassungsfähig sind. Daher ist es wichtig, über einen Zeitraum von sechs Monaten hinaus nicht viel zu planen, welche Funktionen Sie erstellen. Überprüfen Sie Ihre Pläne auch ständig, um sicherzustellen, dass Sie an den wichtigsten Funktionen arbeiten, die bereitgestellt werden sollen was Kunden wollen.
Dieser Artikel erschien ursprünglich in Forbes als Teil der Forbes Technology Council-Reihe.
Mehr erfahren
Nutzungsrichtlinien für Qumulo-Software
5 Schritte zu einer erfolgreichen Cloud-Migration
Von Mom-and-Pop bis hin zu globaler Reichweite: 4-facher Speicherschub liefert
Die Kunst der Einfachheit – Kundenerfolg mit vereinfachten Dateidatenlösungen steigern
Kontakt
Machen Sie eine Probefahrt. Demon Sie Qumulo in unseren neuen interaktiven Hands-On Labs oder fordern Sie eine kostenlose Testversion an.
Abonnieren Sie den Qumulo-Blog für Kundengeschichten, technische Einblicke, Branchentrends und Produktneuigkeiten.
