Einführen von sicheren Bereitstellungsmethoden
 Implementieren von Schutzschienen im Bereitstellungsprozess, um die Auswirkungen von Fehlern oder unerwarteten Bedingungen zu minimieren. |
|---|
Während des Entwicklungszyklus durchlaufen Workloadartefakte viele Änderungen während sie implementiert und getestet, und Fehler behoben werden.
Der Bereitstellungsprozess muss einem Standardbetriebsverfahren entsprechen. Jede Änderung muss mit der gleichen Genauigkeit bereitgestellt werden. Dieses Prinzip gilt gleichermaßen für Code, Konfiguration und alle zugehörigen Artefakte. Der Schlüssel besteht darin, sichere Praktiken so früh wie möglich anzuwenden, damit Ihre Produktion vorhersehbar ist. Auch wenn Fehler die Kunden erreichen, sollten Sie in der Lage sein, Wiederherstellungsänderungen so schnell wie möglich auszuführen.
Beispielszenario
Contoso Air hat eine Webanwendung entwickelt, mit der Kunden Flüge direkt über die App buchen können. Die App wird seit über einem Jahr in der Produktion ausgeführt.
Die App wird vollständig in Azure bereitgestellt und basiert auf Azure App Service, Azure Cosmos DB, Azure Functions, Azure Logic Apps und Azure Service Bus.
Codifizieren automatisierter Bereitstellungsstandards
Standardisieren Sie den Prozess, um Änderungen mithilfe automatisierter Bereitstellungsprozesse wie Pipelines bereitzustellen. Alle Umgebungen müssen Pipelines verwenden. Klassifizieren Sie Ressourcen und Versionen pro Umgebung, damit sie leicht nachverfolgbar und identifizierbar sind.
Konsistente Bereitstellungsmethoden reduzieren Probleme, die durch Prozessfehler und Varianz verursacht werden, und ermöglichen es Ihnen, sich auf die Arbeitsauslastung zu konzentrieren.
Standardisierung stellt sicher, dass die Bereitstellung sicher, zuverlässig und mit Wiederholbarkeit abgeschlossen wird.
Die Klassifizierung erleichtert das Anzeigen von Protokollen früherer Bereitstellungen und Problemen, die aufgetreten sind. Möglicherweise können Sie diese Informationen verwenden, um Rollback- und Roll-Forward-Vorgänge zu beschleunigen.
Herausforderung von Contoso
- Das Contoso Air Workload-Team verwendet automatisierte Build- und Bereitstellungspipelines. Bereitstellungen erfordern jedoch normalerweise einen manuellen Eingriff während des gesamten Vorgangs, um verschiedene Konfigurationseinstellungen zu ändern und zu überprüfen.
- Aufgrund des manuellen Eingriffs treten häufige Fehler in der Bereitstellung auf, wodurch jede Veröffentlichung zu einem stressigen und störenden Ereignis für das gesamte Team wird. Der manuelle Eingriff erschwert auch das Rollback, wenn eine Bereitstellung fehlschlägt.
Umsetzung und Ergebnisse
- Das Team weist Zeit zu, um die Konfigurationsänderungen als Teil der Bereitstellung zu automatisieren und die hinzugefügten Funktionen in die vorhandenen Bereitstellungspipelines zu integrieren.
- Die den einzelnen Umgebungen zugeordneten Konfigurationseinstellungen werden für die jeweiligen JSON-Dateien externalisiert, die zur weiteren Rückverfolgbarkeit in der Quellcodeverwaltung gespeichert werden. Einstellungen, die als geheime Schlüssel gelten, werden auch in geheimen Tresorspeichern gespeichert, die jeder Umgebung zugeordnet sind.
- Alle Änderungen werden jetzt während der Bereitstellung protokolliert und erreichen die vollständige Rückverfolgbarkeit zur Unterstützung von Problembehandlungsbemühungen und Überwachungen. Das Team fügt außerdem automatisierte Tests hinzu, um die Konfigurationsänderungen an der Pipeline zu überprüfen.
- Als Nächstes arbeitet das Team an der vollständigen Automatisierung von Rollbacks, um Prozesse weiter zu optimieren.
- Aufgrund der neuen Automatisierung sind Bereitstellungen zuverlässiger und vorhersehbarer, und auch die Arbeitsmoral ist gestiegen.
Häufig bereitstellen
Bereitstellen kleiner inkrementeller Updates in regelmäßigen Abständen.
Mit diesem Ansatz können Benutzergeschichten und Arbeitsaufgaben von einem Projektmanagement-Standpunkt aus verwaltbar bleiben und das Risiko großer Probleme verringern, wenn Bereitstellungen fehlschlagen.
Herausforderung von Contoso
- Die Bereitstellungsprozesse des Teams wurden in der Vergangenheit zu dem Zweck ausgeführt, um alle drei bis vier Monate große Veröffentlichungen durchzuführen. Diese Arbeitsweise erschwert es, die Version zu überprüfen. Das Team hatte auch Schwierigkeiten bei der Problembehandlung aufgrund vieler beweglicher Bausteine.
- Problematische Versionen, die Hotfixes während der Veröffentlichung erfordern oder die zurückgesetzt oder abgebrochen werden müssen, sind mehrmals aufgetreten.
- Releases sind sehr stressig und wurden als "alle Mann an Deck"-Situationen behandelt, was sich negativ auf die Arbeitsmoral ausgewirkt hat.
Umsetzung und Ergebnisse
- Nach der neuesten problematischen Veröffentlichung baten die Stakeholder das Team, einen besseren Ansatz für Bereitstellungen zu schaffen. Das Team hat beschlossen, ihre Praktiken zu ändern, um häufige, kleine Änderungen zu begünstigen. Sie beschränken den Umfang jeder Version auf eine oder (höchstens) einige verwandte Änderungen, die gründlich getestet werden während der Build in den unteren Umgebungen gefördert wird.
- Infolgedessen sind die Veröffentlichungen viel effizienter geworden, und die Qualität ist gestiegen. Die Veröffentlichungen sind einfacher zu überprüfen, und Probleme sind einfacher zu beheben.
- Das regelmäßige Auftreten vorhersagbarer Veröffentlichungen hat dazu beigetragen, das Vertrauen und die Moral des Teams wiederherzustellen. Die Benutzer profitieren ebenfalls. Mit höherer Veröffentlichungsqualität sehen sie weniger Unterbrechungen und erhalten viel früheren Zugriff auf neue Features.
Verwenden eines progressiven Veröffentlichungsansatzes
Schrittweises sorgfältiges Rollout von Updates. Verwenden Sie Bereitstellungsmodelle, mit denen Sie die Kontrolle erhalten, die Anzahl der Instanzen und Kunden schrittweise zu erhöhen, bis das Update von allen sicher übernommen wird.
Testen Sie jedes Update auf kontrollierte Weise, damit Probleme frühzeitig in der Produktion behoben werden. Vermeiden Sie das Rollout eines fehlerhaften Updates, das sich auf Ihre gesamte Kundenbasis auswirkt.
Testen Sie, ob das Update rückwärts- und vorwärtskompatibel ist.
Herausforderung von Contoso
- Das Team sieht große Vorteile beim Wechseln des Ansatzes, um kleinere Versionen zu erstellen. Sie widmen jetzt Veröffentlichungen weniger Zeit und fühlen sich motiviert so fortzufahren, und weiter zusätzliche operative Exzellenzverbesserungen vorzunehmen.
- Während sie mit neuen Features experimentieren, wurden einige der Änderungen nicht gut von Benutzern empfangen oder haben aufgrund der steilen Lernkurve, die sie mitbringen, eine Zunahme der Supportanrufe verursacht.
- Sie fragen sich, wie sie die Innovation ihrer Anwendungen fortsetzen können, um die Produktivität ihrer Benutzer*innen zu maximieren, und gleichzeitig die Auswirkungen der Veröffentlichung von Features zu minimieren, die möglicherweise nicht so beliebt oder einfach zu bedienen sind.
Umsetzung und Ergebnisse
- Sie haben beschlossen, ein Featureveröffentlichungsmodell zu implementieren, das Benutzer*innen neue Features inkrementell mit Featurekennzeichnungen verfügbar macht.
- Während der Planungsphase für neue Features wird ein Kriterium definiert, um auszuwählen, für welche Benutzer*innen zuerst das Feature verfügbar gemacht wird. Eine kleine Gruppe von Benutzer*innen wird ausgewählt, um zuerst das neue Feature zu erhalten. Je nach Benutzerfeedback wird das Feature aufeinanderfolgenden größeren Gruppen bereitgestellt, bis die gesamte Benutzerpopulation die neue Version ausführt. Während immer mehr Benutzer die neuen Features kennenlernen, dokumentiert das Supportteam das Ergebnis der Supportfälle, die intern geteilt werden, und häufen evtl. die extern am häufig gestelltesten Fragen an.