Migration Ihres Enterprise-Kontos

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

• In den Modi „Testing“ oder „Available“: Bestimmte Organisationen für Blueprints aktivieren. Diese Organisationen wechseln sofort vom klassischen Setup zur deklarativen Konfiguration.
• Im Modus „Enabled by default“: Bestimmte Organisationen wieder auf das klassische Setup zurücksetzen. Diese Organisationen verwenden weiterhin ihre klassische Konfiguration.

1. Aktivieren Sie deklarative Umgebungen für das Enterprise. Ihr Cognition-Administrator aktiviert die Funktion, wodurch das Enterprise in den Modus Testing versetzt wird.
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.

1. Intern kommunizieren Sie gegenüber den Org-Admins, dass die deklarative Konfiguration verfügbar und einsatzbereit ist.
2. In den Modus Available wechseln: Ändern Sie das Dropdown „Rollout mode“ von Testing auf Available. Org-Admins im klassischen Setup sehen jetzt einen Migrationshinweis, 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.

1. Enabled by default aktivieren, sobald die meisten Orgs Blueprints verwenden. Dies ist eine dauerhafte Aktion — 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.

1. Im Testing-Modus beginnen (damit jede Organisation einzeln aktiviert werden kann).
2. Zuerst den Enterprise-Blueprint konfigurieren. Lassen Sie Admins den Enterprise-Blueprint mit gemeinsam genutzten Runtimes, Tools, Zertifikaten und der Registry-Konfiguration einrichten. Das ist die Basisschicht, die alle Organisationen übernehmen.
3. In den Modus „Available“ wechseln. Dadurch wird der Migrationshinweis aktiviert, sodass Organisations-Admins auf ihrer Seite „Machine Configuration“ einen Hinweis sehen und die Migration selbst durchführen können.
4. Dokumentation breit streuen über die vorhandenen internen Channels (Slack, E-Mail, Wiki) und Organisations-Admins dazu ermutigen, sich selbst zu aktivieren. Der Migrationsassistent ermöglicht diesen Selbstservice für Organisations-Admins.
5. Für Organisationen mit 0 aktuell konfigurierten Repositorys automatisch aktivieren. Diese Organisationen haben nichts zu migrieren — der Wechsel zu Blueprints ist risikolos, da sie kein bestehendes klassisches Setup haben, das erhalten werden muss.
6. Die verbleibenden Organisationen schrittweise nacheinander migrieren. Wenn der Enterprise-Blueprint bereits konfiguriert ist, muss bei jeder Organisationsmigration nur noch organisationsspezifische und repo-spezifische Konfiguration ergänzt werden. Das ist deutlich einfacher, als von Grund auf zu migrieren.
7. „Enabled by default“ aktivieren, sobald die meisten Organisationen migriert wurden. Neue Organisationen, die nach diesem Zeitpunkt erstellt werden, starten mit aktivierten Blueprints.

• 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.

• 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

• 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)

• Änderungen am Enterprise-Modus (Testing → Verfügbar, Aktivierung von „Standardmäßig aktiviert“ usw.)
• Änderungen an org-spezifischen Überschreibungen (org hat sich angemeldet, org hat sich abgemeldet, Überschreibung entfernt)
• Welcher Admin die Änderung vorgenommen hat und wann