Zum Hauptinhalt springen
Die Migration eines Enterprise-Kontos von der klassischen Umgebungseinrichtung zur deklarativen Konfiguration ist eine weitreichende Änderung. Auf der Seite „Rollout“ können Enterprise-Admins diesen Übergang detailliert steuern. Sie können Blueprints für einige Pilot-Orgs aktivieren, die Einführung in Ihrem eigenen Tempo ausweiten und bei Problemen sofort zurückrollen.

​
Status des Enterprise-Rollouts

Für das Enterprise gibt es drei übergeordnete Status, die steuern, wie Blueprints für Organisationen verfügbar sind:
StatusBedeutungAuswirkung auf Organisationen
DisabledBlueprints sind für das Enterprise nicht aktiviertKeine Orgs sehen die Umgebungsseiten. Alle Orgs verwenden das klassische Setup.
Default OffBlueprints sind verfügbar, aber nicht der StandardOrgs können vom Enterprise-Admin einzeln aktiviert werden. Neue Orgs starten mit dem klassischen Setup.
Default OnBlueprints sind für alle Orgs der StandardAlle Orgs verwenden Blueprints, sofern nicht ausdrücklich auf das klassische Setup umgestellt wird. Neue Orgs starten mit Blueprints.
Übergänge erfolgen in dieser Reihenfolge: Disabled → Default Off → Default On. Sie können auch einen Schritt zurückgehen (Default On → Default Off), um den Rollout zu verlangsamen.

​
Details zu „Default Off“

Im Status „Default Off“ verwenden Organisationen, die nicht aktiviert wurden, weiterhin das klassische Setup, und für sie ändert sich nichts. Der Enterprise-Admin kann auf der Rollout-Seite einzelne Orgs aktivieren. Nur diese Orgs wechseln zur deklarativen Konfiguration. Es gibt einen zusätzlichen Schalter: Migrationshinweis für alle Organisationen anzeigen. Wenn er aktiviert ist, sehen Org-Admins, die noch das klassische Setup verwenden, auf ihrer Seite „Machine Configuration“ einen Hinweis, der sie zur Migration zur deklarativen Konfiguration auffordert. Dadurch ändert sich ihre Einrichtung nicht, und sie erhalten keinen Zugriff auf die vollständigen Seiten zur Umgebungskonfiguration. Sie werden lediglich darauf aufmerksam gemacht, dass Blueprints verfügbar sind, und erhalten die Möglichkeit, sich zu aktivieren. Das ist nützlich, um zunächst Aufmerksamkeit dafür zu schaffen, bevor Sie mit der Migration von Orgs beginnen. Wenn dieser Schalter deaktiviert ist, sehen Orgs, die nicht ausdrücklich aktiviert wurden, nichts Neues. Für sie ändert sich nichts.

​
Überschreibungen pro Organisation

Enterprise-Admins können auf der Rollout-Seite den Rollout-Status einzelner Organisationen überschreiben:
  • In „Default Off“: Bestimmte Organisationen für Blueprints aktivieren. Diese Organisationen wechseln sofort vom klassischen Setup zur deklarativen Konfiguration.
  • In „Default On“: Bestimmte Organisationen wieder auf das klassische Setup zurücksetzen. Diese Organisationen verwenden weiterhin ihre klassische Konfiguration.
Überschreibungen sind dauerhaft. Sie bleiben auch bei Änderungen des Enterprise-Status bestehen. Wenn Sie eine Organisation während der Phase „Default Off“ für Blueprints aktivieren, bleibt sie bei Blueprints, wenn Sie zu „Default On“ wechseln.

​
Automatische klassische Überschreibungen

Beim Wechsel von Default Off zu Default On verhindert ein Sicherheitsmechanismus Unterbrechungen: Jede Org, die derzeit das klassische Setup verwendet und Repository konfiguriert hat, erhält automatisch eine explizite klassische Überschreibung. Das bedeutet, dass sich durch den Wechsel für Orgs, die das klassische Setup aktiv nutzen, nichts ändert. Sie werden unverändert weitergeführt, bis Sie sie ausdrücklich migrieren. Orgs ohne Repository (oder Orgs, die bereits Blueprints verwenden) sind von diesem Schutzmechanismus nicht betroffen. Am besten erstellen und validieren Sie Ihre Konfiguration zunächst isoliert, bevor Sie sie für Org-Admins freigeben. Vermeiden Sie eine Big-Bang-Migration. Beginnen Sie kontrolliert, prüfen Sie alles und erweitern Sie den Rollout dann schrittweise.

​
Phase 1: Isoliert aufsetzen und verifizieren (Default Off)

Beginnen Sie mit dem Enterprise im Modus Default Off. Orgs können sich nicht selbst dafür anmelden, sodass Sie die volle Kontrolle haben.
  1. Aktivieren Sie Blueprints auf Enterprise-Ebene, indem Sie von Disabled zu Default Off wechseln.
  2. Erstellen Sie eine dedizierte Test-Org zum Testen der Umgebungskonfiguration. Diese Org dient ausschließlich dazu, Ihre Blueprints zu validieren.
  3. Aktivieren Sie die deklarative Konfiguration nur für diese Test-Org (über den org-spezifischen Override auf der Rollout-Seite).
  4. Konfigurieren Sie Ihren Enterprise-Blueprint: Installieren Sie alle gemeinsam genutzten Sprach-Runtimes, Sicherheitstools, Unternehmenszertifikate, internen CLIs, Proxy-Einstellungen und die Registry-Authentifizierung. Das ist Ihre Basisschicht, die jede Org übernimmt.
  5. Konfigurieren Sie einen Org-Blueprint für die Test-Org mit allen Tools auf Org-Ebene oder der Registry-Konfiguration.
  6. Fügen Sie Repository-Blueprints hinzu für eine repräsentative Auswahl an Repositorys. Wählen Sie Repos aus, die Ihre gängigsten Tech-Stacks abdecken.
  7. Prüfen Sie alles Ende-zu-Ende: Starten Sie Devin-Sitzungen in diesen Repos und bestätigen Sie, dass alles funktioniert. Die Repos sollten geklont, Abhängigkeiten installiert und Lint-/Test-/Build-Befehle korrekt ausgeführt werden; außerdem sollten alle Tools in den erwarteten Versionen vorliegen.
Prüfen Sie nicht nur, ob Builds erfolgreich sind. Ein erfolgreicher Build bedeutet nicht immer, dass die Umgebung auch wirklich funktioniert. Ein fehlender PATH-Eintrag, eine falsche Tool-Version oder eine fehlende Registry-Authentifizierung können leicht unbemerkt bleiben. Verifizieren Sie daher immer, indem Sie eine echte Devin-Sitzung ausführen.

​
Phase 2: Opt-in für Org-Admins aktivieren

Sobald Sie bestätigt haben, dass Ihr Blueprint-Stack enterprise → org → repo korrekt zusammenspielt und funktionierende Umgebungen erzeugt:
  1. Intern kommunizieren Sie gegenüber den Org-Admins, dass die deklarative Konfiguration verfügbar und einsatzbereit ist.
  2. Den Migrationshinweis aktivieren: Aktivieren Sie „Show migration nudge to all organizations“, damit Org-Admins im klassischen Setup einen Hinweis sehen, der sie zur Migration ermutigt.
  3. Org-Admins können jetzt migrieren ihre eigenen Organisationen. Da der Enterprise-Blueprint bereits die Basisschicht (Laufzeitumgebungen, Tools, Zertifikate, Registries) bereitstellt, müssen Org-Admins nur noch das konfigurieren, was für ihr Team und ihre Repos spezifisch ist.
Jeder Org-Admin kann den Migrationsassistenten nutzen, um den Prozess zu vereinfachen. Devin kann den vorhandenen Snapshot der Organisation analysieren und automatisch eine äquivalente Blueprint-Konfiguration generieren. Siehe Migration zu deklarativer Konfiguration für den Schritt-für-Schritt-Ablauf. Erstellen Sie eine Bibliothek mit Blueprint-Vorlagen für Ihre gängigsten Tech-Stacks (Node.js, Python, Java, Go, mehrsprachige Monorepos) und teilen Sie sie intern, damit Org-Admins nicht bei null anfangen müssen. Die Vorlagenbibliothek ist dafür eine gute Grundlage.

​
Phase 3: Ausweiten und aufräumen

  1. Zu „Default On“ wechseln, sobald die meisten Orgs Blueprints verwenden. Orgs, die das klassische Setup mit Repos genutzt haben, erhalten automatisch klassische Überschreibungen, sodass sich für sie nichts ändert.
  2. Neue Orgs, die ab diesem Zeitpunkt erstellt werden, starten standardmäßig mit Blueprints.
  3. Die Rollout-Seite überwachen, um den Build-Status aller Orgs im Blick zu behalten. Nach „Classic“ filtern, um zu sehen, wer noch nicht migriert ist.
  4. Mit den verbleibenden Org-Admins zusammenarbeiten, um die letzten Nachzügler zu migrieren. Der Migrationsassistent macht das einfach.
  5. Klassische Überschreibungen entfernen, sobald alle Orgs auf Blueprints bestätigt sind.
Die klassische Konfiguration bleibt immer erhalten. Beim Wechsel einer Org zu Blueprints wird nichts gelöscht. Falls etwas schiefgeht, können Enterprise-Admins jede Org über die Rollout-Seite sofort wieder auf das klassische Setup zurücksetzen.

​
Rollback

Nicht immer läuft alles reibungslos. Das Rollout-System ermöglicht Rollbacks auf jeder Ebene.

​
Rollback pro Org

Enterprise-Admins können auf der Rollout-Seite jede einzelne Org wieder auf das klassische Setup zurücksetzen:
  • Die Org kehrt sofort zu ihrem Snapshot des klassischen Setups zurück.
  • Die klassische Konfiguration bleibt erhalten. Wenn eine Org zu Blueprints wechselt, geht nichts verloren, daher ist ein Zurückwechseln sicher.
  • Aktive Sitzungen sind nicht betroffen. Die Änderung wird in der nächsten Sitzung wirksam.

​
Unternehmensweites Rollback

Enterprise-Admins können von Default On wieder zu Standardmäßig deaktiviert wechseln:
  • Organisationen mit expliziten Blueprint-Überschreibungen behalten diese bei. Sie bleiben bei Blueprints.
  • Organisationen, die standardmäßig Blueprints verwendet haben (ohne Überschreibung), kehren zum klassischen Setup zurück.
  • Dies ist ein sicherer Vorgang. In beide Richtungen gehen keine Konfigurationsdaten verloren.
Ein Rollback löscht weder Blueprints noch klassische Konfigurationen. Beide bleiben erhalten, unabhängig davon, welcher Modus aktiv ist, sodass Sie ohne Arbeitsverlust zwischen ihnen wechseln können.

​
Überwachung des Rollout-Status

Die Seite „Rollout“ bietet ein Dashboard zur Nachverfolgung des Migrationsfortschritts in Ihrem Unternehmen.

​
KPI-Zeile

Oben auf der Seite geben zusammenfassende Metriken einen schnellen Überblick über den Rollout-Status:
  • Blueprint-Organisationen: Anzahl der Organisationen, die derzeit Blueprints nutzen
  • Rollout-Prozentsatz: Prozentsatz der Organisationen mit Blueprints an der Gesamtzahl
  • Build-Status: Aggregierter Build-Status über alle Blueprint-Organisationen hinweg

​
Tabelle pro Org

Unterhalb der KPIs führt eine detaillierte Tabelle jede Organisation auf:
ColumnDescription
OrganizationName der Org
StateAktueller Modus: Blueprints oder Classic
OverrideOb der Status der Org explizit überschrieben wird oder dem Enterprise-Standard entspricht
Classic reposAnzahl der Repos mit klassischer Setup-Konfiguration
Blueprint reposAnzahl der Repos mit Blueprints
Latest buildStatus des letzten Builds (erfolgreich, teilweise, fehlgeschlagen usw.)

​
Filtern

Filtern Sie die Tabelle nach:
  • Alle: Alle Orgs im Enterprise
  • Blueprints: Orgs, die derzeit Blueprints nutzen
  • Classic: Orgs, die derzeit das klassische Setup nutzen
  • Überschreibungen: Orgs mit expliziten Statusüberschreibungen (in beide Richtungen)

​
Sicherheit bei gleichzeitigen Änderungen

Statusänderungen sind vor gleichzeitigen Änderungen geschützt. Wenn ein anderer Administrator den Enterprise-Status zwischen dem Laden der Seite und dem Absenden Ihrer Änderung ändert, wird die Anfrage mit einem Konfliktfehler abgelehnt. Dadurch werden versehentliche Überschreibungen verhindert, wenn mehrere Enterprise-Admins gleichzeitig Änderungen vornehmen. Wenn Ihre Änderung abgelehnt wird, aktualisieren Sie die Seite, um den aktuellen Status zu sehen, und senden Sie die Änderung gegebenenfalls erneut ab.

​
Audit-Protokollierung

Alle Statuswechsel beim Rollout werden in Audit-Logs erfasst:
  • Änderungen am Enterprise-Status (Deaktiviert → Standardmäßig aus, Standardmäßig aus → Standardmäßig an usw.)
  • Änderungen an org-spezifischen Überschreibungen (org hat sich angemeldet, org hat sich abgemeldet, Überschreibung entfernt)
  • Welcher Admin die Änderung vorgenommen hat und wann
Diese Logs sind über die Standardoberfläche für Audit-Logs Ihres Enterprise verfügbar.