Preparar para a migração do ensaio de teste

Este artigo se concentra na preparação da equipe e na geração de arquivos exigidos pela Ferramenta de Migração de Dados.

Pré-requisitos

Conclua a fase Validar antes de começar a preparar-se para a migração de execução de teste.

Gerar configurações de migração

Gera a especificação de migração e os ficheiros relacionados para colocar a migração na fila da tua base de dados de coleções.

1. Execute o comando prepare da Ferramenta de Migração de Dados com os seguintes parâmetros:

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

   • Use a opção de nome de domínio do inquilino como nome do inquilino Microsoft Entra ID da sua empresa.
   • O comando prepare requer acesso à Internet. Se o seu Azure DevOps Server não tiver ligação à internet, execute o comando a partir de outro computador.
   • O termo "região organizacional" refere-se ao local onde planeia migrar a sua coleção para Azure DevOps Services. Você selecionou previamente uma região e gravou seu código taquigráfico. Use este código no comando prepare.

2. Inicie sessão com um utilizador que pertença ao tenant e que tenha permissão para ler informações sobre todos os utilizadores no tenant do Microsoft Entra ID.

Configurar o arquivo de especificação de migração

O ficheiro de especificação de migração é um ficheiro JSON que instrui a Ferramenta de Migração de Dados como realizar as seguintes ações:

• Configurar sua organização migrada
• Especificar os locais de origem
• Personalizar a migração

Muitos dos campos são preenchidos automaticamente durante a etapa de preparação, mas você deve configurar os seguintes campos:

• Nome da organização: o nome da organização que você deseja criar para migrar seus dados.
• Location: Uma cópia de segurança da sua base de dados e dos ficheiros de migração para carregar num contentor de armazenamento Azure. Este campo especifica a chave SAS usada pela ferramenta de migração para se ligar de forma segura e ler os ficheiros fonte do contentor de armazenamento Azure. A criação do contêiner de armazenamento é abordada posteriormente na Fase 5 e a geração de uma chave SAS é abordada na Fase 6 antes de entrar na fila para uma nova migração.
• DACPAC: um arquivo que empacota o banco de dados SQL da sua coleção.
• Tipo de migração: O tipo de migração: Execução de teste ou Execução de produção.

Cada arquivo de especificação de migração destina-se a uma única coleção. Se tentares usar um ficheiro de especificação de migração gerado para outra coleção, a migração não começa. Você precisa preparar uma execução de teste para cada coleção que deseja migrar e usar o arquivo de especificação de migração gerado para enfileirar a migração.

Revise o arquivo de log do mapa de identidade

O log do mapa de identidade é crucial, tão importante quanto os dados reais que você migra. Ao examinar o arquivo de log, entenda como a migração de identidade funciona e os resultados potenciais. Quando você migra uma identidade, ela pode ser ativa ou histórica. As identidades ativas podem iniciar sessão nos Azure DevOps Services, enquanto as identidades históricas não podem. O serviço decide qual tipo será usado.

Identidades ativas

Identidades ativas referem-se às identidades dos utilizadores no Azure DevOps Services após a migração. No Azure DevOps Services, estas identidades são licenciadas e apresentadas como utilizadores na organização. As identidades são marcadas como ativas na coluna de Status de Importação Esperado no ficheiro de registo do mapa de identidade.

Identidades históricas

O ficheiro de registo do mapa de identidade mostra as identidades históricas na coluna Estado de Importação Esperado . As identidades sem uma entrada de linha no arquivo também se tornam históricas. Um exemplo de uma identidade sem uma entrada de linha pode ser um funcionário que não trabalha mais em uma empresa.

Ao contrário das identidades ativas, as identidades históricas:

• Não tenha acesso a uma organização após a migração.
• Não tem licenças.
• Não apareça como usuários na organização. Tudo o que persiste é o registo do nome dessa identidade na organização, para pesquisa futura da sua história. Use identidades históricas para utilizadores que já não trabalham na empresa ou que não necessitam de mais acesso à organização.

Licenças

Durante a migração, o processo atribui automaticamente licenças a todos os utilizadores apresentadas como ativas na coluna Estado de Importação Esperado do registo de mapeamento de identidade. Se a atribuição automática de licenças estiver incorreta, pode alterá-la editando o nível de acesso de um ou mais utilizadores após a conclusão da migração.

A atribuição pode nem sempre ser perfeita, então você tem até o primeiro dia do mês seguinte para reatribuir licenças conforme necessário. Se até ao início do mês seguinte não ligar uma subscrição à sua organização e comprar o número correto de licenças, todas as suas licenças do período de carência são revogadas. Alternativamente, se a atribuição automática atribuiu mais licenças do que compraste para o próximo mês, então não és cobrado pelas licenças extra, mas todas as licenças não pagas são revogadas.

Para evitar perder o acesso, associe uma subscrição e adquira as licenças necessárias antes do primeiro dia do mês, pois a faturação é mensal. Para todas as execuções de teste, as licenças são gratuitas enquanto a organização estiver ativa.

Subscrições do Azure DevOps

As Subscrições do Visual Studio não são atribuídas por padrão para migrações. Em vez disso, os utilizadores com Subscrições do Visual Studio são automaticamente atualizados para usar essa licença. Se a organização de trabalho de um utilizador estiver corretamente ligada, os Serviços Azure DevOps aplicam automaticamente os benefícios de subscrição do Visual Studio no primeiro início de sessão após a migração.

Não precisa de repetir uma migração de teste se os utilizadores não forem automaticamente atualizados para usar a sua subscrição do Visual Studio no Azure DevOps Services. A ligação por subscrição do Visual Studio é algo que acontece fora do âmbito de uma migração. Se a organização de trabalho for vinculada corretamente antes ou depois da migração, o usuário terá sua licença atualizada automaticamente no próximo login. Depois de serem atualizados, da próxima vez que migrar, o utilizador é automaticamente atualizado no início de sessão na organização.

Restringir o acesso apenas às IPs dos Azure DevOps Services

• Opção 1: Usar tags de serviço
• Opção 2: Usar lista de IP

Restringa o acesso à sua conta Armazenamento do Azure apenas a IPs dos Azure DevOps Services. Pode restringir o acesso permitindo apenas ligações a partir de IPs de Serviços Azure DevOps que estejam envolvidos no processo de migração da base de dados de coleções. Os IPs que precisam de acesso à tua conta de armazenamento dependem da região para onde estás a migrar.

Opção 1: Usar tags de serviço

Pode facilmente permitir ligações de todas as regiões Azure DevOps Services adicionando a tag de serviço azuredevops aos seus grupos de segurança de rede ou firewalls, seja através do portal ou programaticamente.

Opção 2: Usar lista de IP

Use o comando IpList para obter a lista de IPs que precisam de acesso para permitir ligações a partir de uma região específica de Azure DevOps Services.

A documentação de ajuda inclui instruções e exemplos para executar o Migrator a partir da própria instância do Azure DevOps Server e de uma máquina remota. Se estiveres a executar o comando a partir de um dos níveis de aplicação da instância do Azure DevOps Server, o teu comando deve ter a seguinte estrutura:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region} 

Você pode adicionar a lista de IPs aos seus grupos de segurança de rede ou firewalls através do portal ou programaticamente.

Configurar exceções de firewall IP para SQL Azure

Esta secção aborda a configuração de exceções de firewall para SQL Azure. Para migrações de DACPAC, veja Configure os firewalls do Armazenamento do Azure e redes virtuais.

A Ferramenta de Migração de Dados exige que configure os IPs dos Serviços Azure DevOps para ligações de entrada apenas na porta 1433.

Para conceder exceções para os IPs necessários que a camada de rede Azure gere para a sua VM SQL Azure, complete os seguintes passos:

1. Inicie sessão no portal Azure.
2. Vai à tua VM SQL Azure.
3. Em Definições, selecione Redes.
4. Selecione Adicionar regra de porta de entrada.
5. Selecione Avançado para configurar uma regra de porta de entrada para um IP específico.
6. Na lista suspensa Fonte, selecione Endereços IP. Introduza um endereço IP que precisa de uma exceção. Defina o intervalo de portas de destino para 1433. Na caixa de Nome , introduza um nome que melhor descreva a exceção que está a configurar.

Dependendo de outras regras de porta de entrada configuradas, pode ser necessário alterar a prioridade padrão para as exceções dos Serviços Azure DevOps, para que não sejam ignoradas. Por exemplo, se tiver uma regra de "negar todas as ligações de entrada para 1433" com prioridade superior às exceções dos Serviços Azure DevOps, a Ferramenta de Migração de Dados pode não conseguir fazer uma ligação bem-sucedida à sua base de dados.

Repita adicionar regras de porta de entrada até que todos os IPs necessários dos Serviços Azure DevOps tenham uma exceção. A falta de um IP pode resultar na falha no início da migração.

Migrar grandes coleções

Para bases de dados que a Ferramenta de Migração de Dados alerta serem demasiado grandes, é necessária uma abordagem diferente de empacotamento de dados para migrar para Azure DevOps Services. Se não tiver a certeza se a sua coleção ultrapassa o limiar de tamanho, execute uma validação da Ferramenta de Migração de Dados na coleção. A validação permite-lhe saber se precisa de usar o método SQL Azure VM para migração.

Determinar se é possível reduzir o tamanho da coleção

Verifica se consegues limpar dados antigos. Com o tempo, as coleções podem acumular grandes volumes de dados. Esse crescimento é uma parte natural do processo de DevOps, mas você pode achar que não precisa reter todos os dados. Alguns exemplos comuns de dados que não são mais relevantes são espaços de trabalho mais antigos e resultados de compilação.

A Ferramenta de Migração de Dados verifica a sua coleção e compara-a com os limites mencionados anteriormente. Em seguida, ele informa se sua coleção é qualificada para o método de migração DACPAC ou SQL. De um modo geral, se a sua coleção for suficientemente pequena para se enquadrar nos limites do DACPAC, pode usar a abordagem DACPAC mais rápida e simples. No entanto, se a sua coleção for demasiado grande, precisa de usar o método de migração SQL, que envolve configurar uma VM SQL Azure e migrar manualmente a base de dados.

Limites de tamanho

Os limites atuais são os seguintes:

• Tamanho total da base de dados de 150 GB (metadados da base de dados + blobs) para DACPAC. Se ultrapassar este limite, precisa de executar o método de migração SQL.
• Tamanho individual de tabela de 30 GB (metadados da base de dados + blobs) para DACPAC. Se qualquer tabela única exceder este limite, precisa de realizar o método de migração SQL.
• Tamanho de metadados de base de dados de 1.536 GB para método de migração SQL. Ultrapassar este limite recebe um aviso. Para ter uma migração bem-sucedida, mantenha este dentro deste limite.
• Tamanho de metadados de base de dados de 2.048 GB para método de migração SQL. Exceder esse limite resulta em um erro, portanto, você não pode executar uma migração.
• Não há limite para tamanhos de blob para o método de migração SQL.

Quando limpa artefactos antigos, que já não são relevantes, pode retirar mais espaço do que esperava. Esta limpeza pode determinar se usa o método de migração DACPAC ou uma VM SQL Azure.

Se você estiver abaixo do limite de DACPAC, siga as instruções para gerar um DACPAC para migração. Se ainda não conseguires colocar a base de dados abaixo do limiar DACPAC, precisas de configurar uma VM SQL Azure para migrar para os Azure DevOps Services.

Configurar uma VM SQL Azure para migrar para Azure DevOps Services

Complete os seguintes passos de alto nível para configurar uma máquina virtual SQL Azure (VM) para migrar para Azure DevOps Services.

1. Configurar uma VM Azure SQL
2. Configurar exceções de firewall IP
3. Restaurar seu banco de dados na VM
4. Configure a sua coleção para migração
5. Configurar o arquivo de especificação de migração para direcionar a VM

Configurar uma VM SQL Azure

Pode rapidamente configurar uma VM SQL Azure a partir do portal Azure. Para mais informações, consulte Use o portal Azure para provisionar uma máquina virtual Windows com SQL Server.

O desempenho da sua VM SQL Azure e dos discos de dados ligados afeta significativamente o desempenho da migração. Por esta razão, complete as seguintes tarefas:

• Selecione um tamanho de VM ao nível de D8s_v5_* ou superior.
• Use discos gerenciados.
• Consulte o desempenho da máquina virtual e do disco. Certifique-se de que sua infraestrutura esteja configurada para que as IOPS da VM (entrada/saída por segundo) e as IOPS de armazenamento não se tornem um gargalo no desempenho da migração. Por exemplo, verifique se o número de discos de dados anexados à sua VM é suficiente para suportar as IOPS da VM.

Azure DevOps Services está disponível em várias regiões Azure em todo o mundo. Para garantir que a migração seja iniciada com êxito, é fundamental colocar os dados na região correta. Se configurares a tua VM SQL Azure num local errado, a migração não começa.

Se você estiver usando esse método de migração, crie sua VM em uma região compatível. Embora o Azure DevOps Services esteja disponível em várias regiões dos Estados Unidos (EUA), apenas a região Central Estados Unidos aceita novas organizações. Já não podes migrar os teus dados para outras regiões do Azure dos EUA.

Use as seguintes configurações de VM SQL Azure:

• Configure a base de dados SQL temporária para usar um disco diferente do disco C. Idealmente, o disco deve ter espaço livre suficiente, pelo menos equivalente à maior tabela da sua base de dados.
• Se o banco de dados de origem ainda tiver mais de 1 terabyte (TB) depois que você reduzir seu tamanho, será necessário anexar mais discos de 1 TB e combiná-los em uma única partição para restaurar o banco de dados na VM.
• Se os bancos de dados de coleção tiverem mais de 1 TB, considere o uso de um SSD (discos rígidos de estado sólido) para o banco de dados temporário e o banco de dados de coleção. Além disso, considere o uso de VMs maiores com 16 CPUs virtuais (vCPUs) e 128 GB (gigabytes) de RAM (memória de acesso aleatório).

Restaurar seu banco de dados na VM

Depois de preparar e configurar uma VM do Azure, precisa de transferir a sua cópia de segurança destacada da sua instância do Azure DevOps Server para a sua VM do Azure. A base de dados da coleção precisa de ser restaurada na sua instância SQL e não requer que o Azure DevOps Server esteja instalado na VM.

Configurar sua coleção para migração

Depois de restaurar a sua base de dados de coleções na sua VM Azure, configure uma autenticação SQL para permitir que os Serviços Azure DevOps se liguem à base de dados e migrem os dados. Esta autenticação concede acesso de leitura a apenas uma base de dados.

1. Abre o SQL Server Management Studio na VM e depois abre uma nova janela de consulta para a base de dados que queres migrar.

2. Defina o modelo de recuperação da base de dados para simples:

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

3. Crie uma autenticação SQL para a base de dados e atribua a essa autenticação o TFSEXECROLE papel, como mostrado no exemplo seguinte.

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

Veja o seguinte exemplo do 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'

Configurar o ficheiro de especificação de migração para direcionar a VM

Atualize o ficheiro de especificação de migração para incluir informações sobre como se ligar à instância do SQL Server. Abra o arquivo de especificação de migração e faça as seguintes atualizações:

1. Remova o parâmetro DACPAC do objeto de arquivos de origem. A especificação de migração antes da alteração se parece com o código de exemplo a seguir.

   

   A especificação de migração após a alteração se parece com o código de exemplo a seguir.

   

2. Insira os parâmetros necessários e adicione o seguinte objeto de propriedades dentro do seu objeto de origem no arquivo de especificação.

   "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"  
   }
   

Depois de aplicar as alterações, a especificação de migração se parece com o exemplo a seguir.

A sua especificação de migração está agora configurada para usar uma VM SQL Azure para migração. Prossiga com o restante das etapas de preparação para a migração. Após a conclusão da migração, certifique-se de excluir a entrada SQL ou girar a senha. A Microsoft não retém as credenciais de início de sessão depois de concluída a migração.

Crie um Armazenamento do Azure Container no data center escolhido

Utilizar a Ferramenta de Migração de Dados para o Azure DevOps requer ter um contentor de armazenamento do Azure no mesmo centro de dados do Azure que a organização final dos serviços do Azure DevOps. Por exemplo, se pretende que a sua organização Azure DevOps Services seja criada no centro de dados Central Estados Unidos, então crie o contentor Armazenamento do Azure nesse mesmo centro de dados. Essa ação acelera drasticamente o tempo necessário para migrar o banco de dados SQL, já que a transferência ocorre dentro do mesmo data center.

Para obter mais informações, veja Criar uma conta de armazenamento.

Configurar a faturação

Quando migra uma organização Azure DevOps Services, a nova organização recebe um período de carência. Utilize este tempo para concluir quaisquer passos e corrigir as atribuições de licenças. Se achar que poderá querer adquirir mais planos de utilizador, pipelines de build ou de implementação, ou serviços de build alojados, certifique-se de que tem uma subscrição do Azure pronta para ser ligada à sua organização migrada. O período de carência termina no primeiro dia do mês seguinte, após concluir a sua migração.

A fase pós-migração indica quando deve ser feita a ligação. Esta etapa de preparação serve mais para garantir que sabe qual subscrição do Azure utiliza nessa etapa posterior. Para obter mais informações, consulte Configurar o faturamento para sua organização.

Próximos passos

Conteúdo relacionado

• Migrar para Azure DevOps Services
• Concluir tarefas pós-migração