Skip to main content
Die Konfiguration der Enterprise-Umgebung gilt für Infrastruktur, die alle Teams in Ihrer Organisation benötigen: VPN-Verbindungen, CA-Zertifikate, Proxy-Konfigurationen und DNS-Overrides. Diese Seite behandelt Enterprise-spezifische Konzepte. Allgemeine Informationen zur Umgebungskonfiguration finden Sie im Leitfaden Umgebungskonfiguration.

​
Was auf Enterprise-Ebene gehört

Navigieren Sie zu Enterprise Settings > Environment (oder klicken Sie auf „Enterprise-weites Setup“ auf der Seite Environment Settings einer beliebigen org). Das YAML-Format ist identisch mit der Konfiguration auf org- und Repo-Ebene — dieselben Abschnitte initialize, maintenance und knowledge gelten.
AnwendungsfallEnterpriseorg-weitRepo-Ebene
VPN-/Netzwerkzugriff✓
CA-Zertifikate✓
Proxy-Konfiguration✓
DNS-Overrides✓
GPG-Commit-Signierung✓
Gemeinsame Sprachlaufzeiten✓
org-weite CLI-Tools✓
Authentifizierung für private Registries✓
Repo-Abhängigkeiten✓
Repo-spezifische Tests/Linting✓
Enterprise-Änderungen haben weitreichende Auswirkungen. Beim Speichern werden Builds für alle Organisationen ausgelöst. Testen Sie Infrastrukturbefehle daher zuerst in einer einzelnen org (mit org-weiter Konfiguration), bevor Sie sie auf Enterprise-Ebene anwenden.
Die Konfiguration auf Enterprise-Ebene kann keine Repositorys klonen — das Klonen von Repositorys erfordert Zugriff auf org-Ebene. Verwenden Sie die Enterprise-Konfiguration nur für gemeinsam genutzte Infrastruktur (VPN, Zertifikate, Tools). Das Klonen von Repos wird auf org-Ebene automatisch gehandhabt.
Beispiele für VPN, CA-Zertifikate, Proxy und private Registrys finden Sie unter Enterprise-Beispiele auf der Seite „Konfigurationsbeispiele“.

​
Enterprise-Berechtigungen

AktionErforderliche Rolle
Enterprise-Konfiguration anzeigen/bearbeitenEnterprise Admin
org-Konfiguration anzeigen/bearbeitenOrg Admin oder Enterprise Admin
Repo-Konfiguration anzeigenBeliebiges org-Member
Repo-Konfiguration bearbeitenMember mit der Berechtigung ManageOrgSnapshots

​
Kaskadierende Builds

Wenn Sie die Enterprise-Konfiguration ändern:
  1. Für jede Organisation wird ein neuer Build ausgelöst
  2. Der Build jeder Organisation umfasst: Enterprise-Konfiguration → Org-Konfiguration → alle Repo-Konfigurationen
  3. Builds laufen pro Organisation unabhängig — ein Fehler in einer Organisation wirkt sich nicht auf die anderen aus
  4. Jede Organisation erhält ihr eigenes Maschinenabbild
Die Reihenfolge ist bei Enterprise-initialize-Schritten wichtig. Zuerst muss das VPN kommen (damit interne Hosts erreichbar sind), dann DNS (damit die Namensauflösung funktioniert), dann Zertifikate (damit HTTPS funktioniert), dann der Proxy (damit der Datenverkehr korrekt geroutet wird) und schließlich alle Tools, die aus internen Quellen herunterladen.

​
Verwaltung mehrerer Organisationen

Empfohlene Reihenfolge für die Einrichtung:
  1. Zuerst die Enterprise-Konfiguration — gemeinsame Infrastruktur einrichten (VPN, Zertifikate, Proxy)
  2. Danach die org-weite Konfiguration — jede Org Admin-Person konfiguriert gemeinsame Tools und den Zugriff auf die Registry
  3. Zuletzt die Repo-spezifische Konfiguration — Teams konfigurieren ihre einzelnen Repositorys
Jede Org erhält ihr eigenes Maschinenabbild. Die Enterprise-Konfiguration ist gemeinsam genutzt und additiv, aber Konfigurationen auf Org- und Repo-Ebene sind auf ihren jeweiligen Geltungsbereich beschränkt — die Konfiguration von Org A wirkt sich nicht auf Org B aus, und Build-Fehlschläge in einer Org wirken sich nicht auf andere aus. Weitere Informationen zur Org-Struktur finden Sie unter Organisationen verstehen. Die Konfigurationshierarchie (Enterprise → Org → Repo) ist streng additiv. Die Befehle jeder Ebene werden der Reihe nach ausgeführt, nachdem die vorherige Ebene abgeschlossen ist. Niedrigere Ebenen können nicht überschreiben oder ändern, was auf höheren Ebenen konfiguriert wurde.

​
Enterprise-Migration

Für Unternehmen, die vom interaktiven Legacy-Setup zur deklarativen Konfiguration migrieren:
  1. Konfigurieren Sie zuerst die YAML auf Enterprise-Ebene — gemeinsam genutzte Infrastruktur wie VPN, Zertifikate und Proxy-Einstellungen.
  2. Migrieren Sie jeweils nur eine org. Jede org hat einen eigenen Schalter „Legacy-Maschinen-Snapshot verwenden“, sodass Sie die Migration schrittweise durchführen können, ohne andere Teams zu beeinträchtigen.
  3. Ziehen Sie eine Test-org in Betracht. Erstellen Sie bei großen Enterprises eine dedizierte Test-Organisation, um die deklarative Konfiguration zu prüfen, bevor Sie sie auf Produktions-orgs ausrollen.
  4. Verwenden Sie Devin für die Skalierung. Devin kann Repos über parallele Sitzungen konfigurieren — starten Sie eine Sitzung pro Repo, und Devin erstellt automatisch Konfigurationsvorschläge. Das eignet sich gut für das Onboarding von 10–100+ Repos.
Den vollständigen Migrationsleitfaden (einschließlich des Schritt-für-Schritt-Workflows und des Testansatzes) finden Sie unter Migration vom interaktiven Setup.

​
Nächste Schritte