Vai al contenuto principale
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 di rollout di Enterprise

Enterprise ha tre stati principali che controllano come i blueprint vengono resi disponibili alle organizzazioni:
StatoSignificatoEffetto sulle organizzazioni
DisabledI blueprint non sono abilitati per EnterpriseNessuna org visualizza le pagine Environment. Tutte le org usano la configurazione classica.
Default OffI blueprint sono disponibili ma non predefinitiLe org possono essere attivate singolarmente dall’admin Enterprise. Le nuove org iniziano con la configurazione classica.
Default OnI blueprint sono l’impostazione predefinita per tutte le orgTutte le org usano i blueprint, salvo override esplicito alla configurazione classica. Le nuove org iniziano con i blueprint.
Le transizioni avvengono in ordine: Disabled → Default Off → Default On. Puoi anche tornare allo stato precedente (Default On → Default Off) per rallentare il rollout.

​
Dettagli su Default Off

Nello stato Default Off, 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. È presente un interruttore aggiuntivo: Mostra il promemoria di migrazione a tutte le organizzazioni. Quando è abilitato, 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 per aderire. È utile per sensibilizzare prima di iniziare la migrazione delle org. Quando questo interruttore è disabilitato, le org che non sono state abilitate esplicitamente non vedono nulla di nuovo. La loro esperienza rimane invariata.

​
Override per org

Gli amministratori Enterprise possono fare override dello stato di rollout per singole organizzazioni dalla pagina Rollout:
  • In Default Off: abilita blueprint per org specifiche. Queste org passano immediatamente dalla configurazione classica alla configurazione dichiarativa.
  • In Default On: 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 modifiche allo stato Enterprise. Se abiliti i blueprint per un’org durante la fase Default Off, l’org rimane sui blueprint quando passi a Default On.

​
Override automatici della configurazione classica

Durante la transizione da Default Off a Default On, 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 (Default Off)

Inizia con l’enterprise in modalità Default Off. Le org non possono aderire autonomamente, quindi hai il pieno controllo.
  1. Abilita i blueprint a livello enterprise passando da Disabled a Default Off.
  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

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. Abilita il promemoria di migrazione: attiva “Mostra il promemoria di migrazione a tutte le organizzazioni” in modo che gli amministratori delle org che usano la configurazione classica vedano un avviso 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.

​
Fase 3: Espandi e ripulisci

  1. Passa a Default On quando la maggior parte delle org usa blueprints. 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 immediatamente qualsiasi org alla configurazione classica dalla pagina Rollout.

​
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 a livello di Enterprise

Gli amministratori Enterprise possono tornare da Default On a Default Off:
  • Le org che avevano override espliciti dei blueprint li mantengono. Continuano a usare i blueprint.
  • Le org che usavano i blueprint per impostazione predefinita (senza override) tornano alla configurazione classica.
  • Si tratta di un’operazione sicura. Nessun dato di configurazione viene perso in nessuna delle due direzioni.
Il rollback non elimina i blueprint né le configurazioni classiche. Entrambi vengono conservati indipendentemente dalla modalità attiva, quindi puoi passare dall’una all’altra 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:
ColumnDescription
OrganizationNome dell’org
StateModalità attuale: Blueprints o Classic
OverrideSe lo stato dell’org è un override esplicito o usa il valore predefinito Enterprise
Classic reposNumero di repo con configurazione classica
Blueprint reposNumero di repo con blueprints
Latest buildStato 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 allo stato Enterprise (Disabled → Default Off, Default Off → Default On, 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.