Migrare da Azure DevOps a GitHub
In un precedente articolo abbiamo già introdotto il concetto di GitHub e i benefici che una soluzione unica porta per fare DevOps. In quell'articolo abbiamo anche iniziato a vedere alcune delle differenze tra Azure DevOps e GitHub stesso, per capire se ci sono temi che possono essere affrontati ad armi pari oppure no.
Non si può negare che, allo stato attuale, Microsoft non stia investendo in entrambi i sistemi che sono di sua proprietà.
Da un lato abbiamo GitHub, neoacquisito, che è punto di svolta importante per Microsoft poiché oggi è il sistema più utilizzato dagli sviluppatori OSS (e non solo), è un ottimo entry-point per poter fare traction su tutti i developer e portarli ad utilizzare altri sistemi collegati, come ad esempio Azure. Proprio per questi motivi e considerando il già noto Azure DevOps (e altre alternative come GitLab, Octopus & co.) per Microsoft è importante investire tanto per portare GitHub ad essere una piattaforma più ricca e quasi in feature-parity con quello che oggi esiste nel mercato.
Dal lato opposto, Microsoft sta continuando ad investire in Azure DevOps e a "sfornare" nuove feature con i classici rollout a tre settimane.
Sorge quindi spontanea la domanda: dove dovrei investire io, come sviluppatore/azienda?
La risposta non è banale, perché dipende da mille fattori diversi. Se siamo un individuo o una organizzazione molto piccola, senza troppe pretese, ha senso iniziare a muoversi immediatamente verso GitHub. Se siamo un'azienda più strutturata, con processi complessi già definiti, dipende: un progetto nuovo potrebbe aver senso di esistere direttamente in GitHub, mentre per l'esistente potrebbe aver senso rimanere in Azure DevOps.
Chiaramente entrano in gioco anche altri fattori importanti, come la questione delle licenze e dei costi, le skill che devono sviluppare le persone e così via. Se teniamo in considerazione che Microsoft, comunque, sta mettendo molto più effort verso GitHub e che è sicuramente più utilizzato di qualunque altro sistema, indipendentemente dal fatto che siamo su Azure DevOps o vogliamo iniziare un nuovo progetto in quella piattaforma, può aver senso approfondire, tramite questo articolo, quali possono essere i costi di una eventuale migrazione a GitHub per il prossimo futuro, valutando così pro e contro e decidere in maniera coscienziosa quale strumento è più adatto per le proprie esigenze prima di fare l'investimento iniziale.
Scegliere la versione corretta
Cambiando il panorama e addentrandoci di più verso il mondo di GitHub, dobbiamo innanzitutto capire qual è la versione che è più adatta rispetto a quanto utilizzato fino ad ora in Azure DevOps.
Dando per scontato che difficilmente avremo repository pubblici su Azure DevOps, poiché di fatto rappresentano la minoranza e che considerando l'utenza media siamo più orientati all'enterprise, possiamo già escludere di creare un account utente gratuito o con licenza pro. In questo caso conviene puntare alle licenze di Team e Enterprise.
Sebbene esista una versione gratuita per le aziende che vogliono approcciare GitHub, che consente di avere 2000 minuti/mese di build pipelines, 500Mb di spazio di archiviazione per package management e tutto il sistema di tracking di gruppi/utenze, non possiamo pensare di avere un supporto base (di tipo community) per un'azienda di medie/grandi dimensioni. Per questo motivo si presume di utilizzare almeno una licenza di Team, che contiene inoltre un po' di tool per fare security e avere insights.
Per avere però il vero supporto aziendale al pari di quello che ha Azure DevOps, dobbiamo pensare di sfruttare un piano di tipo Enterprise (cloud o server, on-prem) che, oltre ad avere molti più minuti/mese e spazio di archiviazione, mi consente di avere supporto di tipo enterprise (con risposta garantita entro 8h), SLA del 99,9%, enterprise managed user e SAML SSO per chi ha, ad esempio, già degli utenti configurati con Active Directory (o meglio AAD).
Lasciamo di seguito un po' di documentazione per quanto riguarda le caratteristiche di ciascuna opzione:
Scelta con cura la versione di GitHub, possiamo creare il nuovo account e i relativi progetti come nuovi repository per quell'account, deciderne la visibilità e così via. Siamo quindi pronti a iniziare la migrazione da Azure DevOps.
Per tutte le funzionalità che vedremo e per eseguire al meglio la migrazione è consigliato, anche se non obbligatorio, essere l'amministratore dell'organizzazione di Azure DevOps. Tuttavia, se questo non è possibile, è necessario essere almeno project administrator per poter migrare i progetti a cui abbiamo interesse.
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Esportare ed analizzare le issue di GitHub con la CLI e GraphQL
Effettuare lo stream della risposta in ASP.NET Core tramite IAsyncEnumerable
Evitare la command injection in un workflow di GitHub
Miglioramenti nell'accessibilità con Angular CDK
Definire stili a livello di libreria in Angular
Eseguire un metodo asincrono dopo il set di una proprietà in Blazor 8
What's new in Azure Functions and Extensions
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Sfruttare lo streaming di una chiamata Http da Blazor
Generare token per autenicarsi sulle API di GitHub
Gestire errori funzionali tramite exception in ASP.NET Core Web API
Migrare una service connection a workload identity federation in Azure DevOps
Top Ten Articoli
- Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Utilizzare scene 3D in Windows Presentation Foundation
di Marco Leoncini - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
In evidenza
- Il meglio della settimana
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- Disabilitare automaticamente un workflow di GitHub (parte 2)
- Ottimizzazione dei block template in Angular 17
- Utilizzare il trigger SQL con le Azure Function
- Paginare i risultati con QuickGrid in Blazor
- Come EF 8 ha ottimizzato le query che usano il metodo Contains
- Evitare (o ridurre) il repo-jacking sulle GitHub Actions