- Utilizzo di GitHub Enterprise Importer (GEI) per spostare codice, pull request e direttive di branch.
- Alternative che utilizzano GitHub Importer e i comandi Git per migrazioni più semplici.
- Strategie per convertire Azure Pipelines in GitHub Actions e gestire gli artefatti.
- Pianificazione della struttura organizzativa e gestione dei permessi post-migratori.
Migrare l'intero ecosistema di sviluppo da una piattaforma all'altra potrebbe sembrare un vero grattacapo, ma con gli strumenti giusti e un piano ben definito, in realtà è un gioco da ragazzi . Quando si decide di passare da Azure DevOps a GitHub, non si porta con sé solo il codice; si punta anche a ottimizzare la collaborazione e a sfruttare l'ecosistema di Actions.
Per evitare che il processo diventi caotico, è fondamentale comprendere che esistono percorsi diversi a seconda delle esigenze . Dalle soluzioni automatizzate per le aziende ai metodi manuali molto rapidi, l'importante è sapere quali dati si desidera conservare e quali si possono tralasciare per evitare complicazioni.
Pianificazione e analisi preliminare
Prima di eseguire qualsiasi comando, è consigliabile fermarsi a riflettere sulla tempistica. Per evitare di procedere alla cieca, raccomandiamo di creare un inventario dettagliato. È possibile utilizzare il comando `inventory-report` dell'estensione ADO2GH della CLI di GitHub , che genererà file CSV con il numero di repository e di pull request in sospeso.
Una volta ottenuti i dati, decidete se eseguire una migrazione in blocco di tutti i repository o una migrazione batch. Se avete team che non possono permettersi di interrompere il loro flusso di lavoro, scaglionare le migrazioni è l'opzione migliore. Inoltre, dovreste progettare la nuova struttura su GitHub; ricordate che ogni organizzazione ADO dovrebbe generalmente essere convertita in una singola organizzazione GitHub per mantenere l'ordine.
Metodi di migrazione del repository
Se lavori in un ambiente aziendale e devi migrare da Azure DevOps Cloud a GitHub Enterprise Cloud, lo strumento ideale è GitHub Enterprise Importer (GEI) . Questo strumento non solo trasferisce codice e cronologia, ma anche pull request, link a elementi di lavoro e direttive di branch.
Per avviarlo e farlo funzionare, devi prima installare l'estensione gh extension install github/gh-gei e autenticarsi sia con Azure DevOps che con GitHub. Se devi spostare molti repository contemporaneamente, la cosa più intelligente da fare è eseguire gh gei generate-script creare un script di migrazione automatizzato che puoi rivedere e modificare prima di pubblicarlo.
Se cerchi una soluzione più leggera e non ti dispiace perdere pull request o direttive, l' importatore GitHub basato sul web è la soluzione più rapida. Ti basta creare un nuovo repository, selezionare l'opzione di importazione e incollare l'URL del clone di Azure DevOps. È l'opzione più semplice per chi non vuole usare il terminale.
Per i puristi delle console, c'è sempre il metodo di clonazione speculareFare un git clone --bare dal repository sorgente e poi un git push --mirror Per migrare alla nuova destinazione su GitHub, è necessario assicurarsi che tutta la cronologia e i rami vengano trasferiti intatti, sebbene senza i metadati della piattaforma.
Limitazioni e colli di bottiglia
Non è tutto rose e fiori, e ci sono dei limiti di cui è bene essere consapevoli per evitare sorprese. Ad esempio, GitHub non accetta commit singoli di dimensioni superiori a 2 GiB . Se hai un commit enorme, dovrai dividerlo in blocchi più piccoli prima di tentare la migrazione.
Per quanto riguarda le dimensioni dei file, il limite standard è di 100 MiB, sebbene aumenti a 400 MiB durante l'importazione. Se si dispone di file molto grandi, la soluzione è implementare Git LFS . Si noti che, sebbene GEI migri i repository che utilizzano LFS, gli oggetti LFS stessi non vengono spostati automaticamente ; sarà necessario migrarli manualmente in una fase successiva.
Potresti anche riscontrare problemi con le regole della tua organizzazione . Se hai regole rigide relative agli indirizzi email degli autori dei commit e i dati ADO non corrispondono, la migrazione fallirà. Per evitare sorprese in produzione, è altamente consigliato eseguire un test in un ambiente sandbox.
Migrazione di pipeline, wiki e artefatti
Il passaggio da Azure Pipelines a GitHub Actions non è un semplice clic, ma Actions GitHub Importer Automatizza gran parte della conversione. Innanzitutto, è necessario eseguire un audit con gh actions-importer audit azure-devops e quindi convertire ogni pipeline specifica. Tieni presente che concetti come i gruppi di agenti Azure si traducono in etichette esecutore su GitHub.
Per i wiki, il processo è più manuale ma comunque semplice. Dato che i wiki di Azure DevOps sono repository Git, è possibile clonarli localmente e poi caricarli sul wiki di GitHub . Se la documentazione è molto estesa, si consiglia di utilizzare GitHub Pages con generatori come Jekyll per un risultato più professionale.
Per quanto riguarda gli artefatti, GitHub Packages rappresenta un'alternativa a NuGet, npm e Maven. Il flusso di lavoro prevede il download dei pacchetti esistenti da Azure Artifacts e la loro ripubblicazione nel nuovo registro GitHub, nonché la riconfigurazione dell'origine dei pacchetti nel proprio ambiente di sviluppo.
Gestione degli elementi di lavoro e post-migrazione
È qui che le cose si complicano, poiché non esiste uno strumento ufficiale per migrare Azure Boards a GitHub Issues. Dovrai affidarti a strumenti della community, esportazioni CSV manuali o creare script personalizzati che utilizzino le API REST di entrambe le piattaforme per mantenere la tracciabilità delle tue attività.
Per quanto riguarda le autorizzazioni, GEI non le migra automaticamente perché i modelli di accesso sono diversi. Tuttavia, crea due team per progetto: uno per i manutentori e uno per gli amministratori . Dovrai solo aggiungere gli utenti a questi team o collegarli ai gruppi di Azure Active Directory.
Per completare il processo, non dimenticare di verificare che i flussi di lavoro CI/CD funzionino correttamente, che la wiki sia leggibile e che tutti i link esterni puntino ora a GitHub. È consigliabile aggiungere una notifica al file README del vecchio progetto in Azure DevOps, in modo che nessuno si perda e tutti sappiano che il codice ora si trova nella sua nuova posizione.
Il passaggio dell'infrastruttura Azure DevOps a GitHub comporta il coordinamento della migrazione del codice, della conversione dei flussi di lavoro e del trasferimento della documentazione e dei pacchetti, avvalendosi di strumenti come GEI o la CLI di GitHub per ridurre al minimo gli errori e garantire che la cronologia di sviluppo rimanga intatta, adattando al contempo autorizzazioni e organizzazione al modello GitHub.