Skip to main content
Prerequisiti: Questa guida presuppone familiarità con la configurazione dichiarativa degli ambienti. Per un’introduzione, consulta Declarative environment configuration.
Prima di configurare gli ambienti, assicurati che il provider SCM sia connesso (Enterprise Settings > Integrations) e che a ogni organizzazione sia stato concesso l’accesso ai rispettivi repository (Enterprise Settings > Repository Permissions). Le org non possono aggiungere repo al proprio ambiente finché l’accesso non viene concesso esplicitamente. Per maggiori dettagli, consulta Git Integrations.
Gli amministratori Enterprise possono definire un ambiente di base che si applica a tutte le organizzazioni dell’Enterprise. In questo modo ottieni un controllo centralizzato sugli strumenti, i runtime e l’infrastruttura di sicurezza utilizzati da Devin, lasciando comunque alle singole org e repo la possibilità di personalizzare la propria configurazione a partire da questa base.

​
La gerarchia del blueprint

La configurazione dell’ambiente di Devin segue una gerarchia a tre livelli. Ogni livello si basa su quello precedente:
La relazione è additiva: i blueprint dell’org e del repo si basano sul blueprint Enterprise, non lo sostituiscono. Durante ogni build, il blueprint Enterprise viene eseguito per primo e definisce la base. Poi viene eseguito il blueprint dell’org, che aggiunge la configurazione specifica del team. Infine, viene eseguito il blueprint di ciascun repo con la configurazione specifica del progetto. Consulta Blueprint scope per capire come si relazionano i blueprint dell’org e del repo.

​
Configurare il blueprint Enterprise

Vai a Settings > ambiente di base di Devin per definire il blueprint Enterprise. Utilizza lo stesso formato dei blueprint org e repo, con le sezioni initialize, maintenance e knowledge. I blueprint Enterprise e org supportano anche una sezione post-build per i comandi che vengono eseguiti dopo che tutte le repo sono state clonate e configurate. Il blueprint Enterprise viene eseguito per primo in ogni build, prima dei blueprint org e repo. Ciò significa che gli strumenti e i runtime installati a livello Enterprise sono disponibili per tutti i blueprint successivi.

​
Cosa includere nel blueprint Enterprise

Il blueprint Enterprise serve per gli strumenti e la configurazione di cui ogni organizzazione ha bisogno. Casi d’uso comuni:

​
Runtime standard dei linguaggi

Blocca le versioni dei linguaggi a livello aziendale, così ogni team utilizza la stessa toolchain:

​
Strumenti di sicurezza e verifica della conformità

Installa scanner e strumenti di audit che ogni progetto deve usare:

​
Strumenti e utilità CLI interni

Distribuisci in ogni ambiente gli strumenti specifici dell’azienda:

​
Configurazione condivisa del registry di pacchetti

Configura i gestori di pacchetti in modo che puntino ai registry interni:

​
Configurazione del proxy aziendale e dei certificati

Installa i certificati CA aziendali e configura le impostazioni del proxy:

​
Come interagiscono i livelli

Durante una build, i passaggi di ciascun livello vengono eseguiti in una sequenza fissa. L’output dei livelli precedenti è disponibile per quelli successivi. Gli strumenti installati a livello Enterprise sono pronti all’uso nei blueprint org e repo senza doverli reinstallare. Una build crea un nuovo snapshot nel seguente ordine:
I passaggi post-build vengono eseguiti dopo che tutte le repo sono state clonate e configurate, quindi possono convalidare l’ambiente completamente assemblato. Un codice di uscita diverso da zero in un passaggio post-build fa fallire la build e non viene prodotto alcuno snapshot. Vedi post-build nel riferimento del blueprint. I livelli sono additivi: i blueprint dei repo possono usare gli strumenti installati dal blueprint dell’org o di Enterprise. I livelli inferiori non possono sovrascrivere ciò che è stato configurato a un livello superiore. Le build richiedono in genere 5–15 minuti. I singoli comandi vanno in timeout dopo 1 ora. Gli elementi knowledge di tutti i livelli vengono raccolti e resi disponibili a Devin. Se più livelli definiscono un elemento knowledge con lo stesso nome, vengono inclusi tutti. Non si sovrascrivono a vicenda.

​
Segreti Enterprise

Gli amministratori Enterprise possono definire segreti a livello Enterprise. Questi segreti sono disponibili come variabili d’ambiente durante ogni build e ogni sessione in tutte le organizzazioni, sia nei passaggi del blueprint Enterprise sia in quelli org e repo. Usa i segreti Enterprise per credenziali condivise in tutta l’azienda:
  • Token del registry interno dei pacchetti
  • Autenticazione del proxy aziendale
  • API key condivise per i servizi interni
  • Chiavi di licenza per strumenti aziendali
I segreti Enterprise vengono gestiti nella scheda Secrets all’interno dell’editor del blueprint Enterprise. Vai a Settings > Ambiente di base di Devin e passa alla scheda Secrets per gestire i segreti a livello Enterprise insieme alla configurazione del blueprint.
La gestione dei segreti Enterprise richiede l’autorizzazione ManageAccountResources.
Se un segreto org ha lo stesso nome di un segreto Enterprise, il segreto org ha la precedenza. In questo modo, le singole organizzazioni possono sovrascrivere i valori predefiniti a livello Enterprise quando necessario.

​
Rebuild a livello di Enterprise

Gli amministratori Enterprise possono attivare un rebuild che si applica a tutte le organizzazioni. È utile quando:
  • Aggiorni il blueprint Enterprise (ad es. porti Python dalla versione 3.11 alla 3.12)
  • Esegui la rotazione di un secret Enterprise
  • Devi aggiornare tutti gli ambienti dopo una patch di sicurezza
Attiva un rebuild a livello di Enterprise da Settings > ambiente di base di Devin. La build di ogni organizzazione viene eseguita con il blueprint Enterprise aggiornato, seguita dai blueprint org e repo dell’organizzazione.
I rebuild a livello di Enterprise rispettano la coda di build di ogni org. Se un’org ha già una build in corso, il rebuild avviato a livello di Enterprise viene messo in coda dopo di essa. Se una build è già in coda, viene annullata e sostituita da quella avviata a livello di Enterprise.

​
Gestione del rollout nelle organizzazioni

L’amministratore Enterprise controlla quali organizzazioni usano la configurazione dichiarativa anziché la configurazione classica dell’ambiente. La pagina Rollout offre visibilità sullo stato di adozione in tutte le org e consente di migrare progressivamente le organizzazioni. Consulta Migrare la tua Enterprise per una panoramica dettagliata degli stati del rollout, degli override a livello di org e di un playbook per una migrazione graduale.