Share via

Panoramica della migrazione

  • Articolo

Il passaggio da Azure DevOps Server ad Azure DevOps Services è un passaggio essenziale per le organizzazioni che vogliono sfruttare la collaborazione, la scalabilità e le funzionalità avanzate basate sul cloud. In questa panoramica vengono esaminate le opzioni per trasferire i dati importanti dal server Azure DevOps locale ad Azure DevOps Services basato sul cloud.

Per informazioni sulle principali differenze tra Azure DevOps Server locale e Azure DevOps Services basato sul cloud, vedere Confrontare Azure DevOps Services con Azure DevOps Server - Azure DevOps Server - Azure DevOps.

Indipendentemente dall'opzione di migrazione selezionata, è consigliabile determinare gli asset più importanti, ad esempio il codice sorgente e gli elementi di lavoro. È consigliabile considerare le dimensioni dei dati, la complessità dell'organizzazione e assicurarsi di avere tempo sufficiente per le esecuzioni dei test prima della migrazione effettiva per una transizione uniforme e corretta.

Approcci alla migrazione

È fondamentale valutare i vantaggi e i svantaggi di ogni approccio alla migrazione, in base alle motivazioni specifiche per l'adozione di Azure DevOps Services. La strategia corretta dipende dal contesto e dai requisiti univoci.

Opzioni Scenari consigliati Limiti
1: Migrazione manuale Usare per progetti più piccoli o subset di dati specifici. Non tutti i dati possono essere migrati con la massima fedeltà ed è soggetto alla limitazione. Questa migrazione non supporta la migrazione di modelli XML, quindi è necessario ricreare i modelli di processo come modelli ereditati.
2: Strumento di migrazione dei dati di Azure DevOps Usare per migrazioni di medie e grandi dimensioni con tipi di dati e strutture complesse diverse. È possibile spostare in modalità lift-and-shift solo una raccolta di Azure DevOps Server in una nuova organizzazione di Azure DevOps Services, senza modifiche. Per altre informazioni, vedere la sezione Limitazioni.
3: migrazione basata su API Offre flessibilità e personalizzazione per le organizzazioni con requisiti di migrazione univoci o esigenze di automazione. Possono verificarsi modifiche a bassa fedeltà, perdita di dati e ID. Per altre informazioni, vedere la sezione Limitazioni.

Opzione 1: Migrazione manuale

Ad esempio, quando il team di Azure DevOps in Microsoft ha scelto di passare da Azure DevOps Server ad Azure DevOps Services, è stato anche deciso di passare da controllo della versione di Team Foundation (TFVC) a Git. La migrazione richiedeva un sacco di pianificazione, ma quando è stata eseguita la migrazione, è stato creato un nuovo repository Git usando la versione "suggerimento" delle origini TFVC e la cronologia è rimasta 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.

Processo di migrazione manuale

  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 momento appropriato 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. È possibile farlo nei modi seguenti:
    • Modificare le autorizzazioni a livello di progetto: impostare le autorizzazioni per tutti gli utenti o i gruppi in sola lettura a livello di progetto, che è possibile eseguire modificando i ruoli di sicurezza nelle impostazioni di Project.
    • Modificare le impostazioni del repository: per ogni repository è possibile modificare le impostazioni in modo da renderle di sola lettura, che comporta la modifica delle autorizzazioni per ogni utente o gruppo in modo da consentire solo le azioni di lettura.
    • Usare i gruppi di sicurezza predefiniti: usare i gruppi di sicurezza predefiniti per gestire le autorizzazioni in modo più efficiente. È possibile assegnare utenti a gruppi come "Lettori" per fornire l'accesso in sola lettura.
    • Modifiche alle autorizzazioni di scripting: se sono presenti molti progetti o repository, potrebbe essere necessario crearne uno script. È possibile usare l'estensione DevOps dell'interfaccia della riga di comando di Azure per elencare tutte le autorizzazioni e aggiornarle in base alle esigenze.
    • Disabilitare la funzionalità del repository: disabilita l'accesso al repository, incluse le compilazioni e le richieste pull, ma mantiene il repository individuabile con un avviso. Passare a Impostazioni progetto>Repository> il repository e accanto a Disabilita repository, spostare l'interruttore su Sì.

Opzione 2: Strumento di migrazione di Azure DevOps

Azure DevOps Data Migration Tool è un set di utilità fornite da Microsoft per facilitare la migrazione dei dati da Azure DevOps Server ad Azure DevOps Services. Questi strumenti offrono un approccio semplificato per eseguire la migrazione di vari artefatti, tra cui codice sorgente, elementi di lavoro, test case e altri dati correlati al progetto.

Prima di avviare il processo di migrazione, gli strumenti possono eseguire un'analisi di premigration per valutare l'idoneità dell'ambiente di origine e identificare potenziali problemi o dipendenze che potrebbero influire sulla migrazione. Valutare l'idoneità, in modo da poter pianificare e mitigare le potenziali sfide in anticipo.

Limitazioni dello strumento di migrazione

Lo strumento consente di spostare in modalità lift-and-shift una raccolta di Azure DevOps Server in una nuova organizzazione del servizio Azure DevOps, senza apportare modifiche per i motivi seguenti:

  • Integrità e coerenza dei dati:
    • Quando si esegue la migrazione dei dati, è fondamentale mantenere l'integrità e la coerenza. La possibilità di apportare modifiche durante la migrazione potrebbe causare danneggiamento o incoerenze dei dati.
    • Lo strumento garantisce che i dati rimangano intatti durante il processo di trasferimento, riducendo al minimo il rischio di errori.
  • Conservazione dei dati di origine:
    • Lo strumento di migrazione mira a replicare fedelmente i dati di origine nell'ambiente di destinazione.
    • Le modifiche possono modificare i dati originali, causando potenzialmente discrepanze tra i dati migrati e i dati di origine.
  • Comportamento prevedibile:
    • Limitando le modifiche, lo strumento garantisce un comportamento prevedibile durante la migrazione.
    • Gli utenti possono basarsi su risultati coerenti senza modifiche impreviste.
  • Stato attivo della migrazione, non trasformazione:
    • Lo scopo principale dello strumento di migrazione è spostare i dati da una posizione a un'altra.
    • La trasformazione dei dati, ad esempio la modifica dei valori, viene in genere gestita separatamente dopo la migrazione.

È possibile eliminare i dati che non sono necessari prima o dopo la migrazione.

Processo dello strumento di migrazione

  1. Completare i prerequisiti, ad esempio l'aggiornamento di Azure DevOps Server a una delle due versioni più recenti.
  2. Convalidare ogni raccolta da spostare in Azure DevOps Services.
  3. Generare file di migrazione.
  4. Preparare tutti gli elementi per l'esecuzione della migrazione.
  5. Eseguire un'esecuzione di test.
  6. Eseguire una migrazione.
  7. Verificare che gli utenti e i dati siano stati migrati e che la raccolta funzioni come previsto.

Opzione 3: migrazione basata su API

Se per qualche motivo non è possibile usare lo strumento di migrazione dei dati ma si vuole comunque una migrazione più fedele rispetto all'opzione 2, è possibile scegliere tra vari strumenti che usano API pubbliche per spostare i dati.

Limitazioni della migrazione basata su API

Le limitazioni seguenti si verificano con la migrazione basata su API:

  • Migrazione a bassa fedeltà:
    • Limitazione: gli strumenti basati su API offrono una maggiore fedeltà rispetto alla copia manuale, ma sono comunque relativamente bassi.
    • Implicazione: anche se questi strumenti offrono una certa fedeltà, non mantengono tutti gli aspetti dei dati.
      • Esempio: nessuno di essi mantiene le date originali dei set di modifiche TFVC (controllo della versione di Team Foundation).
      • Molti non mantengono neanche le date modificate delle revisioni degli elementi di lavoro.
  • Modifiche alla perdita e all'ID dei dati:
    • Limitazione: durante la migrazione, gli strumenti replay dell'elemento di lavoro cambiano, i set di modifiche tfvc, i feed dei pacchetti e gli artefatti della pipeline.
    • Implicazione: questo processo potrebbe causare la perdita di dati, generare nuovi ID e modificare le date di creazione, modifica e chiusura.
      • Esempio: il contesto cronologico associato a date specifiche potrebbe andare perso, che influisce sulla creazione di report e sulla tracciabilità.

Processo di migrazione basato su API

In generale, è consigliabile questo approccio solo se maggiore fedeltà oltre a una copia manuale è fondamentale. Se si decide di adottare questo approccio, è possibile prendere in considerazione l'assunzione di un consulente con uno o più strumenti e di eseguire una migrazione di test prima della migrazione finale.

Molte organizzazioni necessitano di una migrazione molto altamente fedele solo per un subset del proprio 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.

Modelli di processo supportati

Azure DevOps Services supporta i modelli di processo seguenti:

Per impostazione predefinita, Hosted XML è disattivato in Azure DevOps Services. Il modello di processo XML ospitato viene attivato durante la migrazione solo se è stato personalizzato un progetto in Azure DevOps Server. Una volta che il progetto è in Xml ospitato, è possibile aggiornarlo a ereditato dopo la migrazione.

Principi chiave

Quando si esegue la migrazione ad Azure DevOps Services, tenere presenti i principi chiave e le limitazioni seguenti:

  • Azure DevOps Services è solo in inglese: Azure DevOps Server supporta più lingue, ma attualmente Azure DevOps Services supporta solo l'inglese. Se la raccolta usa la lingua non inglese o non inglese in passato e la lingua è stata convertita in inglese durante un aggiornamento, non è possibile usare lo Strumento di migrazione dei dati.
  • Ereditarietà: un progetto creato dal modello di processo Agile, Scrum o CMMI e non è mai stato personalizzato, si trova nel modello processo di ereditarietà dopo la migrazione.
  • XML ospitato: qualsiasi progetto con personalizzazioni usa il modello di processo XML ospitato.
  • Processo per progetto personalizzato: anche se Azure DevOps Services consente ai progetti di condividere un processo, lo strumento di migrazione dei dati crea un processo XML ospitato per ogni progetto team personalizzato. Ad esempio, se sono presenti 30 progetti personalizzati, sono disponibili 30 processi XML ospitati da gestire. Per personalizzare ulteriormente il processo XML ospitato per tutti i progetti, è necessario aggiornare separatamente ogni processo XML ospitato.
  • Convalida del processo: la convalida del processo dello strumento di migrazione dei dati rileva il modello di processo di destinazione per ogni progetto. Prima di poter eseguire la migrazione, è necessario correggere eventuali errori di convalida dei processi per i progetti XML ospitati. È consigliabile aggiornare il processo dei progetti in modo che corrisponda a uno dei processi (Agile, Scrum o CMMI) per sfruttare il modello di processo di ereditarietà. Altre informazioni sui tipi di convalida dei processi sono disponibili nella documentazione.

Risorse

Passaggi successivi

Introduzione allo strumento di migrazione di Azure DevOps