> ## 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. # Migrazione della tua azienda > Distribuzione progressiva della configurazione dichiarativa dell'ambiente nella tua azienda: stati di rollout, override per org, playbook di migrazione graduale e monitoraggio. La migrazione di un'azienda dalla configurazione classica dell'ambiente a una configurazione dichiarativa rappresenta un cambiamento significativo. La pagina Rollout offre agli amministratori Enterprise un controllo granulare su questa transizione. Puoi abilitare i blueprint per alcune org pilota, estendere gradualmente il rollout al ritmo che preferisci ed eseguire immediatamente un rollback se qualcosa va storto.
## Stati del rollout Enterprise
La pagina Rollout include un selettore **Modalità di rollout** che controlla come i blueprint vengono resi disponibili alle organizzazioni. Sono disponibili tre modalità, più uno stato iniziale prima dell'attivazione degli ambienti dichiarativi: | Stato | Significato | Effetto sulle organizzazioni | | ------------------------------------------ | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Non abilitato** | Gli ambienti dichiarativi non sono ancora stati attivati per l'enterprise | Nessuna org vede le pagine degli ambienti. Tutte le org usano la configurazione classica. Contatta un amministratore Cognition per abilitare questa funzionalità. | | **Testing** | Solo le organizzazioni abilitate manualmente usano gli ambienti dichiarativi | Un amministratore Enterprise abilita le singole org dalla pagina Rollout. Tutte le altre org restano sulla configurazione classica e non vedono alcuna modifica. | | **Disponibile** | Gli amministratori delle org vedono un prompt di migrazione e possono passare in autonomia | Gli amministratori delle org che usano la configurazione classica vedono un avviso di migrazione nella pagina Machine Configuration. Possono migrare in self-service senza l'intervento di un amministratore Enterprise. | | **Abilitato per impostazione predefinita** | Le nuove organizzazioni usano gli ambienti dichiarativi per impostazione predefinita | Tutte le nuove org iniziano con i blueprint. Le org esistenti che usavano la configurazione classica con repo ricevono automaticamente classic override. | La progressione è: **Testing → Disponibile → Abilitato per impostazione predefinita**. Puoi passare liberamente tra **Testing** e **Disponibile** usando il menu a discesa della Modalità di rollout. Tuttavia, **Abilitato per impostazione predefinita** è un'azione permanente che non può essere annullata senza l'intervento di un amministratore Cognition. **Abilitato per impostazione predefinita è permanente.** Una volta attivata questa modalità, non può essere ripristinata su Testing o Disponibile senza contattare un amministratore Cognition. Assicurati che l'enterprise blueprint sia stato convalidato completamente e che la maggior parte delle org usi i blueprint prima di abilitare questa modalità.
### Dettagli sulla modalità di test
Nella modalità di test, le organizzazioni che non hanno aderito continuano a usare la configurazione classica e non vedono alcuna modifica nella loro esperienza. L'amministratore Enterprise può abilitare singole org dalla pagina Rollout. Solo queste org passano alla configurazione dichiarativa. Questa è la modalità base quando gli ambienti dichiarativi vengono attivati per la prima volta in un Enterprise.
### Dettagli sulla modalità Available
La modalità Available aggiunge un promemoria di migrazione: gli amministratori delle org che usano ancora la configurazione classica vedono un avviso nella pagina Machine Configuration che li invita a migrare alla configurazione dichiarativa. Questo non cambia la loro configurazione né concede l'accesso alle pagine complete di configurazione dell'ambiente. Serve semplicemente a informarli che i blueprint sono disponibili e a offrire un modo self-service per aderire. È utile per sensibilizzare e consentire agli amministratori delle org di migrare secondo i propri tempi.
## Override per org
Gli amministratori Enterprise possono fare override dello stato di rollout per singole organizzazioni direttamente nella tabella per org della pagina Rollout: * **In Testing o Available**: abilita blueprint per org specifiche. Queste org passano immediatamente dalla configurazione classica alla configurazione dichiarativa. * **In Enabled by default**: disabilita blueprint per org specifiche e le riporta alla configurazione classica. Queste org continuano a usare la configurazione classica. Gli override sono persistenti. Rimangono in vigore anche in caso di cambi di modalità. Se abiliti i blueprint per un'org durante la modalità Testing, l'org rimane sui blueprint quando passi ad Available o Enabled by default.
### Override automatici della configurazione classica
Quando attivi **Enabled by default**, un meccanismo di sicurezza evita interruzioni: qualsiasi org che attualmente usa la configurazione classica **e ha repository configurati** riceve automaticamente un override esplicito per la configurazione classica. Ciò significa che la transizione non cambia nulla per le org che stanno usando attivamente la configurazione classica. Continuano a funzionare come prima finché non le migri esplicitamente. Le org senza repository (o le org che usano già i blueprint) non sono interessate da questo meccanismo. L'approccio migliore è creare e convalidare la configurazione in isolamento prima di renderla disponibile agli amministratori dell'org. Evita una migrazione in un'unica soluzione. Inizia in modo controllato, verifica, poi estendi.
### Fase 1: Configurare e verificare in isolamento (Testing)
Inizia con l'enterprise in modalità **Testing**. Le org non possono aderire autonomamente, quindi hai il pieno controllo. 1. **Attiva gli ambienti dichiarativi** per l'enterprise. Il tuo amministratore Cognition abilita la funzionalità, portando l'enterprise in modalità Testing. 2. **Crea un'org di test dedicata** per il testing della configurazione dell'ambiente. Questa org serve esclusivamente a convalidare i blueprint. 3. **Abilita la configurazione dichiarativa** solo per questa org di test (tramite override per org nella pagina Rollout). 4. **Configura il blueprint dell'enterprise**: installa tutti i language runtimes condivisi, gli strumenti di sicurezza, i certificati corporate, le CLI interne, le impostazioni del proxy e l'autenticazione del registry. Questo è il layer di base che ogni org erediterà. 5. **Configura un blueprint dell'org** di test con eventuali strumenti a livello org o configurazioni del registry. 6. **Aggiungi blueprint di repository** per un insieme rappresentativo di repository. Scegli repo che coprano gli stack tecnologici più comuni. 7. **Verifica end-to-end**: avvia session di Devin su queste repo e conferma che tutto funzioni. Le repo devono essere clonate, le dipendenze installate, i comandi di lint/test/build eseguiti correttamente e tutti gli strumenti devono essere alle versioni previste. Non limitarti a verificare che le build vadano a buon fine. Una build riuscita non significa sempre che l'ambiente funzioni correttamente. Una voce PATH mancante, una versione errata di uno strumento o l'autenticazione del registry mancante possono passare inosservate. Verifica sempre eseguendo una session reale di Devin.
### Fase 2: Abilitare l'opt-in per gli amministratori delle org (Available)
Una volta verificato che lo stack di blueprint enterprise → org → repo si combina correttamente e produce ambienti funzionanti: 1. **Comunica internamente** agli amministratori delle org che la configurazione dichiarativa è disponibile e pronta all'uso. 2. **Passa alla modalità Available**: modifica il menu a discesa della modalità Rollout da Testing ad Available. Gli amministratori delle org che usano la configurazione classica vedono ora un avviso di migrazione che li incoraggia a migrare. 3. **Gli amministratori delle org possono ora migrare** le proprie organizzazioni. Poiché il blueprint enterprise fornisce già il livello di base (runtime, strumenti, certificati, registry), gli amministratori delle org devono configurare solo ciò che è specifico per il proprio team e le repo. Ogni amministratore di org può usare l'**assistente di migrazione** per semplificare il processo. Devin può analizzare lo snapshot esistente dell'org e generare automaticamente una configurazione blueprint equivalente. Consulta [Migrazione alla configurazione dichiarativa](/it/onboard-devin/environment/migration) per la procedura passo passo. Crea una libreria di blueprint template per gli stack tecnologici più comuni (Node.js, Python, Java, Go, monorepo multilingue) e condividila internamente, così gli amministratori delle org non dovranno partire da zero. La [Libreria di template](/it/onboard-devin/environment/templates) è un'ottima base.
### Fase 3: Espandi e ripulisci (Abilitato per impostazione predefinita)
1. **Attiva Enabled by default** quando la maggior parte delle org usa blueprints. Si tratta di un'azione permanente — le org che erano sulla configurazione classica con repo ricevono automaticamente override classici, quindi per loro non cambia nulla. 2. Le **nuove org** create da questo momento in poi iniziano con blueprints per impostazione predefinita. 3. **Monitora la pagina Rollout** per controllare lo stato delle build in tutte le org. Filtra per "Classic" per vedere chi non ha ancora eseguito la migrazione. 4. **Collabora con gli amministratori delle org rimanenti** per migrare quelle che non l'hanno ancora completata. L'assistente alla migrazione rende questa operazione semplice. 5. **Rimuovi gli override classici** una volta che tutte le org sono state verificate su blueprints. La configurazione classica viene sempre mantenuta. Quando un'org passa a blueprints, non viene eliminato nulla. Se qualcosa va storto, gli amministratori Enterprise possono riportare qualsiasi org alla configurazione classica dalla pagina Rollout usando override per org.
### Strategia di migrazione accelerata
Per le aziende che vogliono procedere rapidamente, ecco un approccio che riduce al minimo l'onere di migrazione per ogni org: 1. **Inizia in modalità di test** (così puoi attivarla per ogni org singolarmente). 2. **Configura prima l'enterprise blueprint.** Chiedi agli admin di configurare l'enterprise blueprint con runtimes condivisi, strumenti, certificati e configurazione del registry. Questo è il layer di base che tutte le org erediteranno. 3. **Passa alla modalità Available.** In questo modo viene abilitato il promemoria di migrazione, così gli admin delle org vedranno un avviso nella pagina Machine Configuration e potranno migrare in autonomia. 4. **Diffondi la documentazione** tramite i canali interni disponibili (Slack, email, wiki) e incoraggia gli admin delle org ad attivarsi autonomamente. L'assistente alla migrazione rende il processo self-service per gli admin delle org. 5. **Abilita automaticamente le org con 0 repository attualmente configurati.** Queste org non hanno nulla da migrare: non c'è alcun rischio nel passare ai blueprint, perché non hanno una configurazione classica esistente da preservare. 6. **Migra progressivamente le org rimanenti una per una.** Con l'enterprise blueprint già configurato, ogni migrazione richiede solo di aggiungere la configurazione specifica per org e quella specifica per repo. È molto più semplice che migrare da zero. 7. **Attiva Enabled by default** una volta che la maggior parte delle org è stata migrata. Le nuove organizzazioni create da quel momento in poi partiranno con i blueprint abilitati. Questo approccio concentra subito la configurazione dell'enterprise blueprint (il lavoro a maggior impatto) e poi consente alle singole org di migrare con il minimo sforzo, seguendo i propri tempi.
## Rollback
Non sempre tutto fila liscio. Il sistema di rollout consente il rollback a ogni livello.
### Rollback per org
Gli amministratori Enterprise possono riportare qualsiasi singola org alla configurazione classica dalla pagina Rollout: * L'org **torna immediatamente** a usare il proprio snapshot della configurazione classica. * La configurazione classica viene **mantenuta**. Non si perde nulla quando un'org passa ai blueprint, quindi tornare indietro è sicuro. * Le sessioni attive non sono influenzate. La modifica ha effetto dalla sessione successiva.
### Rollback della modalità
Gli amministratori Enterprise possono passare liberamente tra **Testing** e **Available** usando il menu a discesa Rollout mode. Questo è utile se vuoi mettere in pausa la migrazione self-service mentre esamini un problema. **Enabled by default non può essere annullato** dall'amministratore Enterprise. Se hai bisogno di annullare Enabled by default, contatta il tuo amministratore Cognition. Gli override per org possono comunque essere usati per riportare singole org alla configurazione classica in qualsiasi momento. Il rollback non elimina i blueprint né le configurazioni classiche. Entrambi vengono conservati indipendentemente dalla modalità attiva, quindi puoi passare tra Testing e Available senza perdere il lavoro.
## Monitoraggio dello stato del rollout
La pagina Rollout fornisce una dashboard per monitorare l'avanzamento della migrazione in tutta l'Enterprise.
### Riga dei KPI
Nella parte superiore della pagina, le metriche di riepilogo offrono una rapida panoramica dello stato del rollout: * **Blueprint orgs**: Numero di organizzazioni che utilizzano attualmente blueprint * **Percentuale di rollout**: Percentuale di org che utilizzano blueprint sul totale * **Stato di salute delle build**: Stato aggregato delle build nelle org che utilizzano blueprint
### Tabella per org
Sotto i KPI, una tabella dettagliata mostra ogni organizzazione: | Column | Description | | ------------------- | ----------------------------------------------------------------------------------- | | **Organization** | Nome dell'org | | **State** | Modalità attuale: Blueprints o Classic | | **Override** | Se lo stato dell'org è un override esplicito o usa il valore predefinito Enterprise | | **Classic repos** | Numero di repo con configurazione classica | | **Blueprint repos** | Numero di repo con blueprints | | **Latest build** | Stato della build più recente (Riuscita, Parziale, Fallita, ecc.) |
### Filtraggio
Filtra la tabella per: * **Tutte**: tutte le org nell'Enterprise * **Blueprints**: org che attualmente usano i blueprint * **Classic**: org che attualmente usano la configurazione classica * **Override**: org con override espliciti dello stato (in entrambe le direzioni)
## Sicurezza rispetto alla concorrenza
Le transizioni di stato sono protette dalle modifiche simultanee. Se un altro amministratore modifica lo stato dell'Enterprise tra il momento in cui hai caricato la pagina e quello in cui invii la tua modifica, la richiesta viene respinta con un errore di conflitto. Questo evita sovrascritture accidentali quando più amministratori Enterprise operano contemporaneamente. Se la tua modifica viene respinta, aggiorna la pagina per visualizzare lo stato corrente e inviala di nuovo se è ancora opportuno.
## Registrazione nei log di audit
Tutte le transizioni dello stato di rollout vengono registrate nei log di audit: * Modifiche alla modalità Enterprise (Testing → Available, attivazione di Enabled by default, ecc.) * Modifiche agli override per org (org ha scelto di aderire, org ha scelto di non aderire, override rimosso) * Quale admin ha effettuato la modifica e quando Questi log sono disponibili tramite l'interfaccia standard dei log di audit della tua Enterprise.