Sichere Bereitstellungsmethoden

Manchmal erfüllt eine Veröffentlichung nicht die Erwartungen. Trotz der Verwendung bewährter Methoden und der Übergabe aller Qualitätstore gibt es gelegentlich Probleme, die zu einer Produktionsbereitstellung führen, die unvorhergesehene Probleme für Benutzer verursacht. Um die Auswirkungen dieser Probleme zu minimieren und zu mindern, werden DevOps-Teams ermutigt, eine progressive Expositionsstrategie zu übernehmen, die die Exposition einer bestimmten Version mit ihrer bewährten Leistung ausgleicht. Da sich eine Version in der Produktion beweist, wird sie für Ebenen breiterer Zielgruppen verfügbar, bis jeder es verwendet. Teams können sichere Bereitstellungsmethoden verwenden, um die Qualität und Geschwindigkeit von Versionen in der Produktion zu maximieren.

Steuern der Exposition gegenüber Kunden

DevOps-Teams können verschiedene Methoden verwenden, um die Gefährdung von Updates für Kunden zu steuern. In der Vergangenheit war A/B-Tests eine beliebte Wahl für Teams, die sehen möchten, wie verschiedene Versionen eines Diensts oder einer Benutzeroberfläche gegen Zielziele ausgeführt werden. A/B-Tests sind auch relativ einfach zu verwenden, da die Änderungen in der Regel geringfügig sind und häufig nur unterschiedliche Versionen am Kundenrand eines Dienstes vergleichen.

Sichere Bereitstellung über Ebenen

Da Plattformen wachsen, muss der Infrastrukturmaßstab und die Zielgruppe ebenfalls wachsen. Dadurch entsteht eine Nachfrage nach einem Bereitstellungsmodell, das die Mit einer neuen Bereitstellung verbundenen Risiken mit den Vorteilen der von ihr versprochenen Updates in Einklang bringt. Die allgemeine Idee ist, dass eine bestimmte Version zuerst nur einer kleinen Gruppe von Benutzern mit der höchsten Risikotoleranz ausgesetzt werden sollte. Wenn die Version erwartungsgemäß funktioniert, kann sie für eine breitere Benutzergruppe verfügbar gemacht werden. Wenn keine Probleme auftreten, kann der Prozess durch breitere Benutzergruppen oder Ebenen fortgesetzt werden, bis jeder die neue Version verwendet. Mit modernen Fortlaufendbereitstellungsplattformen wie GitHub-Aktionen und Azure-Pipelines ist das Erstellen eines Bereitstellungsprozesses mit Ebenen für DevOps-Teams beliebiger Größe zugänglich.

Featureflags

Bestimmte Funktionen müssen manchmal als Teil einer Version bereitgestellt werden, jedoch nicht anfänglich für Benutzer verfügbar gemacht werden. In diesen Fällen stellen Featurekennzeichnungen eine Lösung bereit, bei der Funktionen über Konfigurationsänderungen basierend auf Umgebung, Ebene oder einer anderen spezifischen Bereitstellung aktiviert werden können.

Benutzer-Opt-In

Ähnlich wie Featurekennzeichnungen bietet die Benutzer-Opt-In eine Möglichkeit, die Belichtung zu begrenzen. In diesem Modell wird ein bestimmtes Feature in der Version aktiviert, aber nicht für einen Benutzer aktiviert, es sei denn, er möchte es ausdrücklich. Die Risikotoleranzentscheidung wird den Benutzern ausgelagert, damit sie entscheiden können, wie schnell sie bestimmte Updates einführen möchten.

Mehrere Methoden werden häufig gleichzeitig eingesetzt. Beispielsweise kann ein Team ein experimentelles Feature für einen sehr spezifischen Anwendungsfall haben. Da es riskant ist, stellen sie sie für interne Benutzer auf der ersten Ebene bereit, um es auszuprobieren. Obwohl sich die Features im Code befinden, muss jemand das Featurekennzeichnung für eine bestimmte Bereitstellung innerhalb der Ebene festlegen, damit das Feature über die Benutzeroberfläche verfügbar gemacht wird. Selbst dann kann das Featureflagge nur die Option für einen Benutzer verfügbar machen, sich für die Verwendung des neuen Features zu entscheiden. Jeder Benutzer, der sich nicht auf der Ebene, in dieser Bereitstellung befindet oder sich nicht angemeldet hat, wird nicht für das Feature verfügbar gemacht. Dies ist zwar ein ziemlich konverdientes Beispiel, dient aber dazu, die Flexibilität und Praktikabilität der progressiven Exposition zu veranschaulichen.

Häufige Probleme, denen Teams frühzeitig begegnen

Wenn Sich Teams zu einer agileren DevOps-Praxis bewegen, treten möglicherweise Probleme auf, die mit anderen in Einklang stehen, die sich von herkömmlichen monolithischen Lieferungen entfernt haben. Teams, die für die Bereitstellung einmal alle paar Monate verwendet werden, haben eine Denkweise, die puffert für die Stabilisierung. Sie gehen davon aus, dass jede Bereitstellung einen erheblichen Wandel in ihrem Dienst einführt und dass unvorhergesehene Probleme auftreten.

Nutzlasten sind zu groß

Dienste, die alle paar Monate bereitgestellt werden, werden in der Regel mit vielen Änderungen gefüllt. Dies erhöht die Wahrscheinlichkeit, dass sofort Probleme auftreten werden, und macht es auch schwierig, diese Probleme zu beheben, da es so viele neue Dinge gibt. Durch den Wechsel zu häufigeren Lieferungen werden die Unterschiede bei der Bereitstellung kleiner, wodurch gezieltere Tests und einfacheres Debuggen ermöglicht werden.

Keine Dienstisolation

Monolithische Systeme werden traditionell skaliert, indem sie die Hardware abgleichen, auf der sie bereitgestellt werden. Wenn jedoch etwas mit der Instanz schief geht, führt es zu Problemen für jeden. Eine einfache Lösung besteht darin, mehrere Instanzen hinzuzufügen, sodass Sie den Lastenausgleich von Benutzern ausführen können. Dies kann jedoch erhebliche Architekturaspekte erfordern, da viele ältere Systeme nicht für mehrere Instanzen erstellt werden. Darüber hinaus müssen erhebliche doppelte Ressourcen möglicherweise für Funktionen zugewiesen werden, die an anderer Stelle besser konsolidiert werden können.

Wenn neue Features hinzugefügt werden, untersuchen Sie, ob eine Microservices-Architektur Ihnen helfen kann, dank einer besseren Dienstisolation zu arbeiten und zu skalieren.

Manuelle Schritte führen zu Fehlern

Wenn ein Team nur ein paar Mal pro Jahr bereitgestellt wird, scheint die Automatisierung von Lieferungen möglicherweise nicht die Investition wert zu sein. Daher werden viele Bereitstellungsprozesse manuell verwaltet. Dies erfordert eine erhebliche Zeit und Mühe und ist anfällig für menschliche Fehler. Das einfache Automatisieren der am häufigsten verwendeten Build- und Bereitstellungsaufgaben kann einen langen Weg gehen, um verlorene Zeit und nicht erzwungene Fehler zu reduzieren.

Teams kann die Infrastruktur auch als Code nutzen, um eine bessere Kontrolle über Bereitstellungsumgebungen zu erhalten. Dadurch wird die Notwendigkeit für Anforderungen an das Betriebsteam entfernt, manuelle Änderungen vorzunehmen, wenn neue Features oder Abhängigkeiten in verschiedenen Bereitstellungsumgebungen eingeführt werden.

Nur Ops können Bereitstellungen ausführen

Einige Organisationen verfügen über Richtlinien, die erfordern, dass alle Bereitstellungen von den Betriebsmitarbeitern initiiert und verwaltet werden. Obwohl es in der Vergangenheit gute Gründe gegeben hat, hat ein Agile DevOps-Prozess erheblich Vorteile, wenn das Entwicklungsteam Bereitstellungen initiieren und steuern kann. Moderne Plattformen für die kontinuierliche Bereitstellung bieten eine präzise Kontrolle darüber, wer welche Bereitstellungen initiieren kann und wer auf Statusprotokolle und andere Diagnoseinformationen zugreifen kann, um sicherzustellen, dass die richtigen Personen so schnell wie möglich über die richtigen Informationen verfügen.

Fehlerhafte Bereitstellungen werden fortgesetzt und können nicht zurückgesetzt werden

Manchmal ist eine Bereitstellung falsch, und Teams müssen sie beheben. Wenn Prozesse jedoch manuell sind und der Zugriff auf Informationen langsam und eingeschränkt ist, kann es schwierig sein, ein Rollback auf eine vorherige Arbeitsbereitstellung durchzuführen. Glücklicherweise gibt es verschiedene Tools und Methoden zum Verringern des Risikos fehlgeschlagener Bereitstellungen.

Kernprinzipien

Teams, die sichere Bereitstellungsmethoden einführen möchten, sollten einige Kernprinzipien festlegen, um den Aufwand zu unterstützen.

Konsistent sein

Die gleichen Tools, die für die Bereitstellung in der Produktion verwendet werden, sollten in Entwicklungs- und Testumgebungen verwendet werden. Wenn Probleme auftreten, z. B. die, die häufig aus neuen Versionen von Abhängigkeiten oder Tools entstehen, sollten sie gut abgefangen werden, bevor der Code in der Produktion veröffentlicht wird.

Pflege von Qualitätssignalen

Zu viele Teams fallen in die gemeinsame Falle, sich nicht wirklich um Qualitätssignale zu kümmern. Im Laufe der Zeit stellen sie möglicherweise fest, dass sie Tests schreiben oder Qualitätsaufgaben übernehmen, um einfach eine gelbe Warnung in eine grüne Genehmigung zu ändern. Qualitätssignale sind wirklich wichtig, da sie den Impuls eines Projekts darstellen. Die Zur Genehmigung von Bereitstellungen verwendeten Qualitätssignale sollten täglich ständig nachverfolgt werden.

Bereitstellungen sollten keine Ausfallzeiten erfordern

Obwohl es für jeden Dienst nicht wichtig ist, immer verfügbar zu sein, sollten Teams ihre DevOps-Bereitstellungs- und Betriebsphasen mit der Denkweise angehen, dass sie neue Versionen bereitstellen können und sollten, ohne sie jederzeit herunternehmen zu müssen. Moderne Infrastruktur- und Pipelinetools sind jetzt fortgeschritten, wo es für praktisch jedes Team machbar ist, 100% Betriebszeit zu erreichen.

Bereitstellungen sollten während der Arbeitszeit erfolgen

Wenn ein Team mit der Denkweise arbeitet, dass Bereitstellungen keine Ausfallzeiten erfordern, spielt es keine Rolle, wenn eine Bereitstellung verschoben wird. Darüber hinaus wird es vorteilhaft, Bereitstellungen während der Arbeitszeiten zu pushen, insbesondere früh am Tag und anfang der Woche. Wenn etwas schief geht, sollte es früh genug nachverfolgt werden, um den Strahlradius zu steuern. Darüber hinaus arbeiten alle bereits und konzentrieren sich darauf, Probleme zu beheben.

Tierbasierte Bereitstellung

Teams mit ausgereiften DevOps-Veröffentlichungspraktiken sind in der Lage, eine tierbasierte Bereitstellung zu übernehmen. In diesem Modell werden neue Features zuerst für Kunden eingeführt, die bereit sind, das größte Risiko zu akzeptieren. Da sich die Bereitstellung bewährt hat, erweitert sich die Zielgruppe, um weitere Benutzer einzubeziehen, bis jeder die Bereitstellung verwendet.

Beispielebenenmodell

Ein typisches Bereitstellungsmodell der Ebene ist so konzipiert, dass Probleme so früh wie möglich durch die sorgfältige Segmentierung von Benutzern und Infrastruktur gefunden werden. Das folgende Beispiel zeigt, wie Ebenen von einem hauptteam bei Microsoft verwendet werden.

Backzeit zulassen

Der Begriff Backzeit bezieht sich auf die Zeitspanne, in der eine Bereitstellung ausgeführt werden darf, bevor sie auf die nächste Ebene erweitert wird. Einige Probleme können Stunden oder länger dauern, um Symptome zu zeigen, daher sollte die Freigabe für eine angemessene Zeitspanne verwendet werden, bevor sie als bereit eingestuft wird.

Im Allgemeinen sollte ein 24-Stunden-Tag genug Zeit für die meisten Szenarien sein, um latente Fehler verfügbar zu machen. Dieser Zeitraum sollte jedoch einen Zeitraum der Spitzennutzung umfassen, der einen ganzen Arbeitstag erfordert, für Dienste, die während der Geschäftszeiten höchstwertig sind.

Beschleunigte Hotfixes

Ein Live-Site-Vorfall (LSI ) tritt auf, wenn ein Fehler schwerwiegende Auswirkungen auf die Produktion hat. LSIs erfordern die Erstellung eines Hotfixes, bei dem es sich um ein Out-of-Band-Update handelt, das auf ein Problem mit hoher Priorität ausgerichtet ist.

Wenn ein Fehler Sev 0 ist, der schwerste Fehlertyp, kann der Hotfix direkt in der betroffenen Skalierungseinheit so schnell wie verantwortungsvoll bereitgestellt werden. Obwohl es wichtig ist, dass der Fix nicht schlimmer macht, werden Fehler dieses Schweregrads als störend betrachtet, damit sie sofort behoben werden müssen.

Fehler mit der Bewertung Sev 1 müssen über Stufe 0 bereitgestellt werden, können aber dann in den betroffenen Skalierungseinheiten bereitgestellt werden, sobald sie genehmigt wurden.

Hotfixes für Fehler mit geringerem Schweregrad müssen wie geplant über alle Ebenen bereitgestellt werden.

Wichtige Erkenntnisse

Jedes Team möchte Updates schnell und mit höchster Qualität bereitstellen. Mit den richtigen Praktiken kann die Lieferung ein produktiver und schmerzloser Teil des DevOps-Zyklus sein.

• Stellen Sie häufig bereit.
• Bleiben Sie im Sprint grün.
• Verwenden Sie konsistente Bereitstellungstools in Entwicklung, Test und Produktion.
• Verwenden Sie eine fortlaufende Übermittlungsplattform, die Automatisierung und Autorisierung zulässt.
• Folgen Sie sicheren Bereitstellungsmethoden.

Nächste Schritte

Erfahren Sie, wie Featurekennzeichnungen dazu beitragen, die Belichtung neuer Features für Benutzer zu steuern.