Vai al contenuto principale
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: 
+-----------------------------------------+
|  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 |
+-----------------------------------------+
TierChi lo amministraAmbito
EnterpriseAdmin EnterpriseTutte le organizzazioni, tutti i repository
OrganizationAdmin dell’orgTutti i repository dell’org
RepositoryAdmin dell’org o configurazione del repoUn 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 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. 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: 
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: 
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: 
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: 
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: 
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. Blueprint Enterprise (runs in ~):
   a. initialize
   b. maintenance
2. Blueprint organizzazione (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/<repo-name>):
   a. initialize
   b. maintenance
5. Health check, then snapshot is saved
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 pagina Configurazione a livello Enterprise, la stessa pagina in cui configuri il blueprint Enterprise. Vai a Settings > Ambiente di base di Devin per gestire sia il blueprint sia i segreti in un unico posto.
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.