Eseguire test di migrazione

Il team è ora pronto per iniziare il processo di avvio di un'esecuzione di test della migrazione e infine una migrazione completa di produzione. In questa fase vengono illustrati i passaggi finali per mettere in coda una migrazione oltre ad altre attività che in genere si presentano alla fine del progetto di migrazione.

Prerequisiti

Completare la fase Prepara esecuzione del test prima di iniziare una migrazione dell'esecuzione del test.

Importante

Per garantire un processo di migrazione senza problemi, eseguire una o più importazioni di prova. Un'importazione di prova dura 45 giorni per test e convalida. Dopo 45 giorni, il periodo di prova scade e viene annullata, richiedendo di ricominciare il processo, se necessario. Maggiore è il tempo trascorso tra l'esecuzione del test e quella di produzione, più il servizio potrebbe cambiare, introducendo potenzialmente errori che una nuova esecuzione del test rileverebbe. È possibile ripetere l'importazione del test tutte le volte necessarie. Ogni importazione inizia dallo stato iniziale del database importato, perché non è possibile apportare modifiche da un'importazione a un'altra. Si notino i punti seguenti:

• Non è possibile estendere un'esecuzione di test a tempo indeterminato
• Non è possibile trasformare un'esecuzione di test in un'esecuzione di produzione
• Un'esecuzione di test viene eliminata se si verifica una delle operazioni seguenti:
  • L'esecuzione del test ha avuto un timeout
  • Viene eseguita una nuova esecuzione di test con lo stesso nome
  • Inizia un ciclo di produzione
  • L'organizzazione viene eliminata manualmente tramite le impostazioni dell'organizzazione

Convalidare una raccolta

Convalidare ogni raccolta di cui si vuole eseguire la migrazione ad Azure DevOps Services. Il passaggio di convalida esamina vari aspetti della raccolta, tra cui, ad esempio, dimensioni, regole di confronto, identità e processi.

Eseguire la convalida usando lo strumento di migrazione dei dati.

1. Scaricare lo strumento di migrazione dei dati.

2. Copiare il file ZIP in uno dei livelli dell'applicazione Azure DevOps Server.

3. Decomprimere il file . È anche possibile eseguire lo strumento da un computer diverso senza Azure DevOps Server installato, purché il computer possa connettersi al database di configurazione dell'istanza di Azure DevOps Server.

4. Aprire una finestra del prompt dei comandi nel server e immettere un comando cd per passare alla directory in cui è archiviato lo strumento di migrazione dei dati. Prenditi pochi momenti per esaminare il contenuto della guida dello strumento.

   a. Per visualizzare la guida e le linee guida di livello superiore, eseguire il comando seguente.

    Migrator /help
   

   b. Visualizza il testo di aiuto per il comando.

    Migrator validate /help 
   

5. La prima volta che si convalida una raccolta, il comando deve avere la struttura semplice seguente.

    Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}
   

   Dove {name} si inserisce il nome del tenant di Microsoft Entra, ad esempio, per eseguire contro DefaultCollection e il tenant fabrikam, il comando è il seguente.

    Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
   

6. Per eseguire lo strumento da un computer diverso da Azure DevOps Server, è necessario il parametro /connectionString . Il parametro della stringa di connessione indica il database di configurazione del server Azure DevOps. Ad esempio, se il comando convalidato viene eseguito dall'azienda Fabrikam, il comando sarà simile al seguente.

    Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
   

   Importante

   Lo strumento di migrazione dei dati non modifica dati o strutture nella raccolta. Legge la raccolta solo per identificare i problemi.

7. Al termine della convalida, è possibile visualizzare i file di log e i risultati.

   

   Durante la convalida, viene visualizzato un avviso se alcune delle tue pipeline contengono regole di conservazione per singola pipeline. Azure DevOps Services usa un modello di conservazione basato su progetto e non supporta i criteri di conservazione per pipeline. Se si procede con la migrazione, i criteri non vengono trasportati alla versione ospitata. Si applicano invece i criteri di conservazione a livello di progetto predefiniti. Conservare le versioni importanti per evitare la loro perdita.

Dopo aver superato tutte le convalide, è possibile passare al passaggio successivo del processo di migrazione. Se lo strumento di migrazione dei dati contrassegna eventuali errori, correggerli prima di procedere. Per indicazioni sulla correzione degli errori di convalida, vedere Risolvere i problemi di migrazione e errori di migrazione.

Importare file di log

Quando si apre la directory di log, è possibile notare diversi file di registrazione.

Il file di log principale è denominato DataMigrationTool.log. Contiene informazioni dettagliate su tutto ciò che è stato eseguito. Per semplificare l'attenzione su aree specifiche, viene generato un log per ogni operazione di convalida principale.

Ad esempio, se TfsMigrator segnala un errore nel passaggio "Convalida dei processi di progetto", è possibile aprire il file di ProjectProcessMap.log per visualizzare tutti gli elementi eseguiti per tale passaggio invece di dover scorrere l'intero log.

Esaminare il file TryMatchOobProcesses.log solo se si sta tentando di eseguire la migrazione dei processi di progetto per usare il modello ereditato. Se non si vuole usare il modello ereditato, è possibile ignorare questi errori, perché non impediscono l'importazione in Azure DevOps Services. Per altre informazioni, vedere La fase di convalida della migrazione.

Generare file di migrazione

Lo strumento di migrazione dei dati ha convalidato la raccolta e restituisce un risultato di "Tutte le convalide della raccolta passate". Prima di portare una raccolta offline per eseguirne la migrazione, generare i file di migrazione. Quando si esegue il prepare comando , si generano due file di migrazione:

• IdentityMapLog.csv: delinea la mappa delle identità tra Active Directory e Microsoft Entra ID.
• migration.json: richiede di compilare la specifica di migrazione da usare per avviare la migrazione.

Comando di Preparazione

Il prepare comando consente di generare i file di migrazione necessari. Essenzialmente, questo comando analizza la raccolta per trovare un elenco di tutti gli utenti per popolare il log della mappa delle identità, IdentityMapLog.csv e quindi tenta di connettersi all'ID di Microsoft Entra per trovare la corrispondenza di ogni identità. A tale scopo, l'azienda deve usare lo strumento Microsoft Entra Connect (in precedenza noto come strumento di sincronizzazione directory, tool Directory Sync o tool DirSync.exe).

Se la sincronizzazione della directory è configurata, lo strumento di migrazione dei dati deve trovare le identità corrispondenti e contrassegnarle come attive. Se non sono presenti corrispondenze, l'identità viene contrassegnata come Cronologia nel log della mappa delle identità, quindi è necessario esaminare il motivo per cui l'utente non è incluso nella sincronizzazione della directory. Il file delle specifiche di migrazione, migration.json, deve essere popolato prima della migrazione.

A differenza del validate comando, preparerichiede una connessione Internet, perché deve connettersi all'ID Microsoft Entra per popolare il file di log della mappa delle identità. Se l'istanza di Azure DevOps Server non ha accesso a Internet, eseguire lo strumento da un computer che esegue questa operazione. Finché è possibile trovare un computer con una connessione Intranet all'istanza di Azure DevOps Server e una connessione Internet, è possibile eseguire questo comando. Per assistenza con il prepare comando, eseguire il comando seguente:

Migrator prepare /help

Nella documentazione della Guida sono incluse istruzioni ed esempi per l'esecuzione del Migrator comando dall'istanza di Azure DevOps Server stessa e da un computer remoto. Se si esegue il comando da uno dei livelli di applicazione dell'istanza di Azure DevOps Server, il comando deve avere la struttura seguente:

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

Il parametro connectionString è un puntatore al database di configurazione dell'istanza di Azure DevOps Server. Ad esempio, se la società Fabrikam esegue il prepare comando , il comando sarà simile all'esempio seguente:

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

Quando lo strumento di migrazione dei dati esegue il prepare comando , esegue una convalida completa per assicurarsi che non siano state apportate modifiche alla raccolta dopo l'ultima convalida completa. Se vengono rilevati nuovi problemi, non vengono generati file di migrazione.

Poco dopo l'avvio del comando, viene visualizzata una finestra di accesso di Microsoft Entra. Accedere con un'identità appartenente al dominio tenant, specificato nel comando . Assicurarsi che il tenant di Microsoft Entra specificato sia quello con cui si vuole eseguire il backup dell'organizzazione futura. Nell'esempio di Fabrikam, un utente immette credenziali simili allo screenshot di esempio seguente.

Importante

Non usare un tenant Microsoft Entra di test per una migrazione di prova né un tenant Microsoft Entra di produzione per una migrazione in produzione. L'uso di un tenant di Microsoft Entra di test può causare problemi di migrazione delle identità quando si iniziano le operazioni con il tenant Microsoft Entra principale dell'organizzazione.

Quando si esegue correttamente il prepare comando nello strumento di migrazione dei dati, nella finestra dei risultati viene visualizzato un set di log e due file di migrazione. Nella directory di log trovare una cartella logs e due file:

• migration.json è il file di specifica della migrazione. Ti consigliamo di dedicare del tempo per compilarlo.
• IdentityMapLog.csv contiene il mapping generato di Active Directory alle identità di Microsoft Entra. Esaminarlo per verificarne la completezza prima di avviare una migrazione.

I due file sono descritti in modo più dettagliato nelle sezioni successive.

Il file delle specifiche di migrazione

La specifica di migrazione, migration.json, è un file JSON che fornisce le impostazioni di migrazione. Include il nome dell'organizzazione desiderato, le informazioni sull'account di archiviazione e altre informazioni. La maggior parte dei campi viene popolata automaticamente e alcuni campi richiedono l'input prima di tentare una migrazione.

Screenshot di un file di specifica di migrazione appena generato.

I campi visualizzati del file migration.json e le azioni necessarie sono descritti nella tabella seguente:

Campo	Descrizione	Azione richiesta
Origine	Informazioni sul percorso e sui nomi dei file di dati di origine usati per la migrazione.	Nessuna azione richiesta. Esaminare le informazioni sulle azioni da seguire nel sottocampo.
Posizione	Chiave di accesso con firma condivisa per l'account di archiviazione Azure che ospita il pacchetto dell'applicazione di livello dati (DACPAC).	Nessuna azione richiesta. Questo campo è trattato in un passaggio successivo.
File	Nomi dei file contenenti i dati di migrazione.	Nessuna azione richiesta. Esaminare le informazioni sulle azioni da seguire nel sottocampo.
DACPAC	File DACPAC che crea un pacchetto del database di raccolta da usare per inserire i dati durante la migrazione.	Nessuna azione richiesta. In un passaggio successivo si crea questo file usando la raccolta e quindi la si carica in un account di archiviazione di Azure. Aggiornare il file in base al nome usato quando viene generato più avanti in questo processo.
Destinazione	Proprietà della nuova organizzazione verso cui migrare.	Nessuna azione richiesta. Esaminare le informazioni sulle azioni da seguire nel sottocampo.
Nome	Nome dell'organizzazione da creare durante la migrazione.	Specificare un nome. Il nome può essere modificato rapidamente in un secondo momento dopo il completamento della migrazione. NOTA: non creare un'organizzazione con questo nome prima di eseguire la migrazione. L'organizzazione viene creata come parte del processo di migrazione.
TipoImportazione	Tipo di migrazione da eseguire.	Nessuna azione richiesta. In un passaggio successivo selezionare il tipo di migrazione da eseguire.
Dati di convalida	Informazioni necessarie per favorire l'esperienza di migrazione.	Lo strumento di migrazione dei dati genera la sezione "ValidationData". Contiene informazioni utili per favorire l'esperienza di migrazione. Non* modificare i valori in questa sezione o l'avvio della migrazione potrebbe non riuscire.

Dopo aver completato il processo precedente, dovrebbe essere presente un file simile all'esempio seguente.

Nell'immagine precedente, il pianificatore della migrazione di Fabrikam ha aggiunto il nome dell'organizzazione fabrikam-import e ha selezionato Stati Uniti Centrali (CUS) come posizione geografica per la migrazione. Altri valori sono stati lasciati così per essere modificati poco prima che il pianificatore portasse offline la raccolta per la migrazione.

Nota

Le importazioni di esecuzione dei test hanno un '-dryrun' aggiunto automaticamente alla fine del nome dell'organizzazione, che è possibile modificare dopo la migrazione.

Aree di Azure supportate per la migrazione

Azure DevOps Services è disponibile in diverse località geografiche di Azure. Tuttavia, non tutte le posizioni in cui Azure DevOps Services è disponibile sono supportate per la migrazione. La tabella seguente elenca le località geografiche di Azure che è possibile selezionare per la migrazione. È incluso anche il valore che è necessario inserire nel file delle specifiche di migrazione per specificare tale area geografica per la migrazione.

Posizione geografica	Località geografica di Azure	Valore della specifica di importazione
Stati Uniti	Stati Uniti centrale	CUS
Europa	Europa occidentale	WEU
Regno Unito	Regno Unito meridionale	UKS
Australia	Australia orientale	EAU
America del Sud	Brasile meridionale	SBR
Asia/Pacifico	India meridionale	MA
Asia/Pacifico	Asia sud-orientale (Singapore)	SEA
Canada	Canada centrale	CC

Log della mappa delle identità

Il log della mappa delle identità è di uguale importanza ai dati effettivi che vengono migrati ad Azure DevOps Services. Durante la revisione del file, è importante comprendere il funzionamento della migrazione delle identità e quali potrebbero comportare i potenziali risultati. Quando si esegue la migrazione di un'identità, può diventare attiva o cronologica. Le identità attive possono accedere ad Azure DevOps Services, ma le identità cronologiche non possono.

Identità attive

Le identità attive fanno riferimento alle identità utente in Azure DevOps Services dopo la migrazione. In Azure DevOps Services queste identità vengono concesse in licenza e vengono visualizzate come utenti dell'organizzazione. Le identità sono contrassegnate come attive nella colonna Stato previsto di importazione nel file di log della mappa delle identità.

Identità storiche

Viene eseguito il mapping delle identità cronologiche come tale nella colonna Stato di importazione previsto nel file di log della mappa delle identità. Anche le identità senza una voce di riga nel file diventano storiche. Un esempio di identità senza una voce di riga potrebbe essere un dipendente che non lavora più nell'azienda.

A differenza delle identità attive, le identità cronologiche:

• Non si ha accesso a un'organizzazione dopo la migrazione.
• Non ci sono licenze.
• Non apparire come utenti dell'organizzazione. Tutto ciò che persiste è la nozione del nome dell'identità nell'organizzazione, in modo che la sua cronologia possa essere consultata in un secondo momento. È consigliabile usare le identità cronologiche per gli utenti che non lavorano più nella società o che non necessitano di ulteriore accesso all'organizzazione.

Nota

Dopo l'importazione di un'identità come storica, non può diventare attiva.

Comprendere il file di log della mappa delle identità

Il file di log della mappa delle identità è simile all'esempio illustrato di seguito:

Le colonne nel file di log delle mappe delle identità sono descritte nella tabella seguente:

L'utente e l'amministratore di Microsoft Entra devono analizzare gli utenti contrassegnati come No Match Found (Controlla sincronizzazione ID Microsoft Entra) per capire perché non fanno parte della sincronizzazione Microsoft Entra Connect.

Colonna	Descrizione
Active Directory: Utente (Azure DevOps Server)	Nome visualizzato amichevole usato dall'identità in Azure DevOps Server. Questo nome facilita l'identificazione dell'utente a cui fa riferimento la linea nella mappa.
Active Directory: Identificatore di sicurezza	Identificatore univoco per l'identità Active Directory locale in Azure DevOps Server. Questa colonna viene utilizzata per identificare gli utenti nella raccolta.
Microsoft Entra ID: Utente atteso per l'importazione (Azure DevOps Services)	L'indirizzo di accesso previsto dell'utente presto attivo corrispondente o Nessuna corrispondenza trovata (Controlla sincronizzazione Microsoft Entra ID), che indica che l'identità è stata persa durante la sincronizzazione di Microsoft Entra ID e importata come storico.
Stato importazione previsto	Stato di migrazione utente previsto: Attivo se esiste una corrispondenza tra Active Directory e Microsoft Entra ID oppure Cronologia se non esiste una corrispondenza.
Data di convalida	Ultima convalida del log della mappa delle identità.

Durante la lettura del file, si noti se il valore nella colonna Stato importazione prevista è Attivo o Cronologico. Active indica che l'identità in questa riga viene mappata correttamente e diventa attiva durante la migrazione. Cronologico significa che le identità diventano cronologiche durante la migrazione. È importante esaminare il file di mapping generato per completezza e correttezza.

Importante

La migrazione non riesce se si verificano modifiche importanti alla sincronizzazione dell'ID di sicurezza di Microsoft Entra Connect tra i tentativi di migrazione. È possibile aggiungere nuovi utenti tra esecuzioni di test e apportare correzioni per assicurarsi che le identità cronologiche importate in precedenza diventino attive. Tuttavia, non è possibile modificare un utente esistente importato in precedenza come attivo. Procedendo in questo modo, la migrazione fallisce. Un esempio di modifica è completare una migrazione di una prova di esecuzione, eliminare un'identità attivamente importata da Microsoft Entra ID, ricreare l'utente in Microsoft Entra ID e poi tentare un'altra migrazione. In questo caso, si tenta una migrazione attiva delle identità tra Active Directory e l'identità Microsoft Entra appena creata, e ciò causa un errore di migrazione.

1. Esaminare le identità correttamente corrispondenti. Sono presenti tutte le identità previste? Gli utenti sono mappati all'identità corretta di Microsoft Entra?

   Se è necessario aggiornare i valori, contattare l'amministratore di Microsoft Entra per assicurarsi che l'identità di Active Directory locale sia sincronizzata con l'ID Microsoft Entra e configurata correttamente. Per altre informazioni, vedere Integrare le identità locali con Microsoft Entra ID.

2. Esaminare quindi le identità etichettate come cronologiche. Questa etichettatura implica che non è stato possibile trovare un'identità Microsoft Entra corrispondente, per uno dei motivi seguenti:

   • L'identità non è configurata per la sincronizzazione tra Active Directory locale e Microsoft Entra ID.
   • L'identità non è ancora stata registrata nell'ID Microsoft Entra (ad esempio, c'è un nuovo dipendente).
   • L'identità non esiste nell'istanza di Microsoft Entra.
   • L'utente proprietario di tale identità non funziona più all'interno dell'azienda.

Per risolvere i primi tre motivi, configurare l'identità Active Directory locale prevista per la sincronizzazione con Microsoft Entra ID. Per altre informazioni, vedere Integrare le identità locali con Microsoft Entra ID. È necessario configurare ed eseguire Microsoft Entra Connect per importare le identità come attive in Azure DevOps Services.

È possibile ignorare il quarto motivo, perché i dipendenti che non lavorano più nella società devono essere importati come storici.

Identità storiche (piccoli team)

Nota

Solo i team di piccole dimensioni devono considerare la strategia di migrazione delle identità proposta in questa sezione.

Se Microsoft Entra Connect non è configurato, tutti gli utenti nel file di log della mappa delle identità vengono contrassegnati come cronologici. L'esecuzione di una migrazione in questo modo comporta l'importazione di tutti gli utenti come cronologici. È consigliabile configurare Microsoft Entra Connect per assicurarsi che gli utenti vengano importati come attivi.

L'esecuzione di una migrazione con tutte le identità cronologiche ha conseguenze che devono essere considerate attentamente. Solo i team con pochi utenti e per i quali il costo di configurazione di Microsoft Entra Connect è considerato troppo elevato dovrebbero prendere in considerazione.

Per eseguire la migrazione di tutte le identità come storiche, seguire i passaggi descritti nelle sezioni successive. Quando si accoda una migrazione, l'identità usata per accodare la migrazione viene integrata nell'organizzazione in qualità di proprietario dell'organizzazione. Tutti gli altri utenti vengono importati come storici. I proprietari dell'organizzazione possono quindi aggiungere di nuovo gli utenti usando l'identità Microsoft Entra. Gli utenti aggiunti vengono considerati come nuovi utenti. Non possiedono alcuna parte della loro storia e non c'è modo di riassociare questa storia all'identità di Microsoft Entra. Tuttavia, gli utenti possono comunque cercare la cronologia prima della migrazione cercando \<domain>\<Active Directory username>.

Lo strumento di migrazione dei dati visualizza un avviso se rileva lo scenario completo delle identità cronologiche. Se si decide di intraprendere questo percorso di migrazione, è necessario accettare le limitazioni nello strumento.

Sottoscrizioni di Visual Studio

Lo strumento di migrazione dei dati non riesce a rilevare le sottoscrizioni di Visual Studio (in precedenza note come vantaggi MSDN) quando genera il file di log della mappa delle identità. È invece consigliabile applicare la funzionalità di aggiornamento automatico delle licenze dopo la migrazione. Se gli account aziendali degli utenti sono collegati correttamente, Azure DevOps Services applica automaticamente i vantaggi della sottoscrizione di Visual Studio al primo accesso dopo la migrazione. Non vengono addebitati costi per le licenze assegnate durante la migrazione, in modo da poter gestire in modo sicuro le sottoscrizioni in un secondo momento.

Non è necessario ripetere una migrazione di esecuzione dei test se le sottoscrizioni di Visual Studio degli utenti non vengono aggiornate automaticamente in Azure DevOps Services. Il collegamento della sottoscrizione di Visual Studio avviene al di fuori dell'ambito di una migrazione. Se l'account aziendale è collegato correttamente prima o dopo la migrazione, le licenze degli utenti vengono aggiornate automaticamente al successivo accesso. Dopo l'aggiornamento delle licenze, la volta successiva che si esegue una migrazione, gli utenti vengono aggiornati automaticamente al primo accesso all'organizzazione.

Preparare la migrazione

Ora hai tutto pronto per eseguire la migrazione di prova. Pianificare un periodo di inattività con il team per portare offline la raccolta per la migrazione. Quando si accetta un orario per eseguire la migrazione, caricare gli asset necessari generati e una copia del database in Azure. La preparazione per la migrazione è costituita dai cinque passaggi seguenti.

Passaggio 1: Portare offline la raccolta e scollegarla. Passaggio 2: Generare un file DACPAC dalla raccolta di cui si intende eseguire la migrazione.
Passaggio 3: Caricare il file DACPAC e i file di migrazione in un account di archiviazione di Azure.
Passaggio 4: Generare un token SAS per accedere all'account di archiviazione.
Passaggio 5: Completare la specifica della migrazione.

Nota

Prima di eseguire una migrazione di produzione, è consigliabile completare una migrazione di esecuzione dei test. Un'esecuzione di test consente di verificare che il processo di migrazione funzioni per la raccolta e garantisce che non siano presenti forme di dati o problemi univoci che potrebbero causare un errore di migrazione di produzione.

Passaggio 1: Scollegare la raccolta

La rimozione della raccolta è un passaggio fondamentale del processo di migrazione. I dati di identità per la raccolta si trovano nel database di configurazione dell'istanza di Azure DevOps Server mentre la raccolta è collegata e online. Quando una raccolta viene disconnessa dall'istanza di Azure DevOps Server, prende una copia dei dati di identità e la confeziona con la raccolta per il trasporto. Senza questi dati, non è possibile eseguire la parte identity della migrazione.

Suggerimento

Mantenere la raccolta scollegata fino al completamento della migrazione per evitare di perdere le modifiche apportate durante la migrazione, perché queste modifiche non possono essere migrate in seguito. Dopo aver eseguito il backup della raccolta per la migrazione, è possibile ricollegarla. Tuttavia, tutte le modifiche apportate dopo il backup non sono incluse nella migrazione, il che potrebbe generare preoccupazioni sulla presenza dei dati più aggiornati. È possibile usare uno scollegamento offline per le esecuzioni di test, ma questo processo potrebbe non essere allineato alle procedure di migrazione consigliate. Esaminare la documentazione sullo scollegamento offline per comprendere appieno le implicazioni e il modo in cui si integra nella strategia di migrazione.

È importante valutare il costo della scelta di evitare qualsiasi tempo di inattività per un'esecuzione di test. Richiede l'esecuzione di backup del database di raccolta e configurazione, il ripristino in un'istanza DI SQL e la creazione di un backup scollegato. Un'analisi dei costi potrebbe dimostrare che prendere un backup scollegato impiegando solo poche ore di inattività è meglio alla fine.

Passaggio 2: Generare un file DACPAC

I DACPAC offrono un metodo rapido e relativamente semplice per lo spostamento delle raccolte in Azure DevOps Services. Tuttavia, dopo che le dimensioni di un database di raccolta superano una determinata soglia, i vantaggi dell'uso di un DACPAC iniziano a diminuire.

Nota

Se lo strumento di migrazione dei dati visualizza un avviso che indica che non è possibile usare il metodo DACPAC, è necessario eseguire la migrazione usando il metodo macchina virtuale (VM) di SQL Azure. Ignorare i passaggi da 2 a 5 in questo caso e seguire le istruzioni nella fase Preparare l'esecuzione del test, nella sezione Migrare raccolte di grandi dimensioni e quindi continuare a determinare il tipo di migrazione. Se lo strumento di migrazione dei dati non visualizza un avviso, usare il metodo DACPAC descritto in questo passaggio.

DACPAC è una funzionalità di SQL Server che consente di creare un pacchetto di database in un singolo file e distribuirlo in altre istanze di SQL Server. Un file DACPAC può anche essere ripristinato direttamente in Azure DevOps Services, in modo da poterlo usare come metodo di creazione del pacchetto per ottenere i dati della raccolta nel cloud.

Importante

• Quando si usa SqlPackage.exe, è necessario usare la versione di .NET Framework di SqlPackage.exe per preparare il file DACPAC. Il programma di installazione MSI deve essere usato per installare la versione di .NET Framework di SqlPackage.exe. Non usare l'interfaccia della riga di comando dotnet o le versioni .zip (Windows .NET 6) di SqlPackage.exe perché tali versioni potrebbero generare DACPAC incompatibili con Azure DevOps Services.
• La versione 161 di SqlPackage crittografa le connessioni di database per impostazione predefinita e potrebbe non connettersi. Se viene visualizzato un errore del processo di accesso, aggiungere ;Encrypt=False;TrustServerCertificate=True alla stringa di connessione dell'istruzione SqlPackage.

Scarica e installa SqlPackage.exe utilizzando il programma di installazione MSI più recente dalle note sulla versione di SqlPackage.

Dopo aver usato il programma di installazione MSI, SqlPackage.exe viene installato in un percorso simile a %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

Quando si genera un pacchetto di applicazione livello dati, tenere presenti due considerazioni: il disco in cui viene salvato il file DACPAC e lo spazio su disco nel computer che genera il pacchetto di applicazione livello dati. Si vuole assicurarsi di disporre di spazio su disco sufficiente per completare l'operazione.

Durante la creazione del pacchetto, SqlPackage.exe archivia temporaneamente i dati dalla raccolta nella directory temporanea nell'unità C del computer da cui si sta avviando la richiesta di creazione del pacchetto.

È possibile che il drive C sia troppo piccolo per supportare la creazione di un DACPAC. È possibile stimare la quantità di spazio necessaria cercando la tabella più grande nel database di raccolta. I DACPAC vengono creati singolarmente, una tabella alla volta. Il requisito di spazio massimo per eseguire la generazione equivale approssimativamente alle dimensioni della tabella più grande nel database della raccolta. Se si salva il file DACPAC generato nell'unità C, prendere in considerazione le dimensioni del database di raccolta come indicato nel file DataMigrationTool.log da un'esecuzione di convalida.

Il file DataMigrationTool.log fornisce un elenco delle tabelle più grandi della raccolta ogni volta che viene eseguito il comando. Per un esempio di dimensioni di tabella per una raccolta, vedere l'output seguente. Confrontare la dimensione della tabella più grande con lo spazio libero sull'unità che ospita la directory temporanea.

Importante

Prima di procedere con la generazione di un file DACPAC, assicurati che la tua raccolta sia scollegata.

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

Assicurarsi che l'unità che ospita la directory temporanea abbia almeno lo stesso spazio libero disponibile. In caso contrario, è necessario reindirizzare la directory temporanea impostando una variabile di ambiente.

SET TEMP={location on disk}

Un'altra considerazione è la posizione in cui vengono salvati i dati daCPAC. Indirizzare la posizione di salvataggio a un'unità remota distante potrebbe comportare tempi di generazione più lunghi. Se un'unità veloce, come un'unità SSD, è disponibile localmente, si consiglia di selezionare tale unità come percorso di salvataggio del DACPAC. In caso contrario, è sempre più veloce usare un disco nel computer in cui risiede il database di raccolta anziché un'unità remota.

Dopo aver identificato il percorso di destinazione per il file DACPAC e aver verificato che lo spazio sia sufficiente, è possibile generare il file DACPAC.

Aprire una finestra del prompt dei comandi e passare alla posizione del file SqlPackage.exe. Per generare il file DACPAC, sostituire i valori segnaposto con i valori necessari e quindi eseguire il comando seguente:

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

• Origine dati: L'istanza di SQL Server che ospita il database di raccolta di Azure DevOps Server.
• Catalogo iniziale: nome del database di raccolta.
• targetFile: il percorso sul disco e il nome del file DACPAC.

Nell'esempio seguente viene illustrato un comando di generazione DACPAC in esecuzione nel livello dati di Azure DevOps Server stesso:

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

L'output del comando è un file DACPAC, generato dal database di raccolta Foo denominato Foo.dacpac.

Configurare la tua raccolta per la migrazione

Dopo il ripristino del database di raccolta nella macchina virtuale di Azure, configurare un accesso SQL per consentire ad Azure DevOps Services di connettersi al database per eseguire la migrazione dei dati. Questo accesso consente solo l'accesso in lettura a un singolo database.

Per iniziare, aprire SQL Server Management Studio nella macchina virtuale e quindi aprire una nuova finestra di query sul database da importare.

Impostare il ripristino del database su semplice:

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

Creare un accesso SQL per il database e assegnare l'accesso a 'TFSEXECROLE':

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Dopo l'esempio di Fabrikam, i due comandi SQL sono simili all'esempio seguente:

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Nota

Abilitare modalità di autenticazione di SQL Server e Windows in SQL Server Management Studio sulla VM. Se non si abilita la modalità di autenticazione, la migrazione non riesce.

Configurare il file della specifica di migrazione per indirizzare la macchina virtuale

Aggiornare il file delle specifiche di migrazione per includere informazioni su come connettersi all'istanza di SQL Server. Aprire il file delle specifiche di migrazione e apportare gli aggiornamenti seguenti.

1. Rimuovere il parametro DACPAC dall'oggetto file di origine.

   La specifica di migrazione prima della modifica viene illustrata nel codice seguente.

   Screenshot della specifica di migrazione prima della modifica.

   La specifica di migrazione dopo la modifica è illustrata nel codice seguente.

   Screenshot della specifica di migrazione dopo la modifica.

2. Compila i parametri obbligatori e aggiungi l'oggetto delle proprietà seguente all'interno dell'oggetto sorgente nel file di specifica.

   "Properties":
   {
       "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
   }
   

Dopo aver applicato le modifiche, la specifica di migrazione sarà simile all'esempio seguente.

La specifica di migrazione è ora configurata per l'uso di una macchina virtuale di SQL Azure per la migrazione. Procedere con il resto dei passaggi di preparazione per la migrazione ad Azure DevOps Services. Al termine della migrazione, assicurarsi di eliminare le credenziali di accesso SQL o cambiare la password. Microsoft non mantiene le informazioni di accesso al termine della migrazione.

Passaggio 3: Caricare il file DACPAC

Nota

Se si usa il metodo della macchina virtuale di SQL Azure, è necessario fornire solo la stringa di connessione. Non è necessario caricare alcun file ed è possibile ignorare questo passaggio.

Il pacchetto DACPAC deve essere inserito in un contenitore di archiviazione Azure, che può essere un contenitore esistente o creato appositamente per la migrazione. È importante assicurarsi che il contenitore venga creato nelle posizioni geografiche corrette.

Azure DevOps Services è disponibile in più località geografiche. Quando si esegue l'importazione in queste posizioni, è fondamentale posizionare correttamente i dati per assicurarsi che la migrazione possa essere avviata correttamente. I dati devono essere inseriti nella stessa posizione geografica in cui si sta importando. L'inserimento dei dati in qualsiasi altra posizione comporta l'impossibilità di avviare la migrazione. La tabella seguente elenca le posizioni geografiche accettabili per la creazione dell'account di archiviazione e il caricamento dei dati.

Località geografica di migrazione desiderata	Posizione geografica dell'account di archiviazione
Stati Uniti centrale	Stati Uniti centrale
Europa occidentale	Europa occidentale
Regno Unito	Regno Unito meridionale
Australia orientale	Australia orientale
Brasile meridionale	Brasile meridionale
India meridionale	India meridionale
Canada centrale	Canada centrale
Asia Pacifico (Singapore)	Asia Pacifico (Singapore)

Anche se Azure DevOps Services è disponibile in più località geografiche negli Stati Uniti, solo la località di Stati Uniti centrale accetta nuovi servizi Azure DevOps. Al momento non è possibile eseguire la migrazione dei dati in altre località di Azure degli Stati Uniti.

Creare un contenitore blob dal portale di Azure. Dopo aver creato il contenitore, caricare il file DACPAC della Collection.

Al termine della migrazione, eliminare il contenitore BLOB e l'account di archiviazione associato con strumenti come AzCopy o qualsiasi altro strumento di Azure Storage Explorer.

Nota

Se il file DACPAC supera i 10 GB, è consigliabile usare AzCopy, perché supporta il caricamento multithreading per caricamenti più veloci.

Passaggio 4: Generare un token SAS

Un token di firma di accesso condiviso fornisce l'accesso delegato alle risorse in un account di archiviazione. Il token consente di concedere a Microsoft il livello di privilegio più basso necessario per accedere ai dati per l'esecuzione della migrazione.

È possibile generare token SAS usando il portale di Azure. Da un punto di vista della sicurezza, è consigliabile eseguire le attività seguenti:

1. Seleziona solo Lettura ed Elenco come autorizzazioni per il token di firma di accesso condiviso. Non sono necessarie altre autorizzazioni.
2. Impostare un'ora di scadenza non superiore a sette giorni nel futuro.
3. Limitare l'accesso solo agli indirizzi IP di Azure DevOps Services.
4. Considerare la chiave SAS come segreto. Non lasciare la chiave in una posizione non sicura perché concede l'accesso in lettura ed elenco a tutti i dati archiviati nel contenitore.

Passaggio 5: Completare la specifica di migrazione

In precedenza nel processo è stato compilato parzialmente il file delle specifiche di migrazione, noto come migration.json. A questo punto, sono disponibili informazioni sufficienti per completare tutti i campi rimanenti, ad eccezione del tipo di migrazione. Il tipo di migrazione viene illustrato più avanti nella sezione relativa alla migrazione.

Nel file di specifica migration.json, in Origine, completare i campi seguenti.

• Posizione: Incollare la chiave di firma di accesso condiviso generata dallo script e quindi copiata nel passaggio precedente.
• Dacpac: assicurarsi che il file, inclusa l'estensione del file .dacpac, abbia lo stesso nome del file DACPAC caricato nell'account di archiviazione.

Il file della specifica di migrazione finale dovrebbe essere simile all'esempio seguente.

Determinare il tipo di migrazione

Le importazioni possono essere messe in coda come test (DryRun) o come produzione (ProductionRun). Il parametro ImportType determina il tipo di migrazione:

• DryRun: detto anche esecuzione di test. Usare per scopi di test e convalida. Il sistema elimina le esecuzioni dei test dopo 45 giorni.
• ProductionRun: usare un'esecuzione di produzione quando si vuole mantenere la migrazione risultante e usare l'organizzazione a tempo pieno in Azure DevOps Services al termine della migrazione.

Suggerimento

È sempre consigliabile completare prima di tutto una migrazione di prova.

Organizzazioni di esecuzione dei test

Le organizzazioni di esecuzione dei test aiutano i team a testare la migrazione delle raccolte. Prima di poter eseguire una migrazione di produzione, è necessario eliminare tutte le organizzazioni di esecuzione di test completate. Tutte le organizzazioni di esecuzione dei test hanno un'esistenza limitata e vengono eliminate automaticamente dopo un determinato periodo di tempo. Le informazioni su quando l'organizzazione viene eliminata vengono incluse nel messaggio di posta elettronica con esito positivo che si dovrebbe ricevere al termine della migrazione. Assicurarsi di prendere nota di questa data e pianificare di conseguenza.

Le organizzazioni di test hanno 45 giorni prima di essere eliminate. Dopo il periodo di tempo specificato, l'organizzazione di esecuzione dei test viene eliminata. È possibile ripetere le importazioni di esecuzioni di test quante volte è necessario prima di eseguire una migrazione di produzione.

Eliminare le esecuzioni di test

Eliminare tutte le esecuzioni di test precedenti prima di tentare una nuova esecuzione. Quando il team è pronto per eseguire una migrazione di produzione, è necessario eliminare manualmente l'organizzazione di esecuzione dei test. Prima di poter eseguire una seconda migrazione di test o la migrazione di produzione finale, assicurarsi di eliminare tutte le organizzazioni di Azure DevOps Services precedenti create in un'esecuzione di test precedente. Per altre informazioni, vedere Eliminare l'organizzazione.

Suggerimento

Informazioni facoltative per aiutare un utente a ottenere maggior successo. Qualsiasi migrazione di prova eseguita successivamente alla prima ci si aspetta richieda più tempo dato il tempo extra necessario per ripulire le risorse dai test precedenti.

Il nome di un'organizzazione può diventare disponibile fino a un'ora dopo l'eliminazione o la ridenominazione. Per altre informazioni, vedere l'articolo Attività post-migrazione .

Se si verificano problemi di migrazione, consulta Risoluzione dei problemi di migrazione ed errori di migrazione.

Eseguire una migrazione

Il team è ora pronto per iniziare il processo di esecuzione di una migrazione. Si consiglia di iniziare con una migrazione di prova riuscita prima di tentare una migrazione in produzione. Con le importazioni di test, è possibile vedere in anticipo l'aspetto di una migrazione, identificare i potenziali problemi e acquisire esperienza prima di procedere con l'esecuzione di produzione.

Nota

• Se è necessario ripetere una migrazione completata in fase di produzione per una raccolta, ad esempio a causa di un rollback, contattare Azure DevOps Services supporto tecnico prima di accodare un'altra migrazione.

• Gli amministratori di Azure possono impedire agli utenti di creare nuove organizzazioni di Azure DevOps. Se la policy del tenant di Microsoft Entra è attivata, la migrazione non riesce a completarsi. Prima di iniziare, verificare che il criterio non sia impostato o che sia presente un'eccezione per l'utente che esegue la migrazione. Per ulteriori informazioni, consultare Limitare la creazione di organizzazioni tramite la politica del tenant di Microsoft Entra.
• Azure DevOps Services non supporta i criteri di conservazione per pipeline e non vengono trasportati nella versione ospitata.

Considerazioni sui piani di rollback

Un problema comune per i team che eseguono un'ultima esecuzione di produzione è il loro piano di rollback, nel caso in cui qualcosa vada storto con la migrazione. È consigliabile eseguire un'esecuzione di test per assicurarsi di poter testare le impostazioni di migrazione fornite allo Strumento di migrazione dei dati per Azure DevOps.

Un rollback per il ciclo di produzione finale è piuttosto semplice. Prima di accodare la migrazione, scollegare la raccolta di progetti del team da Azure DevOps Server, rendendola non disponibile per i membri del team. Se per qualsiasi motivo devi annullare l'esecuzione della produzione e riattivare il server locale per i membri del team, puoi farlo. Collegare nuovamente la raccolta di progetti del team in locale e informare il team che possono continuare a lavorare normalmente mentre il team si riorganizza per comprendere possibili errori.

È quindi possibile contattare il supporto tecnico di Azure DevOps Services per informazioni sulla causa dell'errore se non è possibile determinare la causa. Per altre informazioni, vedere l'articolo Risoluzione dei problemi. I ticket di supporto clienti possono essere aperti dalla pagina https://aka.ms/AzureDevOpsImportSupportseguente. Se il problema richiede ai tecnici del gruppo di prodotti di impegnarsi, questi casi vengono gestiti durante l'orario di ufficio normale.

Scollegare la raccolta di progetti team da Azure DevOps Server per prepararla per la migrazione.

Prima di generare un backup del database SQL, è necessario scollegare completamente la raccolta da Azure DevOps Server (non SQL) usando lo strumento di migrazione dei dati. Il processo di scollegamento in Azure DevOps Server trasferisce le informazioni sull'identità utente archiviate all'esterno del database di raccolta, rendendole portabili per lo spostamento in un nuovo server o, in questo caso, in Azure DevOps Services.

La rimozione di una raccolta può essere facilmente eseguita dalla Console di Amministrazione del Server Azure DevOps nella propria istanza di Azure DevOps Server. Per altre informazioni, vedere Spostare la raccolta di progetti, Scollegare la raccolta.

Mettere in coda la migrazione

Importante

Prima di procedere, assicurarsi che la raccolta sia stata scollegata prima di generare un file DACPAC o caricare il database della raccolta su una macchina virtuale di SQL Azure. Se non si completa questo passaggio, la migrazione non riesce. Se la migrazione non riesce, consultare Risolvere gli errori di migrazione.

Avviare una migrazione usando il comando di importazione dello Strumento di migrazione dei dati. Il comando import accetta un file di specifica della migrazione come input. Analizza il file per assicurarsi che i valori forniti siano validi e, in caso di esito positivo, accoda una migrazione ad Azure DevOps Services. Il comando di importazione richiede una connessione Internet, ma non* richiede una connessione all'istanza di Azure DevOps Server.

Per iniziare, aprire una finestra del prompt dei comandi e modificare le directory nel percorso dello strumento di migrazione dei dati. È consigliabile esaminare il testo della Guida fornito con lo strumento. Eseguire il comando seguente per visualizzare le istruzioni e la guida per il comando di importazione.

Migrator import /help

Il comando per accodare una migrazione ha la struttura seguente:

Migrator import /importFile:{location of migration specification file}

L'esempio seguente mostra un comando di importazione completato:

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

Al termine della convalida, accedere a Microsoft Entra ID con un'identità che è membro dello stesso tenant di Microsoft Entra per il quale è stato creato il file di log della mappa delle identità. L'utente connesso è il proprietario dell'organizzazione importata.

Nota

Ogni tenant di Microsoft Entra è limitato a cinque importazioni per periodo di 24 ore. Solo le importazioni che sono in coda vengono conteggiate rispetto a questo limite.

Quando il team avvia una migrazione, viene inviata una notifica via email all'utente che ha messo in coda la migrazione. Circa 5-10 minuti dopo aver accodato la migrazione, la tua squadra può andare nell'organizzazione per controllare lo stato. Al termine della migrazione, il team viene indirizzato ad accedere e viene inviata una notifica via email al proprietario dell'organizzazione.

Lo strumento di migrazione dei dati contrassegna gli errori che è necessario correggere prima della migrazione. Questo articolo descrive gli avvisi e gli errori più comuni che è possibile ricevere durante la preparazione della migrazione. Dopo aver corretto ogni errore, eseguire di nuovo il comando migrator validate per verificare la risoluzione.

Passaggi successivi

Risolvere gli errori di migrazione

Articoli correlati

• Panoramica sulla migrazione
• Attività successive alla migrazione