Compartilhar via

Fazer a migração de execução de teste

  • Artigo

Sua equipe agora está pronta para iniciar o processo de iniciar uma execução de teste de sua migração e, finalmente, uma migração de produção completa. Nesta fase, discutimos as etapas finais para enfileirar uma migração, além de outras tarefas que normalmente surgem no final do projeto de migração.

Diagrama destacando o estágio de pré-requisitos em estágios sequenciais.

Pré-requisitos

Conclua a fase Preparar execução de teste antes de iniciar uma migração de execução de teste.

Validar uma coleção

Valide cada coleção que você deseja migrar para Azure DevOps Services. A etapa de validação examina vários aspectos da coleção, incluindo, mas não se limitando a tamanho, ordenação, identidade e processos.

Execute a validação usando a Ferramenta de Migração de Dados.

  1. Baixe a ferramenta de migração de dados.

  2. Copie o arquivo zip para uma das camadas de aplicativo Azure DevOps Server.

  3. Descompacte o arquivo . Você também pode executar a ferramenta de um computador diferente sem Azure DevOps Server instalado, desde que o computador possa se conectar ao banco de dados de configuração da instância Azure DevOps Server.

  4. Abra uma janela do Prompt de Comando no servidor e digite um comando cd para alterar para o diretório em que a Ferramenta de Migração de Dados está armazenada. Reserve alguns minutos para revisar o conteúdo de ajuda da ferramenta.

    a. Para exibir a ajuda e as diretrizes de nível superior, execute o comando a seguir.

     Migrator /help

    b. Exiba o texto de ajuda do comando.

     Migrator validate /help

  5. Como sua primeira vez validando uma coleção, seu comando deve ter a seguinte estrutura simples.

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

    Onde {name} fornece o nome do seu locatário do Microsoft Entra, por exemplo, para executar no DefaultCollection e no locatário fabrikam , o comando seria semelhante ao exemplo a seguir.

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

  6. Para executar a ferramenta de um computador diferente do Azure DevOps Server, você precisa do parâmetro /connectionString. O parâmetro de cadeia de conexão aponta para o banco de dados de configuração Azure DevOps Server. Por exemplo, se o comando validado for executado pela corporação Fabrikam, o comando será semelhante a.

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

    Importante

    A Ferramenta de Migração de Dados não edita dados ou estruturas na coleção. Ele lê a coleção apenas para identificar problemas.

  7. Depois que a validação for concluída, você poderá exibir os arquivos de log e os resultados.

    Captura de tela dos resultados e logs de validação na janela prompt de comando.

    Durante a validação, você receberá um aviso se alguns de seus pipelines contiverem regras de retenção por pipeline. Azure DevOps Services usa um modelo de retenção baseado em projeto e não dá suporte a políticas de retenção por pipeline. Se você continuar com a migração, as políticas não serão transferidas para a versão hospedada. Em vez disso, as políticas de retenção padrão no nível do projeto se aplicam. Retenha builds importantes para você para evitar sua perda.

Depois que todas as validações forem aprovadas, você poderá passar para a próxima etapa do processo de migração. Se a Ferramenta de Migração de Dados sinalizar erros, corrija-os antes de continuar. Para obter diretrizes sobre como corrigir erros de validação, consulte Solucionar problemas de migração e erros de migração.

Importar arquivos de log

Ao abrir o diretório de log, você pode notar vários arquivos de log.

O arquivo de log main é chamado DataMigrationTool.log. Ele contém detalhes sobre tudo o que foi executado. Para facilitar o foco em áreas específicas, um log é gerado para cada operação de validação principal.

Por exemplo, se tfsMigrator relatar um erro na etapa "Validando processos de projeto", você poderá abrir o arquivo ProjectProcessMap.log para exibir tudo o que foi executado para essa etapa em vez de ter que rolar por todo o log.

Revise o arquivo TryMatchOobProcesses.log somente se estiver tentando migrar os processos do projeto para usar o modelo herdado. Se você não quiser usar o modelo herdado, poderá ignorar esses erros, pois eles não impedem que você importe para Azure DevOps Services. Para obter mais informações, consulte a fase Validar da migração.

Gerar arquivos de migração

A Ferramenta de Migração de Dados validou a coleção e está retornando um resultado de "Todas as validações de coleção aprovadas". Antes de colocar uma coleção offline para migrá-la, gere os arquivos de migração. Ao executar o prepare comando, você gera dois arquivos de migração:

  • IdentityMapLog.csv: descreve seu mapa de identidade entre o Active Directory e a ID do Microsoft Entra.
  • migration.json: Requer que você preencha a especificação de migração que deseja usar para iniciar sua migração.

Comando Preparar

O prepare comando ajuda a gerar os arquivos de migração necessários. Essencialmente, esse comando verifica a coleção para localizar uma lista de todos os usuários para preencher o log do mapa de identidade, IdentityMapLog.csv e, em seguida, tenta se conectar à ID do Microsoft Entra para encontrar a correspondência de cada identidade. Para fazer isso, sua empresa precisa usar a ferramenta Microsoft Entra Connect (anteriormente conhecida como ferramenta de Sincronização de Diretório, ferramenta de Sincronização de Diretório ou ferramenta DirSync.exe).

Se a sincronização de diretórios estiver configurada, a Ferramenta de Migração de Dados deverá localizar as identidades correspondentes e marcá-las como Ativas. Se não houver correspondências, a identidade será marcada como Histórica no log do mapa de identidade, portanto, você deve investigar por que o usuário não está incluído na sincronização de diretório. O arquivo de especificação de migração, migration.json, deve ser preenchido antes da migração.

Ao contrário do comando, prepare requer uma conexão com a validate Internet, pois precisa se conectar ao Microsoft Entra ID para preencher o arquivo de log do mapa de identidade. Se sua instância Azure DevOps Server não tiver acesso à Internet, execute a ferramenta em um computador que tenha. Contanto que você possa encontrar um computador com uma conexão de intranet com sua instância de Azure DevOps Server e uma conexão com a Internet, você pode executar esse comando. Para obter ajuda com o prepare comando , execute o seguinte comando:

Migrator prepare /help

Incluídos na documentação de ajuda estão instruções e exemplos para executar o Migrator comando da própria instância do Azure DevOps Server e de um computador remoto. Se você estiver executando o comando de uma das camadas de aplicativo da instância Azure DevOps Server, o comando deverá ter a seguinte estrutura:

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"

O parâmetro connectionString é um ponteiro para o banco de dados de configuração da instância do Azure DevOps Server. Por exemplo, se a corporação Fabrikam executar o prepare comando, o comando será semelhante ao exemplo a seguir:

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

Quando a Ferramenta de Migração de Dados executa o prepare comando, ela executa uma validação completa para garantir que nada tenha sido alterado em sua coleção desde a última validação completa. Se novos problemas forem detectados, nenhum arquivo de migração será gerado.

Logo após o comando começar a ser executado, uma janela de entrada do Microsoft Entra é exibida. Entre com uma identidade que pertença ao domínio do locatário, que é especificado no comando. Verifique se o locatário especificado do Microsoft Entra é aquele com o qual você deseja que sua futura organização seja apoiada. Em nosso exemplo da Fabrikam, um usuário insere credenciais semelhantes à captura de tela de exemplo a seguir.

Importante

Não use um locatário de teste do Microsoft Entra para uma migração de teste e seu locatário de produção do Microsoft Entra para a execução de produção. O uso de um locatário de teste do Microsoft Entra pode resultar em problemas de migração de identidade quando você inicia a execução de produção com o locatário de produção do Microsoft Entra da sua organização.

Quando você executa o prepare comando com êxito na Ferramenta de Migração de Dados, a janela de resultados exibe um conjunto de logs e dois arquivos de migração. No diretório de log, localize uma pasta de logs e dois arquivos:

  • migration.json é o arquivo de especificação de migração. Recomendamos que você tenha tempo para preenchê-lo.
  • IdentityMapLog.csv contém o mapeamento gerado do Active Directory para identidades do Microsoft Entra. Revise-o para verificar se está completo antes de iniciar uma migração.

Os dois arquivos são descritos com mais detalhes nas próximas seções.

O arquivo de especificação de migração

A especificação de migração, migration.json, é um arquivo JSON que fornece configurações de migração. Ele inclui o nome da organização desejado, as informações da conta de armazenamento e outras informações. A maioria dos campos é preenchida automaticamente e alguns campos exigem sua entrada antes de você tentar uma migração.

Captura de tela de um arquivo de especificação de migração recém-gerado.

Os campos exibidos do arquivo migration.json e as ações necessárias são descritos na tabela a seguir:

Campo Descrição Ação necessária
Origem Informações sobre o local e os nomes dos arquivos de dados de origem usados para migração. Nenhuma ação é necessária. Examine as informações das ações de subcampo a serem seguidas.
Location A chave de assinatura de acesso compartilhado para a conta de armazenamento do Azure que hospeda o DACPAC (pacote de aplicativos da camada de dados). Nenhuma ação é necessária. Este campo é abordado em uma etapa posterior.
Arquivos Os nomes dos arquivos que contêm dados de migração. Nenhuma ação é necessária. Examine as informações das ações de subcampo a serem seguidas.
DACPAC Um arquivo DACPAC que empacota o banco de dados de coleção a ser usado para trazer os dados durante a migração. Nenhuma ação é necessária. Em uma etapa posterior, você cria esse arquivo usando sua coleção e carrega-o em uma conta de armazenamento do Azure. Atualize o arquivo com base no nome que você usa ao gerá-lo posteriormente neste processo.
Destino Propriedades da nova organização para a migração. Nenhuma ação é necessária. Examine as informações das ações de subcampo a serem seguidas.
Nome O nome da organização a ser criada durante a migração. Forneça um nome. O nome pode ser alterado rapidamente posteriormente após a conclusão da migração.
NOTA: Não crie uma organização com esse nome antes de executar a migração. A organização é criada como parte do processo de migração.
ImportType O tipo de migração que você deseja executar. Nenhuma ação é necessária. Em uma etapa posterior, selecione o tipo de migração a ser executada.
Dados de validação Informações necessárias para ajudar a impulsionar sua experiência de migração. A Ferramenta de Migração de Dados gera a seção "ValidationData". Ele contém informações para ajudar a impulsionar sua experiência de migração. Não* edite os valores nesta seção, ou sua migração pode falhar ao iniciar.

Depois de concluir o processo anterior, você deve ter um arquivo semelhante ao exemplo a seguir.

Captura de tela de um arquivo de especificação de migração parcialmente concluído.

Na imagem anterior, o planejador da migração da Fabrikam adicionou o nome da organização fabrikam-import e selecionou CUS (Central dos Estados Unidos) como o local geográfico para a migração. Outros valores foram deixados como devem ser modificados pouco antes de o planejador colocar a coleção offline para a migração.

Observação

As importações de execução de teste têm um '-dryrun' anexado automaticamente ao final do nome da organização, que você pode alterar após a migração.

Regiões do Azure com suporte para migração

Azure DevOps Services está disponível em várias localizações geográficas do Azure. No entanto, nem todos os locais em que Azure DevOps Services está disponível têm suporte para migração. A tabela a seguir lista as localizações geográficas do Azure que você pode selecionar para migração. Também está incluído o valor que você precisa colocar no arquivo de especificação de migração para direcionar essa geografia para migração.

Localização geográfica Localização geográfica do Azure Valor da especificação de importação
Estados Unidos Central Estados Unidos CUS
Europa Europa Ocidental WEU
Reino Unido Sul do Reino Unido UKS
Austrália Leste da Austrália EAU
América do Sul Brazil South SBR
Pacífico Asiático Sul da Índia MA
Pacífico Asiático Sudeste da Ásia (Singapura) SEA
Canadá Centro do Canadá CC

O log do mapa de identidade

O log do mapa de identidade é de igual importância para os dados reais que você migra para Azure DevOps Services. Ao revisar o arquivo, é importante entender como a migração de identidade opera e quais os possíveis resultados podem implicar. Quando você migra uma identidade, ela pode se tornar ativa ou histórica. As identidades ativas podem entrar no Azure DevOps Services, mas as identidades históricas não.

Identidades ativas

As identidades ativas referem-se às identidades de usuário no Azure DevOps Services após a migração. Em Azure DevOps Services, essas identidades são licenciadas e são exibidas como usuários na organização. As identidades são marcadas como ativas na coluna Status de Importação Esperado no arquivo de log do mapa de identidade.

Identidades históricas

As identidades históricas são mapeadas como tal na coluna Status de Importação Esperado no arquivo de log do mapa de identidade. 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, 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 é a noção do nome dessa identidade na organização, para que seu histórico possa ser pesquisado posteriormente. Recomendamos que você use identidades históricas para usuários que não trabalham mais na empresa ou que não precisam mais de acesso à organização.

Observação

Depois que uma identidade é importada como histórica, ela não pode se tornar ativa.

Entender o arquivo de log do mapa de identidade

O arquivo de log do mapa de identidade é semelhante ao exemplo mostrado aqui:

Captura de tela de um arquivo de log do mapa de identidade gerado pela Ferramenta de Migração de Dados.

As colunas no arquivo de log do mapa de identidade são descritas na tabela a seguir:

Você e o administrador do Microsoft Entra devem investigar os usuários marcados como Nenhuma correspondência encontrada (verificar a sincronização de ID do Microsoft Entra) para entender por que eles não fazem parte da sincronização do Microsoft Entra Connect.

Coluna Descrição
Active Directory: Usuário (Azure DevOps Server) O nome de exibição amigável usado pela identidade em Azure DevOps Server. Esse nome facilita a identificação de qual usuário a linha no mapa está referenciando.
Active Directory: Identificador de Segurança O identificador exclusivo para a identidade Active Directory local no Azure DevOps Server. Esta coluna é usada para identificar usuários na coleção.
ID do Microsoft Entra: Usuário de Importação Esperado (Azure DevOps Services) O endereço de entrada esperado do usuário correspondente que logo estará ativo ou Nenhuma correspondência encontrada (verificar a sincronização de ID do Microsoft Entra), que indica que a identidade foi perdida durante a sincronização de ID do Microsoft Entra e é importada como histórica.
Status de importação esperado O status de migração do usuário esperado: Ativo se houver uma correspondência entre o Active Directory e a ID do Microsoft Entra ou Histórico se não houver uma correspondência.
Data de validação A última vez que o log do mapa de identidade foi validado.

Ao ler o arquivo, observe se o valor na coluna Status de Importação Esperado é Ativo ou Histórico. Ativo indica que a identidade nessa linha é mapeada corretamente quando a migração se torna ativa. Histórico significa que as identidades se tornam históricas na migração. É importante examinar o arquivo de mapeamento gerado quanto à integridade e à correção.

Importante

A migração falhará se ocorrerem alterações importantes na sincronização da ID de segurança do Microsoft Entra Connect entre as tentativas de migração. Você pode adicionar novos usuários entre as execuções de teste e fazer correções para garantir que as identidades históricas importadas anteriormente se tornem ativas. No entanto, você não pode alterar um usuário existente que foi importado anteriormente como ativo. Isso faz com que sua migração falhe. Um exemplo de alteração pode ser concluir uma migração de execução de teste, excluir uma identidade da ID do Microsoft Entra que foi importada ativamente, recriar um novo usuário na ID do Microsoft Entra para essa mesma identidade e tentar outra migração. Nesse caso, uma migração de identidade ativa tenta entre o Active Directory e a identidade recém-criada do Microsoft Entra, mas causa uma falha de migração.

  1. Revise as identidades correspondentes corretamente. Todas as identidades esperadas estão presentes? Os usuários são mapeados para a identidade correta do Microsoft Entra?

    Se algum valor precisar ser alterado, entre em contato com o administrador do Microsoft Entra para verificar se a identidade do Active Directory local faz parte da sincronização com a ID do Microsoft Entra e está configurada corretamente. Para obter mais informações, consulte Integrar suas identidades locais com a ID do Microsoft Entra.

  2. Em seguida, examine as identidades rotuladas como históricas. Essa rotulagem implica que uma identidade correspondente do Microsoft Entra não pôde ser encontrada, por qualquer um dos seguintes motivos:

    • A identidade não está configurada para sincronização entre o Active Directory local e a ID do Microsoft Entra.
    • A identidade ainda não está preenchida em sua ID do Microsoft Entra (por exemplo, há um novo funcionário).
    • A identidade não existe em sua instância do Microsoft Entra.
    • O usuário que possui essa identidade não funciona mais na empresa.

Para resolver os três primeiros motivos, configure a identidade do Active Directory local pretendida para sincronizar com a ID do Microsoft Entra. Para obter mais informações, consulte Integrar suas identidades locais com a ID do Microsoft Entra. Você deve configurar e executar o Microsoft Entra Connect para que as identidades sejam importadas como ativas em Azure DevOps Services.

Você pode ignorar o quarto motivo, pois os funcionários que não estão mais na empresa devem ser importados como históricos.

Identidades históricas (pequenas equipes)

Observação

A estratégia de migração de identidade proposta nesta seção deve ser considerada apenas por equipes pequenas.

Se o Microsoft Entra Connect não estiver configurado, todos os usuários no arquivo de log do mapa de identidade serão marcados como históricos. Executar uma migração dessa maneira resulta em todos os usuários sendo importados como históricos. É altamente recomendável que você configure o Microsoft Entra Connect para garantir que seus usuários sejam importados como ativos.

Executar uma migração com todas as identidades históricas tem consequências que precisam ser consideradas com cuidado. Somente equipes com poucos usuários e para as quais o custo de configuração do Microsoft Entra Connect é considerado muito alto devem ser consideradas.

Para migrar todas as identidades como históricas, siga as etapas descritas nas seções posteriores. Quando você enfileira uma migração, a identidade usada para enfileirar a migração é inicializada na organização como o proprietário da organização. Todos os outros usuários são importados como históricos. Os proprietários da organização podem adicionar os usuários novamente usando sua identidade do Microsoft Entra. Os usuários adicionados são tratados como novos usuários. Eles não possuem* nenhum de seus históricos e não há como reparentar esse histórico para a identidade do Microsoft Entra. No entanto, os usuários ainda podem pesquisar seu histórico de pré-migração pesquisando por seu \<domain>\<Active Directory username>.

A Ferramenta de Migração de Dados exibirá um aviso se detectar o cenário completo de identidades históricas. Se você decidir seguir esse caminho de migração, precisará consentir na ferramenta com as limitações.

Assinaturas do Visual Studio

A Ferramenta de Migração de Dados não pode detectar assinaturas do Visual Studio (anteriormente conhecidas como benefícios do MSDN) quando gera o arquivo de log do mapa de identidade. Em vez disso, recomendamos que você aplique o recurso de atualização automática de licença após a migração. Desde que as contas corporativas dos usuários estejam vinculadas corretamente, Azure DevOps Services aplica automaticamente seus benefícios de assinatura do Visual Studio na primeira entrada após a migração. Você nunca é cobrado por licenças atribuídas durante a migração, portanto, pode lidar com assinaturas com segurança posteriormente.

Você não precisará repetir uma migração de execução de teste se as assinaturas do Visual Studio dos usuários não forem atualizadas automaticamente em Azure DevOps Services. A vinculação de assinatura do Visual Studio ocorre fora do escopo de uma migração. Desde que a conta corporativa esteja vinculada corretamente antes ou depois da migração, as licenças dos usuários serão atualizadas automaticamente na próxima entrada. Depois que suas licenças forem atualizadas com êxito, na próxima vez que você executar uma migração, os usuários serão atualizados automaticamente em sua primeira entrada na organização.

Preparar para a migração

Agora você tem tudo pronto para ser executado em sua migração de execução de teste. Agende o tempo de inatividade com sua equipe para colocar a coleção offline para a migração. Quando você concordar com um horário para executar a migração, carregue os ativos necessários gerados e uma cópia do banco de dados para o Azure. A preparação para a migração consiste nas cinco etapas a seguir.

Etapa 1: coloque a coleção offline e desanexe-a. Etapa 2: Gere um arquivo DACPAC da coleção que você vai migrar.
Etapa 3: Carregue o arquivo DACPAC e os arquivos de migração em uma conta de armazenamento do Azure.
Etapa 4: gerar um token SAS para acessar a conta de armazenamento.
Etapa 5: Conclua a especificação de migração.

Observação

Antes de executar uma migração de produção, é altamente recomendável que você conclua uma migração de execução de teste. Com uma execução de teste, você pode validar se o processo de migração funciona para sua coleção e se não há formas de dados exclusivas presentes que possam causar uma falha de migração de produção.

Etapa 1: Desanexar sua coleção

Desanexar a coleção é uma etapa crucial no processo de migração. Os dados de identidade da coleção residem no banco de dados de configuração da instância Azure DevOps Server enquanto a coleção está anexada e online. Quando uma coleção é desanexada da instância Azure DevOps Server, ela pega uma cópia desses dados de identidade e os empacota com a coleção para transporte. Sem esses dados, a parte de identidade da migração não pode ser executada.

Dica

Recomendamos que você mantenha a coleção desanexada até que a migração seja concluída, pois não há uma maneira de migrar as alterações que ocorreram durante a migração. Reanexe sua coleção depois de fazer backup dela para migração, para que você não se preocupe em ter os dados mais recentes para esse tipo de migração. Para evitar completamente o tempo offline, você também pode optar por empregar uma desanexação offline para execuções de teste.

É importante pesar o custo de optar por incorrer em tempo de inatividade zero para um teste. Ele requer fazer backups da coleção e do banco de dados de configuração, restaurá-los em uma instância SQL e, em seguida, criar um backup desanexado. Uma análise de custo pode provar que levar apenas algumas horas de inatividade para fazer o backup desanexado é melhor no final.

Etapa 2: gerar um arquivo DACPAC

OS DACPACs oferecem um método rápido e relativamente fácil para mover coleções para Azure DevOps Services. No entanto, depois que um tamanho de banco de dados de coleção excede um determinado limite, os benefícios de usar um DACPAC começam a diminuir.

Observação

Se a Ferramenta de Migração de Dados exibir um aviso de que você não pode usar o método DACPAC, você precisará executar a migração usando o método de VM (máquina virtual) do SQL Azure. Ignore as etapas 2 a 5 nesse caso e siga as instruções na fase Preparar execução de teste, seção Migrar grandes coleções e continue a determinar o tipo de migração. Se a Ferramenta de Migração de Dados não exibir um aviso, use o método DACPAC descrito nesta etapa.

O DACPAC é um recurso do SQL Server que permite que os bancos de dados sejam empacotados em um único arquivo e implantados em outras instâncias do SQL Server. Um arquivo DACPAC também pode ser restaurado diretamente para Azure DevOps Services, para que você possa usá-lo como o método de empacotamento para obter os dados da coleção na nuvem.

Importante

  • Ao usar o SqlPackage.exe, você deve usar a versão .NET Framework do SqlPackage.exe para preparar o DACPAC. O Instalador MSI deve ser usado para instalar a versão .NET Framework do SqlPackage.exe. Não use a CLI dotnet ou as versões .zip (Windows .NET 6) do SqlPackage.exe pois essas versões podem gerar DACPACs incompatíveis com Azure DevOps Services.
  • A versão 161 do SqlPackage criptografa conexões de banco de dados por padrão e pode não se conectar. Se você receber um erro de processo de logon, adicione ;Encrypt=False;TrustServerCertificate=True à cadeia de conexão da instrução SqlPackage.

Baixe e instale SqlPackage.exe usando o instalador MSI mais recente das notas de versão do SqlPackage.

Depois de usar o instalador MSI, SqlPackage.exe é instalado em um caminho semelhante ao %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

Ao gerar um DACPAC, lembre-se de duas considerações: o disco no qual o DACPAC é salvo e o espaço em disco no computador que está gerando o DACPAC. Você deseja garantir que tenha espaço em disco suficiente para concluir a operação.

À medida que ele cria o pacote, SqlPackage.exe armazena temporariamente dados de sua coleção no diretório temporário na unidade C do computador do qual você está iniciando a solicitação de empacotamento.

Você pode achar que a unidade C é muito pequena para dar suporte à criação de um DACPAC. Você pode estimar a quantidade de espaço necessária procurando a maior tabela em seu banco de dados de coleção. OS DACPACs são criados uma tabela por vez. O requisito de espaço máximo para executar a geração é aproximadamente equivalente ao tamanho da maior tabela no banco de dados da coleção. Se você salvar o DACPAC gerado na unidade C, considere o tamanho do banco de dados de coleção conforme relatado no arquivo DataMigrationTool.log de uma execução de validação.

O arquivo DataMigrationTool.log fornece uma lista das maiores tabelas da coleção sempre que o comando é executado. Para obter um exemplo de tamanhos de tabela para uma coleção, consulte a saída a seguir. Compare o tamanho da maior tabela com o espaço livre na unidade que hospeda o diretório temporário.

Importante

Antes de continuar gerando um arquivo DACPAC, verifique se a coleção está desanexada.

[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

Verifique se a unidade que hospeda seu diretório temporário tem pelo menos tanto espaço livre. Caso contrário, você precisará redirecionar o diretório temporário definindo uma variável de ambiente.

SET TEMP={location on disk}

Outra consideração é onde os dados da DACPAC são salvos. Apontar o local salvo para uma unidade remota distante pode resultar em tempos de geração mais longos. Se uma unidade rápida, como uma SSD (unidade de estado sólido) estiver disponível localmente, recomendamos que você direcione a unidade como o local de salvamento do DACPAC. Caso contrário, é sempre mais rápido usar um disco que está no computador em que o banco de dados da coleção reside em vez de uma unidade remota.

Agora que você identificou o local de destino para o DACPAC e garantiu que tem espaço suficiente, é hora de gerar o arquivo DACPAC.

Abra uma janela do Prompt de Comando e vá para o local SqlPackage.exe. Para gerar o DACPAC, substitua os valores de espaço reservado pelos valores necessários e execute o seguinte comando:

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
  • Fonte de dados: a instância SQL Server que hospeda o banco de dados de coleção Azure DevOps Server.
  • Catálogo Inicial: o nome do banco de dados da coleção.
  • targetFile: o local no disco e o nome do arquivo DACPAC.

Um comando de geração DACPAC em execução na própria camada de dados Azure DevOps Server é mostrado no exemplo a seguir:

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

A saída do comando é um arquivo DACPAC, gerado a partir do banco de dados de coleção Foo chamado Foo.dacpac.

Configurar sua coleção para migração

Depois que o banco de dados de coleção for restaurado na VM do Azure, configure uma entrada SQL para permitir que Azure DevOps Services se conecte ao banco de dados para migrar os dados. Essa entrada permite apenas acesso de leitura a um único banco de dados.

Para iniciar, abra SQL Server Management Studio na VM e abra uma nova janela de consulta no banco de dados a ser importado.

Defina a recuperação do banco de dados como simples:

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

Crie uma entrada SQL para o banco de dados e atribua a essa entrada o '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>'

Seguindo nosso exemplo da Fabrikam, os dois comandos SQL seriam semelhantes ao exemplo a seguir:

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'

Observação

Habilite o modo de autenticação do SQL Server e do Windows no SQL Server Management Studio na VM. Se você não habilitar o modo de autenticação, a migração falhará.

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

Atualize o arquivo de especificação de migração para incluir informações sobre como se conectar à 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 é mostrada no código a seguir.

    Captura de tela da especificação de migração antes da alteração.

    A especificação de migração após a alteração é mostrada no código a seguir.

    Captura de tela da especificação de migração após a alteração.

  2. Preencha os parâmetros necessários e adicione o objeto de propriedades a seguir dentro do 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.

Captura de tela da especificação de migração que faz referência a uma VM do SQL Azure.

Sua especificação de migração agora está configurada para usar uma VM do SQL Azure para migração. Prossiga com o restante das etapas de preparação para a migração para Azure DevOps Services. 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 informações de entrada após a conclusão da migração.

Etapa 3: Carregar o arquivo DACPAC

Observação

Se você estiver usando o método SQL Azure VM, precisará fornecer apenas a cadeia de conexão. Você não precisa carregar nenhum arquivo e pode ignorar esta etapa.

Seu DACPAC deve ser colocado em um contêiner de armazenamento do Azure, que pode ser um contêiner existente ou criado especificamente para seu esforço de migração. É importante garantir que seu contêiner seja criado nas localizações geográficas corretas.

Azure DevOps Services está disponível em várias localizações geográficas. Ao importar para esses locais, é fundamental colocar seus dados corretamente para garantir que a migração possa ser iniciada com êxito. Seus dados devem ser colocados na mesma localização geográfica para a qual você está importando. Colocar os dados em qualquer outro lugar faz com que a migração não seja iniciada. A tabela a seguir lista as localizações geográficas aceitáveis para criar sua conta de armazenamento e carregar seus dados.

Localização geográfica da migração desejada Localização geográfica da conta de armazenamento
Central Estados Unidos Central Estados Unidos
Europa Ocidental Europa Ocidental
Reino Unido Sul do Reino Unido
Leste da Austrália Leste da Austrália
Sul do Brasil Brazil South
Sul da Índia Sul da Índia
Canadá Central Canadá Central
Pacífico Asiático (Singapura) Pacífico Asiático (Singapura)

Embora Azure DevOps Services esteja disponível em várias localizações geográficas nos EUA, somente o local Central dos Estados Unidos aceita novos Azure DevOps Services. No momento, você não pode migrar seus dados para outros locais do Azure nos EUA.

Crie um contêiner de blob no portal do Azure. Depois de criar o contêiner, carregue o arquivo DACPAC de Coleção.

Após a conclusão da migração, exclua o contêiner de blob e a conta de armazenamento que o acompanha com ferramentas como o AzCopy ou qualquer outra ferramenta do gerenciador de armazenamento do Azure, como o Gerenciador de Armazenamento do Azure.

Observação

Se o arquivo DACPAC for maior que 10 GB, recomendamos que você use o AzCopy. O AzCopy tem suporte de upload multithread para uploads mais rápidos.

Etapa 4: Gerar um token SAS

Um token SAS (assinatura de acesso compartilhado) fornece acesso delegado aos recursos em uma conta de armazenamento. O token permite que você conceda à Microsoft o nível mais baixo de privilégio necessário para acessar seus dados para executar a migração.

Você pode gerar tokens SAS usando o portal do Azure. Do ponto de vista da segurança, recomendamos executar as seguintes tarefas:

  1. Selecione apenas Ler e Listar como permissões para o token SAS. Nenhuma outra permissão é necessária.
  2. Defina um tempo de expiração não superior a sete dias no futuro.
  3. Restrinja o acesso somente a IPs do Azure DevOps Services.
  4. Trate a chave SAS como um segredo. Não deixe a chave em um local inseguro, pois ela concede acesso de leitura e lista a todos os dados armazenados no contêiner.

Etapa 5: Concluir a especificação de migração

No início do processo, você preencheu parcialmente o arquivo de especificação de migração, conhecido como migration.json. Neste ponto, você tem informações suficientes para preencher todos os campos restantes, exceto o tipo de migração. O tipo de migração é abordado posteriormente, na seção de migração.

No arquivo de especificação migration.json, em Origem, preencha os campos a seguir.

  • Local: cole a chave SAS gerada do script e copiada na etapa anterior.
  • Dacpac: verifique se o arquivo, incluindo a extensão de arquivo .dacpac , tem o mesmo nome que o arquivo DACPAC que você carregou na conta de armazenamento.

O arquivo de especificação de migração final deve ser semelhante ao exemplo a seguir.

Captura de tela do arquivo de especificação de migração concluído.

Determinar o tipo de migração

As importações podem ser enfileiradas como uma execução de teste ou uma execução de produção. O parâmetro ImportType determina o tipo de migração:

  • TestRun: use uma execução de teste para fins de teste. O sistema exclui as execuções de teste após 45 dias.
  • ProductionRun: use uma execução de produção quando quiser manter a migração resultante e usar a organização em tempo integral em Azure DevOps Services após a conclusão da migração.

Dica

Sempre recomendamos que você conclua uma migração de execução de teste primeiro.

Organizações de execução de teste

As organizações de execução de teste ajudam as equipes a testar a migração de suas coleções. Antes que uma migração de produção possa ser executada, todas as organizações de execução de teste concluídas devem ser excluídas. Todas as organizações de execução de teste têm uma existência limitada e são excluídas automaticamente após um determinado período de tempo. As informações sobre quando a organização é excluída são incluídas no e-mail de sucesso que você deve receber após a conclusão da migração. Anote essa data e planeje-se adequadamente.

As organizações de execução de teste têm 45 dias antes de serem excluídas. Após o período de tempo especificado, a organização de execução de teste é excluída. Você pode repetir as importações de execução de teste quantas vezes precisar antes de fazer uma migração de produção.

Excluir execuções de teste

Exclua todas as execuções de teste anteriores antes de tentar uma nova. Quando sua equipe estiver pronta para executar uma migração de produção, você precisará excluir manualmente a organização de execução de teste. Antes de executar uma segunda migração de execução de teste ou a migração de produção final, exclua todas as organizações anteriores do Azure DevOps Services que você criou em uma execução de teste anterior. Para obter mais informações, consulte Excluir organização.

Dica

Informações opcionais para ajudar um usuário a ter mais sucessoEspera-se que qualquer migração de execução de teste que siga a primeira demore mais, devido ao tempo extra necessário para limpar os recursos de execuções de teste anteriores.

Pode levar até uma hora para que o nome de uma organização fique disponível após a exclusão ou renomeação. Para obter mais informações, consulte o artigo Tarefas pós-migração.

Se você encontrar problemas de migração, consulte Solucionar problemas de migração e erros de migração.

Executar uma migração

Sua equipe agora está pronta para iniciar o processo de execução de uma migração. Recomendamos que você comece com uma migração de execução de teste bem-sucedida antes de tentar uma migração de execução de produção. Com as importações de execução de teste, você pode ver com antecedência a aparência de uma migração, identificar possíveis problemas e ganhar experiência antes de iniciar a execução de produção.

Observação

  • Se você precisar repetir uma migração de execução de produção concluída para uma coleção, como no caso de uma reversão, entre em contato com o Suporte ao Cliente do Azure DevOps Services antes de enfileirar outra migração.
  • Os administradores do Azure podem impedir que os usuários criem novas organizações do Azure DevOps. Se a política de locatário do Microsoft Entra estiver ativada, a migração não será concluída. Antes de começar, verifique se a política não está definida ou se há uma exceção para o usuário que está executando a migração. Para obter mais informações, consulte Restringir a criação da organização por meio da política de locatário do Microsoft Entra.
  • Azure DevOps Services não dá suporte a políticas de retenção por pipeline e elas não são transferidas para a versão hospedada.

Considerações sobre planos de reversão

Uma preocupação comum para as equipes que fazem uma execução final de produção é o plano de reversão, se algo der errado com a migração. É altamente recomendável fazer uma execução de teste para garantir que você possa testar as configurações de migração fornecidas para a Ferramenta de Migração de Dados para Azure DevOps.

A reversão para a execução final de produção é bastante simples. Antes de enfileirar a migração, desanexe a coleção de projetos de equipe de Azure DevOps Server, o que a torna indisponível para os membros da equipe. Se, por algum motivo, você precisar reverter a execução de produção e colocar o servidor local novamente online para os membros da equipe, você poderá fazer isso. Anexe a coleção de projetos de equipe local novamente e informe à sua equipe que eles continuam trabalhando normalmente enquanto sua equipe se reagrupa para entender possíveis falhas.

Em seguida, você pode entrar em contato com o suporte ao cliente do Azure DevOps Services para obter ajuda para entender a causa da falha se não puder determinar a causa. Para obter mais informações, consulte o artigo Solução de problemas. Os tíquetes de suporte ao cliente podem ser abertos na página https://aka.ms/AzureDevOpsImportSupporta seguir . É importante observar que, se o problema exigir que os engenheiros do grupo de produtos se envolvam, esses casos serão tratados durante o horário comercial normal.

Desanexe sua coleção de projetos de equipe de Azure DevOps Server para prepará-la para migração.

Antes de gerar um backup do banco de dados SQL, a Ferramenta de Migração de Dados exige que a coleção seja completamente desanexada de Azure DevOps Server (não SQL). O processo de desanexação em Azure DevOps Server transfere informações de identidade do usuário armazenadas fora do banco de dados de coleção e as torna portáteis para mover para um novo servidor ou, nesse caso, para Azure DevOps Services.

Desanexar uma coleção é feito facilmente no Console de Administração do Azure DevOps Server em sua instância do Azure DevOps Server. Para obter mais informações, consulte Mover coleção de projetos, Desanexar a coleção.

Enfileirar a migração

Importante

Antes de prosseguir, verifique se a coleção foi desanexada antes de gerar um arquivo DACPAC ou carregar o banco de dados de coleção em uma VM SQL Azure. Se você não concluir esta etapa, a migração falhará. Caso a migração falhe, consulte Resolver erros de migração.

Inicie uma migração usando o comando import da Data Migration Tool. O comando de migração usa um arquivo de especificação de migração como entrada. Ele analisa o arquivo para garantir que os valores fornecidos sejam válidos e, se for bem-sucedido, enfileira uma migração para Azure DevOps Services. O comando de migração requer uma conexão com a Internet, mas não* requer uma conexão com sua instância Azure DevOps Server.

Para começar, abra uma janela do Prompt de Comando e altere os diretórios para o caminho para a Ferramenta de Migração de Dados. Recomendamos que você revise o texto de ajuda fornecido com a ferramenta. Execute o seguinte comando para ver as diretrizes e a ajuda para o comando de migração:

Migrator import /help

O comando para enfileirar uma migração tem a seguinte estrutura:

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

O exemplo a seguir mostra um comando de migração concluído:

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

Depois que a validação for aprovada, entre na ID do Microsoft Entra com uma identidade que seja membro do mesmo locatário do Microsoft Entra em que o arquivo de log do mapa de identidade foi criado. O usuário conectado é o proprietário da organização importada.

Observação

Cada locatário do Microsoft Entra está limitado a cinco importações por período de 24 horas. Somente importações que estão na fila contam com esse limite.

Quando sua equipe inicia uma migração, uma notificação por e-mail é enviada ao usuário que enfileirou a migração. Cerca de 5 a 10 minutos após a migração na fila, sua equipe pode ir até a organização para verificar o status. Após a conclusão da migração, sua equipe é direcionada para entrar e uma notificação por email é enviada ao proprietário da organização.

A Ferramenta de Migração de Dados sinaliza erros que você precisa corrigir antes da migração. Este artigo descreve os avisos e erros mais comuns que você pode receber ao se preparar para migrar. Depois de corrigir cada erro, execute o comando migrator validate novamente para verificar a resolução.

Próximas etapas

Resolver erros de migração