Preparare la migrazione dell'esecuzione dei test

Questo articolo è incentrato sulla preparazione del team e sulla generazione di file richiesta dallo Strumento di migrazione dei dati.

Prerequisiti

Completare la fase di convalida prima di iniziare a preparare la migrazione dell'esecuzione del test.

Generare le impostazioni di migrazione

Generare la specifica di migrazione e i file correlati per mettere in coda la migrazione del database di raccolta.

1. Eseguire il comando prepare dello strumento di migrazione dei dati con i parametri seguenti:

   /collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS

   • Usa l'opzione per il nome di dominio del tenant come nome del tenant di Microsoft Entra ID della sua azienda.
   • Il comando prepare richiede l'accesso a Internet. Se il Azure DevOps Server non dispone della connettività Internet, eseguire il comando da un computer diverso.
   • Il termine "area dell'organizzazione" si riferisce alla posizione in cui si prevede di eseguire la migrazione della raccolta in servizi di Azure DevOps. In precedenza è stata selezionata un'area e ne è stato registrato il codice abbreviato. Usare questo codice nel comando prepare.

2. Accedere con un utente del tenant autorizzato a leggere informazioni su tutti gli utenti nel tenant Microsoft Entra ID.

Configurare il file delle specifiche di migrazione

Il file di specifica della migrazione è un file JSON che indica allo strumento di migrazione dei dati come completare le azioni seguenti:

• Configurare l'organizzazione migrata
• Specificare i percorsi di origine
• Personalizzare la migrazione

Molti campi vengono popolati automaticamente durante il passaggio di preparazione, ma è necessario configurare i campi seguenti:

• Nome organizzazione: nome dell'organizzazione che si vuole creare per la migrazione dei dati.
• Location: Backup dei file di database e migrazione da caricare in un contenitore di archiviazione Azure. Questo campo specifica la chiave SAS usata dallo strumento di migrazione per connettersi e leggere in modo sicuro i file di origine dal container di archiviazione Azure. La creazione del contenitore di archiviazione viene illustrata più avanti nella fase 5 e la generazione di una chiave di firma di accesso condiviso viene descritta nella fase 6 prima di metterla in coda per una nuova migrazione.
• DACPAC: Un file che impacchetta il database SQL della tua raccolta.
• Tipo di migrazione: tipo di migrazione: esecuzione di test o esecuzione in produzione.

Ogni file di specifica della migrazione è destinato a una singola raccolta. Se si tenta di usare un file di specifica di migrazione generato per un'altra raccolta, la migrazione non viene avviata. È necessario preparare un'esecuzione di test per ogni raccolta di cui si vuole eseguire la migrazione e usare il file di specifiche di migrazione generato per accodare la migrazione.

Esamina il file di log della mappa delle identità

Il log della mappa delle identità è fondamentale, importante quanto i dati effettivi che si migrano. Quando si esamina il file di log, comprendere il funzionamento della migrazione delle identità e i potenziali risultati. Quando si esegue la migrazione di un'identità, può essere attiva o cronologica. Le identità attive possono accedere a servizi di Azure DevOps, mentre le identità cronologiche non possono. Il servizio decide quale tipo viene usato.

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 dell'importazione nel file di registro della mappa delle identità.

Identità storiche

Il file di log della mappa delle identità mostra le identità storiche nella colonna Stato di importazione previsto. Anche le identità senza una voce di riga nel file diventano storiche. Un esempio di identità senza una voce di registro potrebbe essere un dipendente che non lavora più in un'azienda.

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

• Non avere accesso a un'organizzazione dopo la migrazione.
• Non avere licenze.
• Non apparire come utenti nell'organizzazione. Tutto ciò che persiste è il concetto del nome di quell'identità nell'organizzazione, così che la sua storia possa essere consultata in un secondo momento. Usare le identità cronologiche per gli utenti che non lavorano più nell'azienda o che non necessitano di ulteriore accesso all'organizzazione.

Licenze

Durante la migrazione, il processo assegna automaticamente le licenze per tutti gli utenti visualizzati come attivi nella colonna Stato importazione previsto del log di mapping delle identità. Se l'assegnazione automatica delle licenze non è corretta, è possibile modificarla modificando il livello di accesso di uno o più utenti al termine della migrazione.

L'assegnazione potrebbe non essere sempre perfetta, quindi si ha fino al primo del mese successivo per riassegnare le licenze in base alle esigenze. Se entro il primo del mese successivo non si collega una sottoscrizione all'organizzazione e si acquista il numero corretto di licenze, tutte le licenze del periodo di tolleranza vengono revocate. In alternativa, se l'assegnazione automatica ha assegnato più licenze rispetto a quelle acquistate per il mese successivo, non vengono addebitati costi per le licenze aggiuntive, ma tutte le licenze non pagate vengono revocate.

Per evitare di perdere l'accesso, collegare una sottoscrizione e acquistare le licenze necessarie prima del primo mese, perché la fatturazione viene eseguita mensilmente. Per tutte le esecuzioni di test, le licenze sono gratuite finché l'organizzazione è attiva.

sottoscrizioni Azure DevOps

Le sottoscrizioni di Visual Studio non sono assegnate per impostazione predefinita per le migrazioni. Gli utenti con Sottoscrizioni di Visual Studio vengono invece aggiornati automaticamente per usare tale licenza. Se l'organizzazione aziendale di un utente è collegata correttamente, Azure DevOps Services applica automaticamente i vantaggi della sottoscrizione Visual Studio al primo accesso dopo la migrazione.

Non è necessario ripetere una migrazione di esecuzione dei test se gli utenti non vengono aggiornati automaticamente per usare la sottoscrizione Visual Studio nei servizi di Azure DevOps. Il collegamento della sottoscrizione di Visual Studio si verifica al di fuori dell'ambito di una migrazione. Se l'organizzazione aziendale viene collegata correttamente prima o dopo la migrazione, l'utente ha automaticamente la licenza aggiornata al successivo accesso. Dopo l'aggiornamento, la prossima volta che si esegue la migrazione dell'utente viene aggiornato automaticamente al momento dell'accesso iniziale all'organizzazione.

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

• Opzione 1: Usare i tag del servizio
• Opzione 2: Usare l'elenco ip

Limitare l'accesso all'account Archiviazione di Azure solo agli INDIRIZZI IP da servizi di Azure DevOps. È possibile limitare l'accesso consentendo solo le connessioni dagli INDIRIZZI IP dei servizi Azure DevOps coinvolti nel processo di migrazione del database di raccolta. Gli indirizzi IP in cui è necessario accedere all'account di archiviazione dipendono dall'area in cui si esegue la migrazione.

Opzione 1: Usare i tag del servizio

È possibile consentire facilmente le connessioni da tutte le aree di servizi Azure DevOps aggiungendo il tag del servizio azuredevops ai gruppi di sicurezza di rete o ai firewall tramite il portale o a livello di codice.

Opzione 2: Usare l'elenco ip

Usare il comando IpList per ottenere l'elenco di indirizzi IP a cui è necessario accedere per consentire le connessioni da un'area specifica di servizi di Azure DevOps.

La documentazione di supporto include istruzioni ed esempi per eseguire Migrator dall'istanza stessa di Azure DevOps Server 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.

Configurare le eccezioni del firewall IP per SQL Azure

Questa sezione illustra la configurazione delle eccezioni del firewall per SQL Azure. Per le migrazioni DACPAC, vedere Configurare firewall e reti virtuali Archiviazione di Azure.

Lo strumento di migrazione dei dati richiede di configurare gli indirizzi IP dei servizi di Azure DevOps solo sulla porta 1433.

Per concedere eccezioni per gli indirizzi IP necessari gestiti dal livello di rete Azure per la macchina virtuale di SQL Azure, completare la procedura seguente:

1. Accedere al portale di Azure.
2. Vai alla macchina virtuale SQL di Azure.
3. In Impostazioni selezionare Rete.
4. Seleziona Aggiungi regola per la porta in ingresso.
5. Selezionare Avanzate per configurare una regola di porta in ingresso per un indirizzo IP specifico.
6. Nell'elenco a discesa Origine selezionare Indirizzi IP. Immettere un indirizzo IP che richiede un'eccezione. Impostare l'intervallo di porte di destinazione su 1433. Nella casella Nome immettere un nome che descrive meglio l'eccezione che si sta configurando.

A seconda di altre regole delle porte in ingresso configurate, potrebbe essere necessario modificare la priorità predefinita per le eccezioni di Azure DevOps Services, in modo che non vengano ignorate. Ad esempio, se si dispone di una regola "nega su tutte le connessioni in ingresso a 1433" con una priorità più alta rispetto alle eccezioni di Azure DevOps Services, lo strumento di migrazione dei dati potrebbe non essere in grado di stabilire una connessione corretta al database.

Ripetere l'aggiunta di regole di porta in ingresso fino a quando tutti gli indirizzi IP necessari per i servizi Azure DevOps hanno un'eccezione. La mancanza di un indirizzo IP potrebbe impedire l'inizio della migrazione.

Eseguire la migrazione di raccolte di grandi dimensioni

Per i database che lo strumento di migrazione dei dati avvisa essere troppo grandi, è necessario un approccio diverso per l'impacchettamento dei dati per eseguire la migrazione ai servizi di Azure DevOps. Se non si è certi che la raccolta superi la soglia delle dimensioni, eseguire una convalida dello strumento di migrazione dei dati nella raccolta. La convalida consente di sapere se è necessario usare il metodo SQL Azure VM per la migrazione.

Determinare se è possibile ridurre le dimensioni della raccolta

Controllare se è possibile pulire i dati precedenti. Nel corso del tempo, le raccolte possono accumulare grandi volumi di dati. Questa crescita è una parte naturale del processo DevOps, ma potrebbe non essere necessario conservare tutti i dati. Alcuni esempi comuni di dati non più rilevanti sono aree di lavoro meno recenti e risultati di compilazione.

Lo strumento di migrazione dei dati analizza la raccolta e lo confronta con i limiti indicati in precedenza. Segnala quindi se la raccolta è idonea per il metodo di migrazione DACPAC o SQL. In generale, se la raccolta è sufficientemente piccola da adattarsi ai limiti daCPAC, è possibile usare l'approccio DACPAC più veloce e semplice. Tuttavia, se la raccolta è troppo grande, è necessario usare il metodo di migrazione SQL, che comporta la configurazione di una macchina virtuale sql Azure e la migrazione manuale del database.

Limiti di dimensione

I limiti correnti sono:

• Dimensione totale del database di 150 GB (metadati del database e blob) per DACPAC. Se si supera questo limite, è necessario eseguire il metodo di migrazione SQL.
• Dimensioni della tabella individuale da 30 GB (metadati del database + BLOB) per DACPAC. Se una singola tabella supera questo limite, è necessario eseguire il metodo di migrazione SQL.
• Dimensione dei metadati del database di 1.536 GB per il metodo di migrazione SQL. Il superamento di questo limite genera un avviso. Per avere una migrazione di successo, mantenere una dimensione inferiore a questa.
• Dimensioni dei metadati del database da 2.048 GB per il metodo di migrazione SQL. Il superamento di questo limite genera un errore, quindi non è possibile eseguire una migrazione.
• Nessun limite per le dimensioni dei BLOB per il metodo di migrazione SQL.

Quando si puliscono elementi meno recenti e non più rilevanti, è possibile rimuovere più spazio di quanto previsto. Questa pulizia può determinare se si usa il metodo di migrazione daCPAC o una macchina virtuale di SQL Azure.

Se sei sotto la soglia DACPAC, segui le istruzioni per generare un DACPAC per la migrazione. Se non è ancora possibile ottenere il database sotto la soglia DACPAC, è necessario configurare una macchina virtuale di SQL Azure per eseguire la migrazione ai servizi di Azure DevOps.

Configurare una macchina virtuale sql Azure per eseguire la migrazione ai servizi di Azure DevOps

Completare i passaggi generali seguenti per configurare una macchina virtuale (VM) di SQL Azure di cui eseguire la migrazione ai servizi di Azure DevOps.

1. Impostare una macchina virtuale di SQL Azure
2. Configurare le eccezioni del firewall IP
3. Ripristinare il database nella macchina virtuale
4. Configurare la raccolta per la migrazione
5. Configurare il file della specifica di migrazione per mirare alla macchina virtuale

Configurare una macchina virtuale di SQL Azure

È possibile configurare rapidamente una macchina virtuale sql Azure dal portale di Azure. Per altre informazioni, vedere Usare il portale di Azure per effettuare il provisioning di una macchina virtuale Windows con SQL Server.

Le prestazioni di SQL Azure macchina virtuale e dei dischi dati collegati influiscono significativamente sulle prestazioni della migrazione. Per questo motivo, completare le attività seguenti:

• Selezionare una dimensione della macchina virtuale a livello di D8s_v5_* o superiore.
• Usare i dischi gestiti.
• Consultare le prestazioni della macchina virtuale e del disco. Assicurarsi che l'infrastruttura sia configurata in modo che le operazioni di I/O al secondo (IOPS) e gli IOPS di archiviazione non limitino le prestazioni della migrazione. Ad esempio, assicurarsi che il numero di dischi dati collegati alla macchina virtuale sia sufficiente per supportare le operazioni di I/O al secondo dalla macchina virtuale.

Azure DevOps Services è disponibile in diverse aree Azure in tutto il mondo. Per assicurarsi che la migrazione venga avviata correttamente, è fondamentale posizionare i dati nell'area corretta. Se si configura la macchina virtuale sql Azure in una posizione errata, la migrazione non viene avviata.

Se si usa questo metodo di migrazione, creare la macchina virtuale in un'area supportata. Anche se Azure DevOps Services è disponibile in più aree nella Stati Uniti (Stati Uniti), solo l'area Stati Uniti centrale accetta nuove organizzazioni. Non è ora possibile eseguire la migrazione dei dati in altre aree Azure degli Stati Uniti.

Usare le configurazioni di MACCHINE virtuali di SQL Azure seguenti:

• Configurare il database temporaneo SQL per l'uso di un'unità diversa dall'unità C. Idealmente, l'unità deve avere spazio libero sufficiente, almeno equivalente alla tabella più grande del database.
• Se il database di origine è ancora superiore a 1 terabyte (TB) dopo aver ridotto le dimensioni, è necessario collegare più dischi da 1 TB e combinarli in una singola partizione per ripristinare il database nella macchina virtuale.
• Se le dimensioni dei database di raccolta sono superiori a 1 TB, è consigliabile usare un'unità SSD (unità disco rigido ssd) sia per il database temporaneo che per il database di raccolta. Prendere in considerazione anche l'uso di macchine virtuali di dimensioni maggiori con 16 CPU virtuali (vCPU) e 128 GB (gigabyte) di RAM (memoria ad accesso casuale).

Ripristinare il database nella macchina virtuale

Dopo aver impostato e configurato una macchina virtuale Azure, è necessario trasferire la copia di backup scollegata dalla tua istanza di Azure DevOps Server alla macchina virtuale Azure. Il database di raccolta deve essere ripristinato nell'istanza di SQL e non richiede l'installazione di Azure DevOps Server nella macchina virtuale.

Configura la raccolta per la migrazione

Dopo aver ripristinato il database di raccolta nella macchina virtuale Azure, configurare un'autenticazione SQL per consentire a Azure DevOps Services di connettersi al database ed eseguire la migrazione dei dati. Questa autenticazione concede l'accesso in lettura a un solo database.

1. Aprire SQL Server Management Studio nella macchina virtuale e quindi aprire una nuova finestra di query per il database di cui si vuole eseguire la migrazione.

2. Impostare il modello di recupero del database su semplice:

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

3. Creare un'autenticazione SQL per il database e assegnare tale autenticazione al TFSEXECROLE ruolo, come illustrato nell'esempio seguente.

   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>'
   

Vedere l'esempio seguente del comando SQL:

    ALTER DATABASE [Foo] 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'

Configurare il file della specifica di migrazione indirizzato alla 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 è simile al codice di esempio seguente.

   

   La specifica di migrazione dopo la modifica è simile al codice di esempio seguente.

   

2. Immettere i parametri obbligatori e aggiungere il seguente oggetto delle proprietà 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 sql Azure per la migrazione. Procedere con il resto dei passaggi di preparazione per la migrazione. Al termine della migrazione, assicurarsi di eliminare l'accesso SQL o modificare la password. Microsoft non mantiene le informazioni di accesso al termine della migrazione.

Creare un contenitore Archiviazione di Azure nel data center scelto

L'uso dello strumento di migrazione dei dati per Azure DevOps richiede la presenza di un contenitore Archiviazione di Azure nello stesso data center di Azure dell'organizzazione finale di Azure DevOps Services. Ad esempio, se si intende creare l'organizzazione di Azure DevOps Services nel data center degli Stati Centrali Uniti, creare il contenitore di Archiviazione di Azure nello stesso data center. Questa azione accelera drasticamente il tempo necessario per eseguire la migrazione del database SQL, poiché il trasferimento avviene all'interno dello stesso data center.

Per altre informazioni, vedere Creare un account di archiviazione.

Configurare la fatturazione

Quando si esegue la migrazione di un'organizzazione Azure DevOps Services, la nuova organizzazione ottiene un periodo di tolleranza. Utilizzare il tempo per completare tutti i passaggi e rivedere le assegnazioni di licenza. Se pensi di voler acquistare più piani utente, pipeline di build o distribuzione, o servizi di build ospitati, assicurati di avere una sottoscrizione di Azure pronta per il collegamento all'organizzazione migrata. Il periodo di tolleranza termina il primo giorno del mese successivo dopo il completamento della migrazione.

La fase post-migrazione ricorda quando eseguire il collegamento. Questo passaggio di preparazione riguarda più l'assicurarsi di sapere quale sottoscrizione Azure utilizzi in quel passaggio successivo. Per altre informazioni, vedere Configurare la fatturazione per l'organizzazione.

Passaggi successivi

Contenuti correlati

• Migrare a Azure DevOps Services
• Completare le attività successive alla migrazione