Migrazione della tua azienda

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.

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. 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: 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. 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. 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. 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. 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. 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.

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 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 è un’ottima base.

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.

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. Non sempre tutto fila liscio. Il sistema di rollout consente il rollback a ogni livello. 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.

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. La pagina Rollout fornisce una dashboard per monitorare l’avanzamento della migrazione in tutta l’Enterprise. 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

Sotto i KPI, una tabella dettagliata mostra ogni organizzazione: 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)

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. 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.