Verwenden von Bereitstellungsringen mit Erweiterungsversionen

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Mit Bereitstellungsringen können Sie änderungen an Ihrer Erweiterung in der Produktion schrittweise bereitstellen und überprüfen, während sie die Auswirkungen auf Ihre Benutzer einschränken.

Es wird nicht empfohlen, alle Produktionsumgebungen gleichzeitig bereitzustellen, wodurch alle Benutzer den Änderungen zur Verfügung stehen. Ein schrittweises Rollout stellt Benutzern die Änderungen im Laufe der Zeit zur Verfügung, indem die Änderungen in der Produktion mit weniger Benutzern überprüft werden.

In der folgenden Tabelle sind die Unterschiede für betroffene Bereiche aufgeführt, wenn Sie Ringe und keine Ringe verwenden.

Ohne Ringe Betroffener Bereich Mit Ringen
Manuelle und fehleranfällige Fehler Entwickeln Automatisierte und konsistente
Manuelle und fehleranfällige Fehler Release Automatisierte und konsistente
Stunden Zeit zum Erstellen (TTB) Sekunden
Tage Zeit zur Veröffentlichung (TTR) Minuten
Anruf vom Benutzer Problemerkennung Proactive
Tage bis Wochen Problemauflösung Minuten bis Tage

Weitere Informationen finden Sie unter Konfigurieren Ihrer Releasepipelinen für sichere Bereitstellungen.

Voraussetzungen

  • Überprüfen Sie CI/CD Pipelines und Genehmigungen für detaillierte Dokumentationen von Pipelines und den Genehmigungsfeatures für Versionen.

Zuweisen von Benutzertypen

Bestimmen Sie, welche Benutzer für jeden Benutzertyp am besten geeignet sind. Kommunizieren Sie die Möglichkeit, Feedback und die Risikostufen auf jeder Ebene bereitzustellen, da es wichtig ist, Erwartungen festzulegen und den Erfolg zu gewährleisten. Im folgenden Beispiel werden Benutzer in drei Gruppen in der Produktion unterteilt:

  • Canaries: Freiwillig testen Sie Features, sobald sie verfügbar sind.
  • Frühe Adopter: freiwillig Vorschauversionen, die als besser als die Kanarischen Bits angesehen wurden.
  • Benutzer: Nutzen Sie die Produkte, nachdem sie über Canaries und frühe Adopter übergeben haben.

User Rings

Zuordnen der Topologie

Ordnen Sie die Topologie Ihrer Erweiterung dem ringierten Bereitstellungsmodell zu, um die Auswirkungen der Änderung auf Ihre Benutzer zu beschränken und Wert zu liefern. Für unsere Open-Source-Community-Erweiterungen verwenden wir hauptsächlich ringbasierte Bereitstellungen, um eine neue Version für Canary, Early Adopters und Benutzer schrittweise verfügbar zu machen.

Auf Anwendungsebene ist die Zusammensetzung von Azure DevOps Erweiterungen einfach zu verdauen, zu skalieren und unabhängig bereitzustellen.

Jede Erweiterung führt die folgenden Aufgaben aus:

  • Verfügt über eine der weiteren Web- und Skriptdateien
  • Schnittstellen mit Core-Client
  • Schnittstellen mit REST-Client- und REST-APIs
  • Beibehalten des Status im Cache oder widerstandsfähigen Speicher

Progressive exposure of the application layer

Auf Infrastrukturebene werden die Erweiterungen im Marketplace veröffentlicht. Nachdem Sie die Erweiterung in Ihrer Organisation installiert haben, wird sie vom Azure DevOps-Dienstportal gehostet, wobei der Zustand auf Azure-Speicher oder den Erweiterungsdatenspeicher beibehalten wird.

Progressive exposure of the infrastructure layer

Die Erweiterungstopologie eignet sich perfekt für das Ringbereitstellungsmodell und zum Veröffentlichen der Erweiterung für jeden Bereitstellungsring:

  • Eine private Entwicklungsversion für den Kanarischen Ring
  • Eine private Vorschauversion für den frühen Adopterring
  • Eine öffentliche Produktionsversion für den Benutzerring

Tipp

Veröffentlichen Sie Ihre Erweiterung als privat, um die Exposition für eingeladene Benutzer zu steuern.

Verschieben von Änderungen durch Bereitstellungsringe

Im folgenden Beispiel werden Änderungen durch Bereitstellungsringe verschoben.

Verwenden Sie die Azure DevOps Entwicklertools-Buildaufgabenerweiterung, um Erweiterungen im Marketplace zu verpacken und zu veröffentlichen.

Extension rings

  1. Ein Entwickler aus dem Countdown Widget-Erweiterungsprojekt setzt eine Änderung an das GitHub Repository fest.
  2. Der Commit löst einen fortlaufenden Integrationsbuild aus.
  3. Der neue Build löst einen fortlaufenden Bereitstellungsauslöser aus, der die Canaries-Umgebungsbereitstellung automatisch startet.
  4. Die Canaries-Bereitstellung veröffentlicht eine private Erweiterung für den Marketplace und teilt sie mit vordefinierten Organisationen. Nur die Canaries sind von der Änderung betroffen.
  5. Die Canaries-Bereitstellung löst die Early Adopter-Umgebungsbereitstellung aus. Ein Vorbereitstellungsgenehmigungsgate erfordert eine der autorisierten Benutzer, die Version zu genehmigen. Pre-deployment approval for Early Adopter environment
  6. Die Early Adopter-Bereitstellung veröffentlicht eine private Erweiterung auf dem Marketplace und teilt sie mit vordefinierten Organisationen. Sowohl canaries als auch Early Adopter sind von der Änderung betroffen.
  7. Die Early Adopter-Bereitstellung löst die Benutzerumgebungsbereitstellung aus. Ein strikteres Vorbereitstellungsgenehmigungsgate erfordert, dass alle autorisierten Benutzer die Version genehmigen. Pre-deployment approval for User environment
  8. Die Bereitstellung der Benutzer veröffentlicht eine öffentliche Erweiterung auf dem Marketplace. In dieser Phase ist jeder, der die Erweiterung in ihrer Organisation installiert hat, von der Änderung betroffen.
  9. Es ist wichtig zu erkennen, dass der Effekt erhöht wird, wenn sich Ihre Änderung durch die Ringe bewegt. Wenn Sie die Änderung an den Canaries und den Early Adopters anzeigen, erhalten Sie zwei Möglichkeiten, die Änderung und den Hotfix kritische Fehler zu überprüfen, bevor Sie die Produktion freigeben.

Überwachen von Problemen

Überwachung und Warnungen können Ihnen helfen, Probleme zu erkennen und zu verringern. Ermitteln Sie, welche Art von Daten wichtig ist, z. B. Infrastrukturprobleme, Verstöße und Featurenutzung. Konzentrieren Sie sich auf aktionsfähige Warnungen, um Benutzer zu vermeiden, die sie ignorieren und probleme mit hoher Priorität fehlen.

Tipp

Beginnen Sie mit hohen Ansichten Ihrer Daten, visuelle Dashboards, die Sie nach Bedarf von einem Fern- und Drilldown ansehen können. Führen Sie regelmäßige Haushaltung ihrer Ansichten aus, und entfernen Sie alle Geräusche. Ein visuelles Dashboard erzählt eine bessere Geschichte als viele Benachrichtigungs-E-Mails, die häufig nach E-Mail-Regeln gefiltert und vergessen werden.

Verwenden Sie Team Project Integrität und andere Erweiterungen, um einen Überblick über Ihre Pipelines, Lead- und Zykluszeiten zu erstellen und andere Informationen zu sammeln. Im Beispieldashboard ist es offensichtlich, dass es 34 erfolgreiche Builds gibt, 21 erfolgreiche Versionen, 1 fehlgeschlagene Version und 2 Versionen in Bearbeitung.

High-level dashboard on Azure DevOps

Gibt es eine Abhängigkeit von Feature-Flags?

Nein. Manchmal benötigen Sie möglicherweise eine bestimmte Funktionalität, die als Teil einer Version bereitgestellt werden soll, aber nicht zunächst benutzern verfügbar gemacht wird. Feature-Flags bieten Ihnen eine fein zugeschnittene Kontrolle über Features, die in Ihrer Änderung enthalten sind. Wenn Sie beispielsweise nicht vollständig über ein Feature vertraut sind, können Sie Feature-Flags verwenden, um das Feature in einem oder allen Bereitstellungsringen auszublenden . Sie können alle Features im Canärring aktivieren und eine Teilmenge für die frühen Adopter und Produktionsbenutzer optimieren, wie in der folgenden Abbildung dargestellt.

Feature flags

Weitere Informationen finden Sie unter "Progressive Experimentierung mit Feature-Flags".

Häufig gestellte Fragen

F: Wie wissen Sie, dass eine Änderung im nächsten Ring bereitgestellt werden kann?

A: Sie sollten eine konsistente Checkliste für die Benutzer haben, die eine Version genehmigen.

F: Wie lange warten Sie, bevor Sie eine Änderung an den nächsten Ring verschieben?

Es gibt keine feste Dauer oder einen "Cool off"-Zeitraum. Es hängt davon ab, wie lange es dauert, bis Sie alle Versionsüberprüfungen erfolgreich abschließen.

F: Wie verwalten Sie einen Hotfix?

A: Das Ringbereitstellungsmodell ermöglicht Es Ihnen, einen Hotfix wie alle anderen Änderungen zu verarbeiten. Je schneller Sie ein Problem fangen, desto schneller können Sie einen Hotfix ohne Auswirkung auf nachgelagerte Ringe bereitstellen.

F: Wie arbeiten Sie mit Variablen zusammen, die freigegebene Releaseumgebungen umfassen?

A: Verweisen Sie auf Standard- und benutzerdefinierte Versionsvariablen.

F: Wie können Sie Geheime verwalten, die von der Pipeline verwendet werden?

A: Informationen zum Schützen von kryptografischen Schlüsseln und anderen geheimen Schlüsseln, die von Ihren Pipelines verwendet werden, finden Sie unter Azure Key Vault.