> ## 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. # Panoramica dell'ambiente Enterprise > Gestione degli ambienti a livello Enterprise: gerarchia dei blueprint, configurazione dei blueprint Enterprise, segreti e rebuild a livello Enterprise. **Prerequisiti:** Questa guida presuppone familiarità con la configurazione dichiarativa degli ambienti. Per un'introduzione, consulta [Declarative environment configuration](/it/onboard-devin/environment/blueprints). **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](/it/enterprise/integrations/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: ``` +-----------------------------------------+ | Enterprise Blueprint | | Python 3.12, Node 20, security tools | +-----------------------------------------+ | Organization Blueprint | | registry npm privato, linting del team | +-----------------------------------------+ | Repository Blueprint | | npm install, config specifica del progetto | +-----------------------------------------+ ``` | Tier | Chi lo amministra | Ambito | | ---------------- | ---------------------------------------- | ------------------------------------------- | | **Enterprise** | Admin Enterprise | Tutte le organizzazioni, tutti i repository | | **Organization** | Admin dell'org | Tutti i repository dell'org | | **Repository** | Admin dell'org o configurazione del repo | Un singolo repository | 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](/it/onboard-devin/environment/blueprints#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`](/it/onboard-devin/environment/blueprint-reference#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: ```yaml theme={null} initialize: - name: "Install Python 3.12" uses: github.com/actions/setup-python@v5 with: python-version: "3.12" - name: "Install Node.js 20" uses: github.com/actions/setup-node@v4 with: node-version: "20" - name: "Install Go 1.22" uses: github.com/actions/setup-go@v5 with: go-version: "1.22" ```
### Strumenti di sicurezza e verifica della conformità
Installa scanner e strumenti di audit che ogni progetto deve usare: ```yaml theme={null} initialize: - name: "Install security tools" run: | npm install -g snyk pip install safety bandit curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh ```
### Strumenti e utilità CLI interni
Distribuisci in ogni ambiente gli strumenti specifici dell'azienda: ```yaml theme={null} initialize: - name: "Install internal CLI" run: | curl -L https://internal.example.com/cli/latest/linux-amd64 \ -o /usr/local/bin/internal-cli chmod +x /usr/local/bin/internal-cli ```
### Configurazione condivisa del registry di pacchetti
Configura i gestori di pacchetti in modo che puntino ai registry interni: ```yaml theme={null} initialize: - name: "Configure internal registries" run: | npm config set registry https://npm.internal.example.com/ pip config set global.index-url https://pypi.internal.example.com/simple/ ```
### Configurazione del proxy aziendale e dei certificati
Installa i certificati CA aziendali e configura le impostazioni del proxy: ```yaml theme={null} initialize: - name: "Install corporate certificates" run: | cp "$FILE_CORPORATE_CA_CERT" /usr/local/share/ca-certificates/corporate-ca.crt update-ca-certificates echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corporate-ca.crt' >> ~/.bashrc ```
## 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: ``` 1. Enterprise blueprint (runs in ~): a. initialize b. maintenance 2. Organization blueprint (runs in ~): a. initialize b. maintenance 3. Clone all repositories (up to 10 concurrent) 4. For each configured repo, in the order shown in Settings (runs in ~/repos/): a. initialize b. maintenance 5. post-build (org- and enterprise-level; runs in ~) 6. Health check, then snapshot is saved ``` 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`](/it/onboard-devin/environment/blueprint-reference#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](/it/enterprise/environment-management/rollout) per una panoramica dettagliata degli stati del rollout, degli override a livello di org e di un playbook per una migrazione graduale. * [Migrare la tua Enterprise](/it/enterprise/environment-management/rollout) * [Best practice](/it/enterprise/environment-management/best-practices) * [Riferimento per i blueprint](/it/onboard-devin/environment/blueprint-reference) * [Configurazione dichiarativa dell'ambiente](/it/onboard-devin/environment/blueprints)