Verwenden von Bereitstellungsringen mit Erweiterungsversionen

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

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

Es wird nicht empfohlen, die Bereitstellung in allen Produktionsumgebungen gleichzeitig auszuführen, wodurch alle Benutzer den Änderungen zur Verfügung stehen. Ein graduelles Rollout macht Benutzer den Änderungen im Laufe der Zeit verfügbar und überprüft die Änderungen in der Produktion mit weniger Benutzern.

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

Ohne Ringe	Betroffene Bereiche	Mit Ringen
Manuell und fehleranfällig	Erstellen	Automatisiert und konsistent
Manuell und fehleranfällig	Freigabe	Automatisiert und konsistent
Stunden	Zeit zum Erstellen (TTB)	Sekunden
Tage	Zeit für die Veröffentlichung (TTR)	Minuten
Anruf vom Benutzer	Problemerkennung	Proactive
Tage bis Wochen	Problemlösung	Minuten bis Tage

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

Voraussetzungen

• Lesen Sie CI/CD-Pipelines und Genehmigungen, um detaillierte Dokumentationen von Pipelines und den Genehmigungsfeatures für Versionen zu erhalten.

Zuweisen von Benutzertypen

Ermitteln 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: Testfeatures freiwillig, sobald sie verfügbar sind.
• Early Adopters: freiwillige Vorschauversionen, die als verfeinerter betrachtet werden als die Canarybits.
• Benutzer: Verbrauchen Sie die Produkte, nachdem sie Die Canaries und Early Adopters durchlaufen haben.

Zuordnen der Topologie

Ordnen Sie die Topologie Ihrer Erweiterung dem ringierten Bereitstellungsmodell zu, um die Auswirkungen von Änderungen auf Ihre Benutzer zu begrenzen und Wert zu erzielen. Für unsere Open-Source-Communityerweiterungen verwenden wir hauptsächlich ringbasierte Bereitstellungen, um schrittweise eine neue Version für Canary, Early Adopters und Benutzer verfügbar zu machen.

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

Jede Erweiterung führt die folgenden Aufgaben aus:

• Verfügt über eine von mehreren Web- und Skriptdateien
• Schnittstellen mit Core-Client
• Schnittstellen mit REST-Client- und REST-APIs
• Behält den Status im Cache oder ausfallsicheren Speicher bei

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

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 Canaryring
• Eine private Vorschauversion für den Early Adopter-Ring
• Eine öffentliche Produktionsversion für den Benutzerring

Tipp

Veröffentlichen Sie Ihre Erweiterung als privat, um die Gefährdung von eingeladenen Benutzern zu steuern.

Verschieben von Änderungen durch Bereitstellungsringe

Sehen Sie sich den folgenden Beispielfluss des Verschiebens von Änderungen durch Bereitstellungsringe an.

Verwenden Sie die Azure DevOps Developer Tools Build Tasks-Erweiterung , um Erweiterungen auf dem Marketplace zu packen und zu veröffentlichen.

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 Bereitstellungstrigger 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 Genehmigungsgate für die Vorabbereitstellung erfordert, dass einer der autorisierten Benutzer die Freigabe genehmigt.
6. Die Early Adopter-Bereitstellung veröffentlicht eine private Erweiterung auf dem Marketplace und teilt sie mit vordefinierten Organisationen. Sowohl die Canaries als auch early Adopter sind von der Änderung betroffen.
7. Die Early Adopter-Bereitstellung löst die Bereitstellung der Benutzerumgebung aus. Ein strengeres Genehmigungsgate für die Vorabbereitstellung erfordert, dass alle autorisierten Benutzer die Freigabe genehmigen.
8. Die Benutzerbereitstellung 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 steigt, wenn Ihre Änderung durch die Ringe bewegt wird. Wenn Sie die Änderung an den Canaries und early Adopters verfügbar machen, haben Sie zwei Möglichkeiten, die Änderung zu überprüfen und wichtige Fehler vor der Veröffentlichung in der Produktion zu überprüfen.

Überwachen von Problemen

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

Tipp

Beginnen Sie mit allgemeinen Ansichten Ihrer Daten, visuellen Dashboards, die Sie nach Bedarf aus einem Fern- und Drilldown ansehen können. Führen Sie regelmäßige Haushaltung Ihrer Ansichten durch 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 Health und andere Erweiterungen, um einen Überblick über Ihre Pipelines, Lead- und Zykluszeiten zu erstellen und andere Informationen zu sammeln. Im Beispieldashboard ist klar, dass es 34 erfolgreiche Builds, 21 erfolgreiche Versionen, 1 fehlgeschlagene Veröffentlichungen und 2 laufende Versionen gibt.

Gibt es eine Abhängigkeit von Featurekennzeichnungen?

Nein Manchmal benötigen Sie möglicherweise eine bestimmte Funktionalität, die als Teil einer Version bereitgestellt werden muss, aber nicht anfänglich für Benutzer verfügbar gemacht wird. Featurekennzeichnungen bieten Ihnen eine differenzierte Kontrolle über Features, die in Ihrer Änderung enthalten sind. Wenn Sie z. B. über ein Feature nicht vollständig sicher sind, können Sie featurekennzeichnungen verwenden, um das Feature in einem oder allen Bereitstellungsringen auszublenden . Sie können alle Features im Canaries-Ring aktivieren und eine Teilmenge für die Early Adopters und Produktionsbenutzer optimieren, wie in der folgenden Abbildung dargestellt.

Weitere Informationen finden Sie unter "Progressives Experimentieren mit Featurekennzeichnungen".

Häufig gestellte Fragen

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

A: Sie sollten über eine konsistente Checkliste für die Benutzer verfügen, die eine Freigabe genehmigen.

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

Es gibt keine feste Dauer oder "Abkühlzeit". Es hängt davon ab, wie lange es dauert, bis Sie alle Releaseüberprüfungen erfolgreich abschließen können.

F: Wie verwalten Sie einen Hotfix?

A: Mit dem Ringbereitstellungsmodell können Sie einen Hotfix wie jede andere Änderung verarbeiten. Je früher Sie ein Problem abfangen, desto früher können Sie einen Hotfix ohne Auswirkung auf downstream-Ringe bereitstellen.

F: Wie behandeln Sie Variablen, die freigegebene Releaseumgebungen umfassen?

A: Verweisen Sie auf Standard- und benutzerdefinierte Releasevariablen.

F: Wie können Sie geheime Schlüssel verwalten, die von der Pipeline verwendet werden?

A: Informationen zum Schutz kryptografischer Schlüssel und anderer geheimer Schlüssel, die von Ihren Pipelines verwendet werden, finden Sie unter Azure Key Vault.

Verwandte Artikel

• Sichere Bereitstellungsmethoden
• Progressives Experimentieren mit Featureflags
• Konfigurieren Sie Ihre Releasepipelines für sichere Bereitstellungen.