Executar migração de teste

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 agendar uma migração, além de outras tarefas que normalmente surgem no final do projeto de migração.

Pré-requisitos

Conclua a fase de Preparação da execução de testes antes de iniciar uma migração da execução de testes.

Validar uma coleção

Valide cada coleção que você deseja migrar para os Serviços de DevOps do Azure. A etapa de validação examina vários aspetos da sua coleção, incluindo, mas não limitado a, tamanho, agrupamento, identidade e processos.

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

1. Faça o download da Ferramenta de Migração de Dados.

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

3. Deszipe o ficheiro. Você também pode executar a ferramenta de uma máquina diferente sem o Servidor de DevOps do Azure instalado, desde que a máquina possa se conectar ao banco de dados de configuração da instância do Servidor de DevOps do Azure.

4. Abra uma janela da Linha de Comandos no servidor e insira um comando cd para mudar para o diretório onde a Ferramenta de Migração de Dados está armazenada. Reserve alguns minutos para rever o conteúdo de ajuda da ferramenta.

   a) Para exibir a ajuda e a orientação de nível superior, execute o seguinte comando.

    Migrator /help
   

   b. Exiba o texto de ajuda do comando.

    Migrator validate /help 
   

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

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

   Onde {name} fornece o nome do inquilino do Microsoft Entra, por exemplo, para executar contra a DefaultCollection e o inquilino 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 uma máquina diferente do Servidor de DevOps do Azure, você precisa do parâmetro /connectionString . O parâmetro da cadeia de ligação aponta para a base de dados de configuração do Azure DevOps Server. Por exemplo, se o comando validado for executado pela corporação Fabrikam, o comando será parecido.

    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 quaisquer dados ou estruturas na coleção. Ele lê a coleção apenas para identificar problemas.

7. Após a conclusão da validação, você poderá visualizar os arquivos de log e os resultados.

   

   Durante a validação, receberás um aviso caso alguns dos teus pipelines contenham regras de retenção por pipeline. Os Serviços de DevOps do Azure usam um modelo de retenção baseado em projeto e não oferecem 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, aplicam-se as políticas de retenção padrão no nível do projeto. Retenha construções importantes para você para evitar sua perda.

Depois que todas as validações passarem, 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 orientação 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 principal é chamado DataMigrationTool.log. 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 o TfsMigrator relatar um erro no passo "Validar Processos do Projeto", pode abrir o ficheiro ProjectProcessMap.log para ver tudo o que foi executado para essa etapa em vez de ter que percorrer todo o log.

Revise o arquivo TryMatchOobProcesses.log somente se estiver tentando migrar seus processos de projeto para usar o modelo herdado. Se você não quiser usar o modelo herdado, poderá ignorar esses erros, pois eles não impedem a importação para os Serviços de DevOps do Azure. Para obter mais informações, consulte a fase de Validação 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 coleta 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 Ative Directory e o Microsoft Entra ID.
• migration.json: Requer que você preencha a especificação de migração que deseja usar para iniciar a migração.

Preparar Comando

O prepare comando ajuda a gerar os arquivos de migração necessários. Essencialmente, esse comando verifica a coleção para encontrar uma lista de todos os usuários para preencher o log do mapa de identidade, IdentityMapLog.csv e, em seguida, tenta se conectar ao 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órios, ferramenta de sincronização de diretórios 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órico 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órios. O arquivo de especificação de migração, migration.json, deve ser preenchido antes da migração.

Ao contrário do comando validate, preparerequer uma conexão com a internet, porque precisa se conectar ao Microsoft Entra ID para preencher o ficheiro de log do mapa de identidade. Se sua instância do Servidor de DevOps do Azure não tiver acesso à Internet, execute a ferramenta a partir de uma máquina que o faça. Contanto que você possa encontrar uma máquina com uma conexão de intranet para sua instância do 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 comando a Migrator partir da própria instância do Azure DevOps Server e de uma máquina remota. Se você estiver executando o comando de uma das camadas de aplicativo da instância do Azure DevOps Server, seu 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 sua instância do Azure DevOps Server. Por exemplo, se a corporação da 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 mudou com sua coleção desde a última validação completa. Se forem detetados novos problemas, nenhum arquivo de migração será gerado.

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

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 dedique algum tempo a 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 ficheiros são descritos mais pormenorizadamente nas secções seguintes.

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. Inclui o nome da organização desejada, informações da conta de armazenamento e outras informações. A maioria dos campos é preenchida automaticamente e alguns campos exigem sua entrada antes de tentar uma migração.

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

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

Na imagem anterior, o planejador da migração da Fabrikam adicionou o nome da organização fabrikam-import e selecionou CUS (Central United States) como a localização geográfica para a migração. Outros valores foram deixados inalterados para serem modificados pouco antes de o planificador colocar a coleção offline para a migração.

Regiões do Azure suportadas para migração

Os Serviços de DevOps do Azure estão disponíveis em vários locais geográficos do Azure. No entanto, nem todos os locais onde os Serviços de DevOps do Azure estão disponíveis têm suporte para migração. A tabela a seguir lista os locais geográficos 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.

O registo do mapa de identidade

O registo do mapa de identidade é tão importante quanto os dados reais que são migrados para os Azure DevOps Services. Ao analisar o arquivo, é importante entender como a migração de identidade opera e o que os resultados potenciais podem implicar. Quando você migra uma identidade, ela pode se tornar ativa ou histórica. As identidades ativas podem entrar nos Serviços de DevOps do Azure, mas as identidades históricas não.

Identidades ativas

As identidades ativas referem-se às identidades de usuário nos Serviços de DevOps do Azure após a migração. Nos Serviços de DevOps do Azure, essas identidades são licenciadas e exibidas como usuários na organização. As identidades são marcadas como ativas na coluna de Status de Importação Esperada no ficheiro 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 ficheiro de registo do mapa de identidade. 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 já não trabalha na 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çam como utilizadores na organização. Tudo o que persiste é a noção do nome dessa identidade na organização, para que a sua história possa ser pesquisada mais tarde. Recomendamos que você use identidades históricas para usuários que não trabalham mais na empresa ou que não precisam de mais acesso à organização.

Compreender o ficheiro de log do mapa de identidade

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

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 No Match Found (Verifique Microsoft Entra ID Sync) para entender por que eles não fazem parte do Microsoft Entra Connect Sync.

Ao ler o ficheiro, observe se o valor na coluna Status de importação esperado é Ativo ou Histórico. Ativo indica que a identidade nesta linha é mapeada corretamente e se torna ativa durante a migração. Histórico significa que as identidades se tornam históricas na migração. É importante revisar o arquivo de mapeamento gerado para verificar se há integridade e correção.

1. Revise as identidades corretamente correspondidas. Todas as identidades esperadas estão presentes? Os utilizadores são mapeados à identidade correta do Microsoft Entra?

   Se algum valor precisar ser atualizado, entre em contato com o administrador do Microsoft Entra para garantir que a identidade do Ative Directory local esteja sincronizada com a ID do Microsoft Entra e configurada corretamente. Para obter mais informações, consulte Integrar suas identidades locais com o Microsoft Entra ID.

2. Em seguida, analise as identidades que são 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 Ative Directory local e o Microsoft Entra ID.
   • A identidade ainda não está preenchida no seu ID do Microsoft Entra (por exemplo, há um novo funcionário).
   • A identidade não existe na sua instância do Microsoft Entra.
   • O usuário que possui essa identidade não trabalha mais na empresa.

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

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

Identidades históricas (equipas 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 desta forma resulta na importação de todos os utilizadores como histórico. É altamente recomendável que você configure o Microsoft Entra Connect para garantir que seus usuários sejam importados como ativos.

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

Para migrar todas as identidades como históricas, siga as etapas descritas nas seções posteriores. Quando se enfileira uma migração, a identidade usada para enfileirar a migração é integrada na organização como proprietário da organização. Todos os outros utilizadores são importados como históricos. Os proprietários da organização podem adicionar os utilizadores novamente usando a sua identidade Microsoft Entra. Os usuários adicionados são tratados como novos usuários. Eles não têm propriedade sobre a sua história, e não há como reassociar essa história à identidade Microsoft Entra. No entanto, os utilizadores ainda podem procurar o seu histórico de pré-migração pesquisando pelo \<domain>\<Active Directory username>.

A Ferramenta de Migração de Dados exibirá um aviso se detetar o cenário de identidades históricas completas. Se decidir seguir este caminho de migração, terá de consentir na ferramenta em relação às limitações.

Subscrições do Visual Studio

A Ferramenta de Migração de Dados não pode detetar 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 de licença automática após a migração. Desde que as contas de trabalho dos usuários estejam vinculadas corretamente, os Serviços de DevOps do Azure aplicam automaticamente seus benefícios de assinatura do Visual Studio na primeira entrada após a migração. Você nunca será cobrado por licenças atribuídas durante a migração, e assim pode gerir as assinaturas com segurança depois.

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 nos Serviços de DevOps do Azure. A vinculação de subscrição do Visual Studio decorre fora do escopo de uma migração. Desde que a conta profissional esteja vinculada corretamente antes ou depois da migração, as licenças dos usuários são atualizadas automaticamente no próximo login. 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 seu primeiro login na organização.

Prepare para a migração

Agora tens tudo pronto para executar a tua migraçã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 no Azure. A preparação para a migração consiste nas cinco etapas a seguir.

Passo 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 para uma conta de armazenamento do Azure.
Etapa 4: Gere um token SAS para acessar a conta de armazenamento.
Etapa 5: Conclua a especificação de migração.

Passo 1: Separe a sua coleção

Separar 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 do Servidor de DevOps do Azure enquanto a coleção está anexada e online. Quando uma coleção é desanexada da instância do Azure DevOps Server, ela pega uma cópia desses dados de identidade e a empacota com a coleção para transporte. Sem esses dados, a parte de identidade da migração não pode ser executada.

É importante pesar o custo de optar por ter um tempo de inatividade zero para uma execução de teste. Ele requer fazer backups do banco de dados de coleta e configuração, restaurá-los em uma instância SQL e, em seguida, criar um backup desanexado. Uma análise de custos pode provar que dedicar apenas algumas horas de interrupção para realizar diretamente o backup autónomo é 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 os Serviços de DevOps do Azure. No entanto, depois que o tamanho de um banco de dados de coleção excede um determinado limite, os benefícios do uso de um DACPAC começam a diminuir.

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 nos Serviços de DevOps do Azure, para que você possa usá-lo como o método de empacotamento para obter os dados da sua coleção na nuvem.

Baixe e instale SqlPackage.exe usando o instalador MSI mais recente das notas de lançamento do SqlPackage.

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

Ao gerar um DACPAC, tenha duas considerações em mente: o disco no qual o DACPAC está salvo e o espaço em disco na máquina que está gerando o DACPAC. Você deseja garantir que você tenha espaço em disco suficiente para concluir a operação.

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

Pode achar que o disco C é demasiado pequeno para suportar a 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 um de cada vez. O espaço máximo necessário para executar a geração é aproximadamente equivalente ao tamanho da maior tabela no banco de dados da coleção. Se salvares o DACPAC gerado na drive C, considera o tamanho da base de dados de coleção como relatado no ficheiro DataMigrationTool.log de uma execução de validação.

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

[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

Certifique-se de que a unidade que hospeda seu diretório temporário tenha pelo menos tanto espaço livre. Se isso não acontecer, você precisará redirecionar o diretório temp definindo uma variável de ambiente.

SET TEMP={location on disk}

Outra consideração é onde os dados do DACPAC são salvos. Apontar o local de armazenamento salvo para uma unidade remota distante pode resultar em tempos de geração mais demorados. Se uma unidade rápida, como uma unidade de estado sólido (SSD), estiver disponível localmente, recomendamos que direcione a unidade como o local de armazenamento do DACPAC. Caso contrário, é sempre mais rápido usar um disco que esteja na máquina onde reside o banco de dados de coleta em vez de uma unidade remota.

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

Abra uma janela do Prompt de Comando e vá para o diretório onde se encontra o SqlPackage.exe. Para gerar o DACPAC, substitua os valores temporários pelos valores necessários e, em seguida, 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 do SQL Server que hospeda seu banco de dados de coleção do Azure DevOps Server.
• Catálogo inicial: o nome do banco de dados de coleção.
• targetFile: O local no disco e o nome do arquivo DACPAC.

Um comando de geração de DACPAC que está sendo executado na própria camada de dados do Servidor de DevOps do Azure é 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 coleta Foo chamado Foo.dacpac.

Configurar sua coleção para migração

Depois que o banco de dados de coleção for restaurado em sua VM do Azure, configure uma entrada SQL para permitir que os Serviços de DevOps do Azure se conectem ao banco de dados para migrar os dados. Este login permite apenas acesso de leitura a uma única base de dados.

Para começar, abra o 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 um logon SQL para o banco de dados e atribua a esse logon 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 parecidos com o 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'

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.

   

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

   

2. Preencha 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.

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 os Serviços de DevOps do Azure. Após a conclusão da migração, certifique-se de remover os dados de autenticação SQL ou modificar a senha. A Microsoft não retém as informações de início de sessão após a conclusão da migração.

Etapa 3: Carregue o arquivo DACPAC

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 nos locais geográficos corretos.

Os Serviços de DevOps do Azure estão disponíveis em vários locais geográficos. Ao importar para esses locais, é fundamental colocar os 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 possa ser iniciada. A tabela a seguir lista os locais geográficos aceitáveis para criar sua conta de armazenamento e carregar seus dados.

Embora os Serviços de DevOps do Azure estejam disponíveis em vários locais geográficos nos EUA, apenas o local Central dos Estados Unidos aceita novos Serviços de DevOps do Azure. No momento, não é possível migrar seus dados para outros locais do Azure dos EUA.

Crie um contêiner de blob a partir do portal do Azure. Após criar o contentor, carregue o ficheiro DACPAC da 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 AzCopy ou qualquer outra ferramenta do explorador de armazenamento do Azure.

Etapa 4: Gerar um token SAS

Um token de assinatura de acesso compartilhado (SAS) fornece acesso delegado a recursos em uma conta de armazenamento. O token permite que você dê à 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 realizar as seguintes tarefas:

1. Selecione apenas Ler e Listar como permissões para seu token SAS. Nenhuma outra permissão é necessária.
2. Estabeleça um prazo de validade não superior a sete dias no futuro.
3. Restrinja o acesso apenas aos IPs dos Serviços de DevOps do Azure.
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 mais tarde, 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 a partir do script e copiada na etapa anterior.
• Dacpac: Certifique-se de que o ficheiro, incluindo a extensão . dacpac , tem o mesmo nome que o ficheiro DACPAC que carregou para a conta de armazenamento.

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

Determinar o tipo de migração

As importações podem ser enfileiradas como um processo de teste (DryRun) ou um processo de produção (ProductionRun). O parâmetro ImportType determina o tipo de migração:

• DryRun: Também conhecido como execução de teste. Utilização para fins de teste e validação. 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 use a organização em tempo integral nos Serviços de DevOps do Azure após a conclusão da migração.

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. Certifique-se de tomar nota desta data e planeie em conformidade.

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 um novo. 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, certifique-se de excluir todas as organizações anteriores dos Serviços de DevOps do Azure que você criou em uma execução de teste anterior. Para obter mais informações, consulte Excluir organização.

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 algum problema 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 testes de execução, pode ver com antecedência como é uma migração, identificar possíveis problemas e ganhar experiência antes de realizar a execução em produçã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çares, verifica se a política não está definida ou se existe uma exceção para o utilizador que está a fazer a migração. Para obter mais informações, consulte Restringir a criação de organizações através da política de locatário do Microsoft Entra.
• Os Serviços de DevOps do Azure não dão suporte a políticas de retenção por pipeline e elas não são transferidas para a versão hospedada.

Considerações para planos de reversão

Uma preocupação comum para as equipes que fazem uma execução final de produção é seu 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 à Ferramenta de Migração de Dados para Azure DevOps.

A reversão para a produção final é bastante simples. Antes de colocar a migração na fila, desassocie a coleção de projetos de equipa do Azure DevOps Server, tornando-a indisponível para os membros da equipa. Se, por qualquer motivo, você precisar reverter a execução de produção e colocar o servidor local online novamente para os membros da sua equipe, poderá fazê-lo. Anexe a coleção de projetos de equipe no local novamente e informe sua equipe de que eles continuam a trabalhar normalmente enquanto sua equipe se reagrupa para entender possíveis falhas.

Em seguida, você pode entrar em contato com o suporte ao cliente dos Serviços de DevOps do Azure para obter ajuda com a compreensão da causa da falha, se não puder determinar a causa. Para obter mais informações, consulte o artigo Solução de problemas. Os tickets de suporte ao cliente podem ser abertos na página https://aka.ms/AzureDevOpsImportSupportseguinte. Se o problema exigir o envolvimento de engenheiros do grupo de produtos, esses casos serão tratados durante o horário comercial normal.

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

Antes de gerar um backup do banco de dados SQL, você deve desanexar completamente a coleção do Azure DevOps Server (não SQL) usando a Ferramenta de Migração de Dados. O processo de desanexação no Servidor de DevOps do Azure transfere informações de identidade do usuário armazenadas fora do banco de dados de coleta, tornando-as portáteis para mover para um novo servidor ou, neste caso, para os Serviços de DevOps do Azure.

A desanexação de uma coleção é feita facilmente a partir da Consola de Administração do Azure DevOps Server na sua instância do Azure DevOps Server. Para obter mais informações, consulte Mover coleção de projetos, Desanexar a coleção.

Colocar a migração na fila

Inicie uma migração usando o comando import da Ferramenta de Migração de Dados. O comando import 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 bem-sucedido, enfileira uma migração para os Serviços de DevOps do Azure. O comando import requer uma conexão com a Internet, mas não* requer uma conexão com sua instância do 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 a orientação e a ajuda para o comando import:

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 importaçã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 contra o qual o arquivo de log do mapa de identidade foi criado. O usuário conectado é o proprietário da organização importada.

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 depois de enfileirar a migração, 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 e-mail é 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 quando estiver se preparando para migrar. Depois de corrigir cada erro, execute novamente o comando migrator validate para verificar a resolução.

Próximos passos

Conteúdo relacionado

• Visão geral da migração
• Tarefas pós-migração