1. Informazioni sulle migrazioni in tempo reale aziendali

Servizi di Azure DevOps

Enterprise Live Migrations (ELM) consente di eseguire la migrazione di repository Azure DevOps a GitHub Enterprise Cloud con residenza dei dati con interruzioni minime. ELM sincronizza continuamente i repository di origine e di destinazione, così i tuoi team possono continuare a lavorare in Azure DevOps Services finché non sono pronti per il passaggio. Esistono due percorsi di migrazione: il cut over completamente per GitHub o l'uso di un modello ibrido in cui il codice sorgente passa a GitHub mentre i team continuano a usare Azure Boards e Azure Pipelines.

ELM è disponibile in due esperienze: l'interfaccia della riga di comando di Azure DevOps e il portale di Azure DevOps. Usare l'interfaccia della riga di comando per creare script o eseguire migrazioni dalla riga di comando. Usare il portale quando si vuole un'esperienza guidata per la selezione dei repository, l'avvio delle migrazioni e il rilevamento dello stato di avanzamento.

Funzionalità principali

ELM offre le funzionalità di base seguenti:

• Sincronizzazione continua: ELM sincronizza le modifiche da Azure DevOps a GitHub usando la sincronizzazione incrementale e il rilevamento differenziale, in modo che i team possano continuare a lavorare in Azure DevOps fino al cutover. Prevedere una breve finestra di sola lettura durante il cutover, in genere inferiore a 30 minuti per la maggior parte dei repository.
• Migrazioni di più repository: ELM supporta la migrazione di più repository, con fino a 20 processi di migrazione simultanei. Nell'interfaccia della riga di comando eseguire il comando di migrazione per ogni repository uno alla volta. Nell'interfaccia utente è possibile selezionare fino a 20 repository di cui eseguire la migrazione insieme.
• Flusso di lavoro di migrazione end-to-end: ELM tiene traccia degli stati del repository tramite l'inizializzazione, la sincronizzazione, il cutover, la convalida e il completamento. Questo modello offre visibilità sullo stato della migrazione e supporta la risoluzione dei problemi.
• Cutover pianificato dal cliente: Si sceglie e si pianifica il tempo di cutover per cambiare il sistema di record da Azure DevOps a GitHub.
• La configurazione post-migrazione è stata semplificata: ELM consente di ridurre il lavoro manuale dopo il cutover configurando la connessione Azure Boards e ricollegando Azure Pipelines in modo che punti al repository di GitHub migrato. Questo rende più semplice per i team continuare a usare Azure DevOps per la pianificazione e le pipeline, lavorando in GitHub sul codice sorgente, con meno attriti nel passaggio di consegne e meno attività successive.

Flusso di dati di migrazione

ELM trasferisce i dati del repository dall'origine a GitHub Enterprise Cloud tramite canali crittografati. Esegue la migrazione del contenuto, della cronologia, dei metadati e delle autorizzazioni del repository, quindi usa la sincronizzazione incrementale per copiare solo le modifiche dopo il trasferimento iniziale. ELM non archivia il contenuto del repository dei clienti all'esterno del processo di migrazione.

Sicurezza e gestione dei dati

ELM è progettato in modo che il contenuto del repository rimanga sotto il controllo e Microsoft mantiene solo i dati operativi minimi necessari per eseguire la migrazione.

Dati in movimento

Tutte le comunicazioni tra Azure DevOps, l'agente Linux self-hosted e GitHub Enterprise Cloud usano HTTPS crittografato con TLS. Il contenuto del repository viene trasferito tramite protocolli Git crittografati. ELM non archivia il contenuto del repository dei clienti all'esterno del processo di migrazione attivo.

Gestione PAT

ELM richiede due token di accesso personale GitHub, ognuno usato per uno scopo diverso. Considerare entrambi come segreti e concedere solo gli ambiti documentati in Prerequisiti. Impostare scadenze di breve durata per entrambi i PAT e ruotarli o revocarli al termine della migrazione. Revoca immediatamente una delle due PAT se sospetti che sia stata esposta. Limitare gli utenti che possono visualizzare o modificare la connessione del servizio all'operatore di migrazione e agli amministratori necessari.

• Pat di connessione al servizio: Un amministratore GitHub Enterprise crea questo pat e lo usa per creare la connessione al servizio Azure DevOps per l'organizzazione di destinazione GitHub. Memorizza questo PAT solo nella connessione del servizio. Non farne il commit nel controllo versione, non condividerlo in chat e non incollarlo nei log.
• Pat di migrazione personale: La persona che esegue la migrazione crea il token di accesso personale e lo usa per eseguire l'autenticazione per GitHub durante la migrazione.

Cosa conserva Microsoft

ELM archivia solo i metadati operativi relativi alla migrazione: ID repository, stato della migrazione, risultati della convalida, messaggi di errore ed eventi di controllo. ELM non conserva i contenuti del repository, i dati dei commit o il PAT al termine della migrazione.

Audit

ELM scrive gli eventi del ciclo di vita della migrazione nel log di controllo Azure DevOps in modo che gli amministratori aziendali possano esaminare chi ha avviato, sospeso, ripreso, pianificato o abbandonato una migrazione. Usare il log di controllo per supportare le verifiche di conformità e ricostruire la sequenza temporale della migrazione se è necessario analizzare un problema.

Per visualizzare gli eventi di controllo, passare a Impostazioni> organizzazioneControllo e filtro in base all'area Enterprise Live Migrations.

Ambito di ELM

Cosa automatizza ELM

• Esegue controlli di pre-migrazione.
• Sincronizza il codice Git, inclusi i rami, la cronologia delle modifiche e i tag in GitHub.
• Sincronizza le richieste pull, inclusi titoli, descrizioni, commenti e cronologia utente.
• Crea il repository GitHub di destinazione.
• Migra i criteri del branch nei set di regole del branch di GitHub.
• Riconfigura Azure Pipelines affinché punti al nuovo repository GitHub.
• Crea una connessione a schede.
• Passa da Azure DevOps a GitHub.

Operazioni eseguite manualmente

• Pulire il repository Azure DevOps prima della migrazione (file di grandi dimensioni, richieste pull con più di 10.000 file, nomi di riferimento lunghi).
• Creare l'organizzazione di GitHub di destinazione.
• Verificare lo stato del repository dopo la migrazione (rami, tag, cronologia, pull request).
• Verificare e modificare i set di regole dei rami migrati.
• Aggiornare gli URL dei repository di Azure DevOps codificati in modo statico in script, pipeline e strumenti.
• Configura l'accesso del team e degli utenti in GitHub.
• Eseguire la migrazione o dismettere gli elementi di lavoro, i wiki, le pipeline e altri dati esterni al repository.

Cosa migra ELM

Dati migrati

ELM esegue attualmente la migrazione dei dati del repository seguenti da Azure DevOps Services a GitHub Enterprise Cloud con residenza dei dati:

• Sorgente Git, inclusa la cronologia completa dei commit
• Rami e tag
• Policy dei rami, migrate in set di regole per i rami di GitHub
• Metadati della richiesta pull, inclusi titoli, descrizioni, rami di origine e di destinazione e commenti
• Cronologia dell'utente per le pull request

Dati non migrati

ELM non esegue la migrazione dei dati seguenti:

• Elementi di lavoro
• Definizioni di pipeline
• Rilasci
• Wiki
• Piani di test e risultati dei test
• Azure Artifacts
• Oggetti Git LFS (futuro)

ELM esegue la migrazione delle pull request attive e di quelle di cui è stato eseguito il merge, oltre alle pull request con cronologia del branch disponibile. Le richieste pull abbandonate con rami eliminati non vengono migrate.

Come ELM usa le pipeline e cosa aspettarsi per i costi

ELM funziona in Azure Pipelines tramite un agente Linux ospitato autonomamente. Durante una migrazione, ELM utilizza due tipi di processi:

• La convalida iniziale verifica che il repository sia pronto per la migrazione. Questo processo viene eseguito una sola volta.
• Sync copia il repository su GitHub e continua a sincronizzare le modifiche fino al cutover.

L'agente Linux ospitato autonomamente deve rimanere online e disponibile per tutta la durata della migrazione.

Come ELM usa il pool di agenti

ELM riduce al minimo l'impatto sulle pipeline esistenti. Usa un solo agente alla volta, indipendentemente dal numero di agenti nel pool. Per ciascun repository, ELM accoda un processo alla volta, non esegue processi in parallelo e in genere attende da 30 a 60 minuti prima di accodare il processo successivo, in modo che le altre attività della pipeline possano continuare.

In pratica, ELM si comporta come qualsiasi altro processo della pipeline e condivide la capacità con le build attuali. Non deve assumere il controllo dell'intero pool o bloccare il lavoro non correlato.

Cosa aspettarsi per i costi

ELM stesso è libero da usare. L'unico costo potenziale deriva dalla capacità di Azure Pipelines se l'organizzazione supera la relativa indennità di lavoro parallela inclusa.

Ogni processo ELM può essere eseguito per un massimo di un'ora, ma la fatturazione di Azure Pipelines si basa sulla capacità dei processi paralleli, non sul numero di agenti o di minuti utilizzati. Poiché ELM si limita a un processo simultaneo, molti clienti possono eseguire migrazioni all'interno della capacità esistente senza costi aggiuntivi. Se si supera la capacità inclusa, potrebbe essere necessario acquistare processi paralleli aggiuntivi. Azure Pipelines include anche minuti gratuiti per i progetti privati, quindi i costi aggiunti si applicano in genere solo dopo l'esaurimento del livello gratuito.

Flusso di lavoro della migrazione

A livello generale, una migrazione ELM segue questi passaggi. Ogni passaggio è collegato a istruzioni dettagliate.

1. Informazioni su Enterprise Live Migrations. Esaminare questa panoramica per comprendere le operazioni di ELM, le operazioni di migrazione e le modalità di adattamento al piano di migrazione. Decidere se il team prevede di spostare completamente i flussi di lavoro di sviluppo in GitHub o continuare a usare Azure DevOps e GitHub insieme in un modello ibrido. Se si sceglie un modello ibrido, ELM può contribuire a ridurre la configurazione post-migrazione ricollegando Azure Pipelines al repository di GitHub migrato e creando la connessione Azure Boards.
2. Completare i prerequisiti. Verificare l'accesso, gli strumenti e l'autenticazione e raccogliere gli ID necessari per eseguire i comandi di migrazione. Per altre informazioni, vedere Completare i prerequisiti.
3. Avviare la migrazione. Eseguire l'autenticazione in Azure DevOps, impostare le impostazioni predefinite e usare l'interfaccia della riga di comando ELM per avviare la sincronizzazione iniziale. Per altre informazioni, vedere Avviare la migrazione.
4. Monitorare la migrazione. Controllare la sincronizzazione iniziale e le sincronizzazioni incrementali successive. Per altre informazioni, vedere Monitorare la migrazione.
5. Passa a GitHub. Pianifica il passaggio non appena sei pronto. È necessario completare il cutover entro 21 giorni dall'avvio della migrazione completa (all'inizio della sincronizzazione iniziale). Per altre informazioni, vedere Cutover su GitHub.
6. Completare le attività successive alla migrazione. Verificare che tutto funzioni al termine della migrazione. Per altre informazioni, vedere Completare le attività successive alla migrazione.

Controlli di convalida pre-migrazione

La tabella seguente elenca i limiti correnti dello strumento controllati durante la convalida e cosa accade se non vengono risolti.

Ruoli e responsabilità chiave

Passo successivo

Contenuti correlati

• Prerequisiti da completare
• Informazioni di riferimento per l'interfaccia della riga di comando ELM