Processi di convalida e importazione

  • Articolo

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

Questo articolo illustra la preparazione necessaria per ottenere un'importazione in Azure DevOps Services pronta per l'esecuzione. Se si verificano errori durante il processo, vedere Risolvere gli errori di importazione e migrazione.

Prerequisiti

  • È necessario configurare un tenant di Microsoft Entra come descritto in Microsoft Entra Connessione Sync: Apportare una modifica alla configurazione predefinita. Lo strumento di migrazione dei dati configura un collegamento al tenant di Microsoft Entra quando l'organizzazione di Azure DevOps Services viene creata come parte dell'inizio del processo di importazione. Quando si sincronizza il Active Directory locale con Microsoft Entra ID, i membri del team possono usare le stesse credenziali per l'autenticazione e gli amministratori di Azure DevOps Services possono usare i gruppi di Active Directory per impostare le autorizzazioni all'interno dell'organizzazione di Azure DevOps Services. Per configurare la sincronizzazione, usare la tecnologia Microsoft Entra Connessione.
  • Prima di iniziare le attività di importazione, verificare di eseguire una versione supportata di Azure DevOps Server.
  • È consigliabile usare la guida alla migrazione dettagliata per procedere con l'importazione. La guida contiene collegamenti a documentazione tecnica, strumenti e procedure consigliate.

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

  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. Esaminare il contenuto della Guida per lo strumento.

    a. Per visualizzare le linee guida e le linee guida di primo livello, eseguire il comando seguente:

     Migrator /help

    b. Visualizzare il testo della Guida per il comando:

     Migrator validate /help

  5. La prima volta che si convalida una raccolta, è possibile mantenerla semplice. Il comando deve avere la struttura seguente:

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

    Dove {name} fornisce il nome del tenant di Microsoft Entra, ad esempio, per l'esecuzione in DefaultCollection e nel tenant fabrikam , il comando sarà simile all'esempio 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 stringa di connessione punta al database di configurazione di Azure DevOps Server. 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.

    Screenshot dei risultati e dei log di convalida nella finestra del prompt dei comandi.

    Durante la convalida, viene visualizzato un avviso se alcune pipeline contengono regole di conservazione per 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 compilazioni importanti per evitare la perdita.

Dopo aver superato tutte le convalide, è possibile passare al passaggio successivo del processo di importazione. Se lo strumento di migrazione dei dati contrassegna eventuali errori, correggerli prima di procedere. Per indicazioni sulla correzione degli errori di convalida, vedere Risolvere gli errori di importazione e 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 importare i 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.

Generare file di importazione

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 importazione. Quando si esegue il prepare comando , si generano due file di importazione:

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

Comando Prepara

Il prepare comando consente di generare i file di importazione 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 Connessione (noto in precedenza come strumento di sincronizzazione della directory, strumento di sincronizzazione directory o strumento di DirSync.exe).

Se la sincronizzazione della directory è configurata, lo strumento di migrazione dei dati deve trovare le identità corrispondenti e contrassegnarle come Attivo. 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 di specifica di importazione, import.json, deve essere popolato prima dell'importazione.

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 importazione.

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 un'importazione di test e il tenant microsoft Entra di produzione per l'esecuzione di produzione. L'uso di un tenant Di Microsoft Entra di test può causare problemi di importazione delle identità quando si avvia l'esecuzione di produzione con il tenant Microsoft Entra 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 importazione. Nella directory di log trovare una cartella logs e due file:

  • import.json è il file di specifica di importazione. Ti consigliamo di dedicare del tempo per compilarlo.
  • IdentityMapLog.csv contiene il mapping generato di Active Directory alle identità di Microsoft Entra. Verificarne la completezza prima di avviare un'importazione.

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

File di specifica dell'importazione

La specifica di importazione, import.json, è un file JSON che fornisce le impostazioni di importazione. 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 un'importazione.

Screenshot di un file di specifica di importazione appena generato.

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

Campo Descrizione Azione richiesta
Origine Informazioni sul percorso e i nomi dei file di dati di origine usati per l'importazione. Nessuna azione richiesta. Esaminare le informazioni per le azioni del sottocampo da seguire.
Ufficio Chiave di firma di accesso condiviso all'account di archiviazione di Azure che ospita il pacchetto dell'applicazione livello dati (DACPAC). Nessuna azione richiesta. Questo campo è trattato in un passaggio successivo.
File Nomi dei file contenenti dati di importazione. Nessuna azione richiesta. Esaminare le informazioni per le azioni del sottocampo da seguire.
DACPAC File DACPAC che crea un pacchetto del database di raccolta da utilizzare per inserire i dati durante l'importazione. 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 in cui eseguire l'importazione. Nessuna azione richiesta. Esaminare le informazioni per le azioni del sottocampo da seguire.
Nome Nome dell'organizzazione da creare durante l'importazione. Specificare un nome. Il nome può essere modificato rapidamente in un secondo momento dopo il completamento dell'importazione.
NOTA: non creare un'organizzazione con questo nome prima di eseguire l'importazione. L'organizzazione viene creata come parte del processo di importazione.
ImportType Tipo di importazione da eseguire. Nessuna azione richiesta. In un passaggio successivo selezionare il tipo di importazione da eseguire.
Dati di convalida Informazioni necessarie per favorire l'esperienza di importazione. Lo strumento di migrazione dei dati genera la sezione "ValidationData". Contiene informazioni che consentono di guidare l'esperienza di importazione. Non* modificare i valori in questa sezione o l'importazione potrebbe non essere avviata.

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

Screenshot di un file di specifica di importazione parzialmente completato.

Nell'immagine precedente, lo strumento di pianificazione dell'importazione di Fabrikam ha aggiunto il nome dell'organizzazione fabrikam-import e l'opzione CUS (Central Stati Uniti) come posizione geografica per l'importazione. Altri valori sono stati lasciati così come devono essere modificati poco prima che lo strumento di pianificazione abbia portato offline la raccolta per la migrazione.

Nota

Le importazioni a esecuzione secca hanno un '-dryrun' aggiunto automaticamente alla fine del nome dell'organizzazione, che è possibile modificare dopo l'importazione.

Località geografiche di Azure supportate per l'importazione

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

Posizione geografica Località geografica di Azure Valore della specifica di importazione
Stati Uniti Stati Uniti centrale CUS
Europa Europa occidentale UEO
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 di cui si esegue la migrazione ad Azure DevOps Services. Quando si esamina il file, è importante comprendere il funzionamento dell'importazione delle identità e quali potrebbero comportare i potenziali risultati. Quando si importa 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 l'importazione. 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 importazione prevista nel file di log della mappa delle identità.

Identità cronologiche

Viene eseguito il mapping delle identità cronologiche, ad esempio nella colonna Stato importazione prevista nel file di log della mappa delle identità. Anche le identità senza una voce di riga nel file diventano cronologiche. Un esempio di identità senza una voce di riga potrebbe essere un dipendente che non lavora più in una società.

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

  • Non avere accesso a un'organizzazione dopo la migrazione.
  • Non avere licenze.
  • Non visualizzare come utenti dell'organizzazione. Tutto ciò che persiste è la nozione del nome dell'identità nell'organizzazione, in modo che la relativa cronologia possa essere eseguita 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 cronologica, non può diventare attiva.

Informazioni sul file di log della mappa delle identità

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

Screenshot di un file di log della mappa delle identità generato dallo strumento di migrazione dei dati.

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 di Microsoft Entra Connessione.

Colonna Descrizione
Active Directory: utente (Azure DevOps Server) Nome visualizzato descrittivo usato dall'identità in Azure DevOps Server. Questo nome semplifica l'identificazione della linea nella mappa a cui fa riferimento l'utente.
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 di importazione previsto (Azure DevOps Services) L'indirizzo di accesso previsto dell'utente che corrisponde a soon-to-be-active o Nessuna corrispondenza trovata (Verifica sincronizzazione ID Microsoft Entra), che indica che l'identità non viene trovata durante la sincronizzazione microsoft Entra ID e viene importata come cronologica.
Stato importazione previsto Stato di importazione dell'utente previsto: Attivo se esiste una corrispondenza tra Active Directory e Microsoft Entra ID oppure Cronologia se non esiste una corrispondenza.
Data di convalida Ora dell'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 durante l'importazione diventa attiva. Cronologico significa che le identità diventano cronologiche durante l'importazione. È importante esaminare il file di mapping generato per completezza e correttezza.

Importante

L'importazione ha esito negativo se si verificano modifiche importanti al Connessione sincronizzazione dell'ID di sicurezza tra i tentativi di importazione. È possibile aggiungere nuovi utenti tra esecuzioni asciutte e apportare correzioni per assicurarsi che le identità cronologiche importate in precedenza diventino attive. Tuttavia, la modifica di un utente esistente importato in precedenza come attivo non è attualmente supportata. In questo modo l'importazione non riesce. Un esempio di modifica potrebbe essere il completamento di un'importazione a secco, l'eliminazione di un'identità dall'ID Microsoft Entra importato attivamente, la ricreazione di un nuovo utente nell'ID di Microsoft Entra per la stessa identità e quindi il tentativo di un'altra importazione. In questo caso, un'importazione di identità attiva tenta di eseguire un'importazione tra Active Directory e l'identità Microsoft Entra appena creata, ma causa un errore di importazione.

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

    Se è necessario modificare i valori, contattare l'amministratore di Microsoft Entra per verificare che l'identità Active Directory locale faccia parte della sincronizzazione con Microsoft Entra ID e che sia 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 viene ancora popolata 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 Connessione per importare le identità come attive in Azure DevOps Services.

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

Identità cronologiche (piccoli team)

Nota

La strategia di importazione delle identità proposta in questa sezione deve essere considerata solo da piccoli team.

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

L'esecuzione di un'importazione con tutte le identità cronologiche ha conseguenze che devono essere considerate attentamente. Solo i team con pochi utenti e per cui il costo di configurazione di Microsoft Entra Connessione viene considerato troppo elevato.

Per importare tutte le identità come cronologiche, seguire i passaggi descritti nelle sezioni successive. Quando si accoda un'importazione, l'identità usata per accodare l'importazione viene avviata nell'organizzazione come proprietario dell'organizzazione. Tutti gli altri utenti vengono importati come cronologici. 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 sono proprietari della loro storia e non c'è modo di replicare questa storia all'identità di Microsoft Entra. Tuttavia, gli utenti possono comunque cercare la cronologia di preimportazione cercando il nome <utente> di Active Directory del dominio><.

Lo strumento di migrazione dei dati visualizza un avviso se rileva lo scenario completo delle identità cronologiche. Se si decide di arrestare questo percorso di migrazione, è necessario fornire il consenso nello strumento alle limitazioni.

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 delle mappe delle identità. È invece consigliabile applicare la funzionalità di aggiornamento automatico delle licenze dopo l'importazione. 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 l'importazione. Non vengono addebitati costi per le licenze assegnate durante l'importazione, in modo da poter gestire in modo sicuro le sottoscrizioni in un secondo momento.

Non è necessario ripetere un'importazione a secco se le sottoscrizioni di Visual Studio degli utenti non vengono aggiornate automaticamente in Azure DevOps Services. Il collegamento della sottoscrizione di Visual Studio si verifica all'esterno dell'ambito di un'importazione. Se l'account aziendale è collegato correttamente prima o dopo l'importazione, le licenze degli utenti vengono aggiornate automaticamente al successivo accesso. Dopo l'aggiornamento delle licenze, alla successiva esecuzione di un'importazione, gli utenti vengono aggiornati automaticamente al primo accesso all'organizzazione.

Preparare l'importazione

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

Passaggio 1: Portare la raccolta offline e scollegarla.

Il limite di dimensioni della raccolta per il metodo DACPAC è 150 GB. Se lo strumento di migrazione dei dati visualizza un avviso che indica che non è possibile usare il metodo DACPAC, è necessario eseguire l'importazione usando il metodo macchina virtuale (VM) di SQL Azure. Ignorare i passaggi da 2 a 5 in questo caso e seguire le istruzioni fornite in Importa raccolte di grandi dimensioni e quindi continuare a determinare il tipo di importazione.

Passaggio 2: Generare un file DACPAC dalla raccolta che si intende importare.
Passaggio 3: Caricare il file DACPAC e importare i file in un account di archiviazione di Azure.
Passaggio 4: Generare un token di firma di accesso condiviso per accedere all'account di archiviazione.
Passaggio 5: Completare la specifica di importazione.

Nota

Prima di eseguire un'importazione di produzione, è consigliabile completare un'importazione di tipo dry-run. Con un'esecuzione asciutta, è possibile verificare che il processo di importazione funzioni per la raccolta e che non siano presenti forme di dati univoche che potrebbero causare un errore di importazione di produzione.

Passaggio 1: Scollegare la raccolta

La rimozione della raccolta è un passaggio fondamentale del processo di importazione. 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, accetta una copia di tali dati di identità e la inserisce nella raccolta per il trasporto. Senza questi dati, non è possibile eseguire la parte identity dell'importazione. È consigliabile mantenere la raccolta scollegata fino al completamento dell'importazione, perché non è possibile importare le modifiche apportate durante l'importazione.

Per un'importazione a secco (test), è consigliabile ricollegare la raccolta dopo aver eseguito il backup per l'importazione, in modo da non preoccuparsi di avere i dati più recenti per questo tipo di importazione. Per evitare del tutto il tempo offline, è anche possibile scegliere di usare uno scollegamento offline per le esecuzioni asciutte.

È importante valutare il costo della scelta di incorrere in tempi di inattività zero per un'esecuzione asciutta. 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 la fine del backup scollegato richiede solo poche ore di inattività.

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 pacchetto di applicazione livello dati 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 l'importazione usando il metodo macchina virtuale (VM) di SQL Azure fornito in Importa raccolte di grandi dimensioni.

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 di .zip (Windows .NET 6) di SqlPackage.exe perché tali versioni possono 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.

Scaricare e installare SqlPackage.exe usando 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 l'unità C sia troppo piccola per supportare la creazione di un pacchetto daCPAC. È possibile stimare la quantità di spazio necessaria cercando la tabella più grande nel database di raccolta. I DACPAC vengono creati 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 le dimensioni della tabella più grande con lo spazio disponibile nell'unità che ospita la directory temporanea.

Importante

Prima di procedere con la generazione di un file DACPAC, assicurarsi che la 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 spazio 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. Puntare il percorso di salvataggio a un'unità remota lontana potrebbe comportare tempi di generazione più lunghi. Se un'unità veloce, ad esempio un'unità SSD ,è disponibile in locale, è consigliabile specificare come destinazione l'unità come percorso di salvataggio 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 al percorso 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: 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 raccolta per l'importazione

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 importare i 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 'TF edizione Standard XECROLE':

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 [Foo] SET RECOVERY SIMPLE;

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

Nota

Assicurarsi di abilitare SQL Server e autenticazione di Windows modalità in SQL Server Management Studio nella macchina virtuale. Se non si abilita la modalità di autenticazione, l'importazione non riesce.

Configurare il file di specifica di importazione per la macchina virtuale di destinazione

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

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

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

    Screenshot della specifica di importazione prima della modifica.

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

    Screenshot della specifica di importazione dopo la modifica.

  2. Compilare i parametri obbligatori e aggiungere l'oggetto proprietà seguente all'interno dell'oggetto di origine 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 importazione è simile all'esempio seguente.

Screenshot della specifica di importazione che fa riferimento a una macchina virtuale di SQL Azure.

La specifica di importazione è ora configurata per l'uso di una macchina virtuale di SQL Azure per l'importazione. Procedere con il resto dei passaggi di preparazione da importare in Azure DevOps Services. Al termine dell'importazione, assicurarsi di eliminare l'accesso SQL o ruotare la password. Microsoft non mantiene le informazioni di accesso al termine dell'importazione.

Passaggio 3: Caricare il file DACPAC

Nota

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

Il pacchetto di applicazione livello dati deve essere inserito in un contenitore di archiviazione di Azure, che può essere un contenitore esistente o creato in modo specifico per il lavoro di 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 l'importazione 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 l'importazione. La tabella seguente elenca le posizioni geografiche accettabili per la creazione dell'account di archiviazione e il caricamento dei dati.

Località geografica di importazione desiderata Archiviazione posizione geografica dell'account
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 importare i dati in altre località di Azure negli Stati Uniti.

È possibile creare un contenitore BLOB dal portale di Azure. Dopo aver creato il contenitore, caricare il file DACPAC raccolta.

Al termine dell'importazione, eliminare il contenitore BLOB e l'account di archiviazione associato con strumenti come AzCopy o qualsiasi altro strumento di Azure Storage Explorer, ad esempio Archiviazione di Azure Explorer.

Nota

Se il file DACPAC è maggiore di 10 GB, è consigliabile usare AzCopy. AzCopy include il supporto per il caricamento multithreading per caricamenti più veloci.

Passaggio 4: Generare un token di firma di accesso condiviso

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 dell'importazione.

I token di firma di accesso condiviso possono essere generati usando il portale di Azure. Da un punto di vista della sicurezza, è consigliabile:

  1. Selezionare 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. Inserire il token di firma di accesso condiviso in una posizione sicura.

Passaggio 5: Completare la specifica di importazione

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

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

  • Percorso: 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 con estensione dacpac , abbia lo stesso nome del file DACPAC caricato nell'account di archiviazione.

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

Screenshot del file di specifica di importazione completato.

Limitare l'accesso solo agli indirizzi IP di Azure DevOps Services

Per altre informazioni, vedere Limitare l'accesso solo agli indirizzi IP di Azure DevOps Services.

Opzione 1: Uso dei tag del servizio

È possibile consentire facilmente le connessioni da tutte le località geografiche di Azure DevOps Services aggiungendo il tag di azuredevopsservizio ai gruppi di sicurezza di rete o ai firewall tramite il portale o a livello di codice.

Opzione 2: Uso di IpList

Usare il IpList comando per ottenere l'elenco di indirizzi IP a cui è necessario concedere l'accesso per consentire le connessioni da una specifica posizione geografica di Azure DevOps Services.

La documentazione della Guida include istruzioni ed esempi per l'esecuzione di Migrat 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 IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

È possibile aggiungere l'elenco di indirizzi IP ai gruppi di sicurezza di rete o ai firewall tramite il portale o a livello di codice.

Determinare il tipo di importazione

Le importazioni possono essere accodate come un'esecuzione asciutta o un'esecuzione di produzione. Il parametro ImportType determina il tipo di importazione:

  • DryRun: usare un'esecuzione asciutta a scopo di test. Il sistema elimina le esecuzioni asciutte dopo 21 giorni.
  • ProductionRun: usare un'esecuzione di produzione quando si vuole mantenere l'importazione risultante e usare l'organizzazione a tempo pieno in Azure DevOps Services al termine dell'importazione.

Suggerimento

È sempre consigliabile completare prima un'importazione a esecuzione asciutta.

File di specifica di importazione completato con tipo di importazione

Organizzazioni a esecuzione secca

Le importazioni in fase di esecuzione consentono ai team di testare la migrazione delle raccolte. Si prevede che le organizzazioni non rimangano in giro per sempre, ma che esistano per un breve periodo di tempo. Infatti, prima di poter eseguire una migrazione di produzione, è necessario eliminare tutte le organizzazioni completate. Tutte le organizzazioni dry-run 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 dell'importazione. Assicurarsi di prendere nota di questa data e pianificare di conseguenza.

La maggior parte delle organizzazioni a esecuzione asciutta ha 15 giorni prima dell'eliminazione. Le organizzazioni a esecuzione secca possono anche avere una scadenza di 21 giorni se più di 100 utenti hanno una licenza di base o maggiore in fase di importazione. Dopo il periodo di tempo specificato, l'organizzazione di esecuzione secca viene eliminata. È possibile ripetere le importazioni a esecuzione asciutta tutte le volte necessarie prima di eseguire una migrazione di produzione. È necessario eliminare le esecuzioni asciutte precedenti prima di tentare una nuova esecuzione. Quando il team è pronto per eseguire una migrazione di produzione, è necessario eliminare manualmente l'organizzazione a secco.

Per altre informazioni sulle attività post-importazione, vedere l'articolo post-importazione .

Se si verificano problemi di importazione, vedere Risolvere gli errori di importazione e migrazione.

Eseguire un'importazione

Il team è ora pronto per iniziare il processo di esecuzione di un'importazione. È consigliabile iniziare con un'importazione a secco completata prima di tentare un'importazione in esecuzione in produzione. Con le importazioni a secco, è possibile osservare in anticipo l'aspetto di un'importazione, identificare i potenziali problemi e acquisire esperienza prima di passare all'esecuzione di produzione.

Nota

  • Se è necessario ripetere un'importazione completata in fase di produzione per una raccolta, come in caso di rollback, contattare il supporto tecnico di Azure DevOps Services prima di accodare un'altra importazione.
  • Gli amministratori di Azure possono impedire agli utenti di creare nuove organizzazioni di Azure DevOps. Se i criteri del tenant di Microsoft Entra sono attivati, l'importazione non riesce a terminare. Prima di iniziare, verificare che il criterio non sia impostato o che sia presente un'eccezione per l'utente che esegue la migrazione. Per altre informazioni, vedere Limitare la creazione dell'organizzazione tramite i criteri del tenant di Microsoft Entra.
  • Azure DevOps Services non supporta i criteri di conservazione per pipeline e non vengono trasportati nella versione ospitata.

Considerazioni per i piani di rollback

Un problema comune per i team che eseguono un'esecuzione di produzione finale è il piano di rollback, se si verificano problemi con l'importazione. È consigliabile eseguire un'esecuzione a secco per assicurarsi di poter testare le impostazioni di importazione fornite allo strumento di migrazione dei dati per Azure DevOps.

Il rollback per l'esecuzione di produzione finale è piuttosto semplice. Prima di accodare l'importazione, scollegare la raccolta di progetti team da Azure DevOps Server, che lo rende non disponibile per i membri del team. Se per qualsiasi motivo è necessario eseguire il rollback dell'esecuzione di produzione e riportare online il server locale per i membri del team, è possibile farlo. Collegare nuovamente la raccolta di progetti team in locale e informare il team che continuano a funzionare normalmente mentre il team raggruppa per comprendere eventuali errori.

Accoda un'importazione

Importante

Prima di procedere, assicurarsi che la raccolta sia stata scollegata prima di generare un file DACPAC o caricare il database di raccolta in una macchina virtuale di SQL Azure. Se non si completa questo passaggio, l'importazione avrà esito negativo. Nel caso in cui l'importazione non riesca, vedere Risolvere gli errori di importazione e migrazione.

Avviare un'importazione usando il comando di importazione dello strumento di migrazione dei dati. Il comando import accetta un file di specifica di importazione come input. Analizza il file per assicurarsi che i valori forniti siano validi e, in caso di esito positivo, accoda un'importazione in 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 indicazioni e la Guida per il comando di importazione:

Migrator import /help

Il comando per accodare un'importazione ha la struttura seguente:

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

L'esempio seguente mostra un comando di importazione completato:

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

Al termine della convalida, viene chiesto di accedere a Microsoft Entra ID. È importante accedere con un'identità membro dello stesso tenant di Microsoft Entra rispetto al 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 vengono conteggiate in coda rispetto a questo limite.

Quando il team avvia un'importazione, viene inviata una notifica tramite posta elettronica all'utente che ha accodato l'importazione. Circa 5-10 minuti dopo aver accodato l'importazione, il team può passare all'organizzazione per verificare lo stato. Al termine dell'importazione, il team viene indirizzato all'accesso e viene inviata una notifica tramite posta elettronica al proprietario dell'organizzazione.