Opzioni di migrazione

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Quando si decide di passare da Azure DevOps Server ad Azure DevOps Services, è possibile iniziare a usare un'organizzazione vuota. Spesso, tuttavia, si avrà codice, elementi di lavoro e altri asset da spostare. Esistono molti approcci per eseguire questa operazione che variano sia nella fedeltà del trasferimento dei dati che nella complessità del processo.

Prima di eseguire la migrazione dei dati, esaminare le differenze esistenti tra Azure DevOps Server e Azure DevOps Services.

Opzione 1: copiare manualmente gli asset più importanti

Per gran parte l'opzione più semplice per lo spostamento dei dati in Azure DevOps Services consiste nel copiare manualmente gli asset più importanti e iniziare relativamente fresco. Questo può essere difficile quando ci si trova al centro di un progetto di grandi dimensioni, ma è possibile semplificare se si esegue una pianificazione avanzata e pianificare lo spostamento quando è opportuno per il team.

Ad esempio, quando il team di Azure DevOps ha scelto di passare da Azure DevOps Server ad Azure DevOps Services, si è deciso anche di passare da controllo della versione di Team Foundation (TFVC) a Git. Ciò richiedeva un po' di pianificazione, ma quando è stata effettivamente eseguita la migrazione, è stato creato un nuovo repository Git usando la versione "suggerimento" delle origini vc tf e la cronologia è stata lasciata indietro in Azure DevOps Server. Abbiamo anche spostato gli elementi di lavoro attivi e abbiamo lasciato indietro tutti i nostri vecchi bug, le storie utente completate e le attività e così via.

Ecco il processo generale:

  1. Identificare gli asset più importanti di cui è necessario eseguire la migrazione, in genere codice sorgente, elementi di lavoro o entrambi. Altri asset in Azure DevOps Server: pipeline di compilazione, piani di test e così via, sono più difficili da migrare manualmente.
  2. Identificare un buon momento per eseguire la transizione.
  3. Preparare le organizzazioni di destinazione. Creare le organizzazioni e i progetti team necessari, effettuare il provisioning degli utenti e così via.
  4. Eseguire la migrazione dei dati.
  5. Valutare la possibilità di rendere di sola lettura le distribuzioni di Azure DevOps Server di origine.

Opzione 2: Migrazione del database ad alta fedeltà.

Il team di prodotto Azure DevOps Server e Azure DevOps Services offre uno strumento di migrazione dei dati ad alta fedeltà. Una guida alla migrazione scaricabile è disponibile all'indirizzo https://aka.ms/AzureDevOpsImport.

Guida alla migrazione

Poiché lo strumento di migrazione dei dati opera a livello di database, può offrire una migrazione molto fedele. Per spostare i dati esistenti di Azure DevOps Server in Azure DevOps Services, è consigliabile usare questa opzione.

Opzione 3: Uso di strumenti pubblici basati su API per una migrazione più fedele

Se per qualche motivo non è possibile usare lo strumento di migrazione dei dati, ma si vuole comunque una migrazione più fedele rispetto all'opzione 1, è possibile scegliere tra un'ampia gamma di strumenti che usano API pubbliche per spostare i dati. In genere questi strumenti possono offrire una migrazione più fedele rispetto a una copia manuale dei dati "mancia", ma sono ancora relativamente bassa fedeltà. Ad esempio:

  • Nessuno di essi manterrà le date dei set di modifiche di TF VC.
  • Molti di essi non manterranno le date modificate delle revisioni degli elementi di lavoro.
  • Nessuno di essi eseguirà la migrazione di tutti gli artefatti di Azure DevOps Server.

In generale, è consigliabile questo approccio solo se la fedeltà aggiuntiva oltre a una copia manuale è critica. Se decidi di adottare questo approccio, potresti prendere in considerazione l'assunzione di un consulente che ha esperienza con uno o più strumenti. È consigliabile eseguire una migrazione di test prima di eseguire la migrazione finale.

Molte organizzazioni necessitano di una migrazione ad alta fedeltà solo per un sottoinsieme del lavoro. Un nuovo lavoro potrebbe essere avviato direttamente in Azure DevOps Services. Altre operazioni, con requisiti di fedeltà meno rigorosi, possono essere migrate usando uno degli altri approcci. Sarà necessario valutare i vantaggi e i svantaggi dei vari approcci rispetto alle motivazioni per passare ad Azure DevOps Services e decidere per se stessi qual è la strategia giusta.