Skip to main content
La configurazione dell’ambiente Enterprise riguarda l’infrastruttura necessaria a tutti i team della tua organizzazione: connessioni VPN, certificati CA, configurazione del proxy e override del DNS. Questa pagina illustra i concetti specifici di Enterprise. Per la configurazione generale dell’ambiente, consulta la guida Configurazione dell’ambiente.

​
Cosa rientra nel livello Enterprise

Vai a Enterprise Settings > Environment (oppure fai clic su “Enterprise-wide setup” dalla pagina Environment Settings di qualsiasi org). Il formato YAML è identico alla configurazione a livello di org e repo: si applicano le stesse sezioni initialize, maintenance e knowledge.
Caso d’usoEnterpriseOrg-wideRepo-level
Accesso VPN / di rete✓
Certificati CA✓
Configurazione del proxy✓
Override DNS✓
Firma dei commit GPG✓
Runtime dei linguaggi condivisi✓
Strumenti CLI org-wide✓
Autenticazione al private registry✓
Dipendenze del repo✓
Test/lint specifici per repo✓
Le modifiche a livello Enterprise hanno un impatto elevato. Il salvataggio avvia build per tutte le organizzazioni. Testa prima i comandi dell’infrastruttura in una singola org (usando la configurazione org-wide) prima di applicarli a livello Enterprise.
La configurazione a livello Enterprise non può clonare i repository: la clonazione dei repository richiede accesso a livello di org. Usa la configurazione Enterprise solo per l’infrastruttura condivisa (VPN, certificati, strumenti). La clonazione dei repo viene gestita automaticamente a livello di org.
Per esempi di VPN, certificati CA, proxy e private registry, vedi Esempi Enterprise nella pagina Esempi di configurazione.

​
Autorizzazioni Enterprise

AzioneRuolo richiesto
Visualizzare/modificare la configurazione EnterpriseEnterprise Admin
Visualizzare/modificare la configurazione dell’orgOrg Admin o Enterprise Admin
Visualizzare la configurazione del repoQualsiasi membro dell’org
Modificare la configurazione del repoMembro dell’org con autorizzazione ManageOrgSnapshots

​
Build a cascata

Quando modifichi la configurazione Enterprise:
  1. Viene avviata una nuova build per ogni organizzazione
  2. La build di ogni org include: configurazione Enterprise → configurazione dell’org → tutte le configurazioni dei repo
  3. Le build vengono eseguite in modo indipendente per ogni org — un errore in un’org non influisce sulle altre
  4. Ogni org ottiene la propria machine image
L’ordine è importante per i passaggi initialize di Enterprise. La VPN deve venire per prima (così gli host interni sono raggiungibili), poi il DNS (così i nomi si risolvono), poi i certificati (così HTTPS funziona), poi il proxy (così il traffico viene instradato correttamente) e infine eventuali strumenti che scaricano da fonti interne.

​
Gestione di più organizzazioni

Ordine di configurazione consigliato:
  1. Per prima la configurazione Enterprise — imposta l’infrastruttura condivisa (VPN, certificati, proxy)
  2. Per seconda la configurazione a livello di org — ogni admin dell’org configura gli strumenti condivisi e l’accesso al registry
  3. Per ultima la configurazione specifica per repo — i team configurano i singoli repository
Ogni org ha la propria machine image. La configurazione Enterprise è condivisa e additiva, ma le configurazioni a livello di org e di repo hanno un ambito distinto: la configurazione dell’Org A non influisce sull’Org B e gli errori di build in una org non influiscono sulle altre. Per ulteriori informazioni sulla struttura delle org, vedi Comprendere le organizzazioni. La gerarchia di configurazione (Enterprise → Org → Repo) è rigorosamente additiva. I comandi di ciascun livello vengono eseguiti in sequenza dopo il completamento del livello precedente. I livelli inferiori non possono sovrascrivere o modificare ciò che è configurato dai livelli superiori.

​
Migrazione Enterprise

Per le aziende che stanno passando dalla configurazione interattiva legacy alla configurazione dichiarativa:
  1. Configurate prima il file YAML a livello Enterprise — infrastruttura condivisa come VPN, certificati e impostazioni del proxy.
  2. Eseguite la migrazione di una org alla volta. Ogni org ha il proprio interruttore “Usa lo snapshot legacy della macchina”, così potete migrare progressivamente senza influire sugli altri team.
  3. Valutate una org di test. Per le grandi aziende, create un’organizzazione di test dedicata per convalidare la configurazione dichiarativa prima di estenderla alle org di produzione.
  4. Usate Devin per scalare. Devin può configurare le repo tramite sessioni parallele: avviate una sessione per ogni repo e Devin genererà automaticamente proposte di configurazione. Questo approccio funziona bene per l’onboarding di 10–100+ repo.
Per la guida completa alla migrazione (inclusi il flusso di lavoro passo dopo passo e l’approccio al testing), consultate Migrare dalla configurazione interattiva.

​
Prossimi passaggi