Processos de validação e importação
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Este artigo orienta você pela preparação necessária para obter uma importação para os Serviços de DevOps do Azure pronta para ser executada. Se você encontrar erros durante o processo, consulte Solucionar problemas de erros de importação e migração.
Pré-requisitos
- Você deve configurar um locatário do Microsoft Entra conforme descrito em Microsoft Entra Connect Sync: Faça uma alteração na configuração padrão. A ferramenta de migração de dados configura um link para seu locatário do Microsoft Entra quando sua organização dos Serviços de DevOps do Azure é criada como parte do início do processo de importação. Quando você sincroniza seu Active Directory local com a ID do Microsoft Entra, os membros da equipe podem usar as mesmas credenciais para autenticar e os administradores dos Serviços de DevOps do Azure podem usar seus grupos do Active Directory para definir permissões em sua organização dos Serviços de DevOps do Azure. Para configurar a sincronização, use a tecnologia Microsoft Entra Connect.
- Antes de começar as tarefas de importação, marcar para garantir que você esteja executando uma versão com suporte do Azure DevOps Server.
- Recomendamos que você use o guia de migração passo a passo para progredir na importação. O guia vincula-se à documentação técnica, às ferramentas e às práticas recomendadas.
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 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.
Copiar o arquivo zip para uma das camadas de aplicativo do Servidor de DevOps do Azure
Descompacte o arquivo . Você também pode executar a ferramenta de uma máquina diferente sem o Servidor de DevOps do Azure instalado, desde que o computador possa se conectar ao banco de dados de configuração da instância do Servidor de DevOps do Azure.
Abra uma janela do Prompt de Comando no servidor e insira um comando cd para alterar para o diretório em que a ferramenta de migração de dados está armazenada. Reserve alguns momentos para revisar o conteúdo de ajuda da ferramenta.
a. Para exibir a ajuda e as diretrizes de nível superior, execute o seguinte comando:
Migrator /helpb. Exiba o texto da ajuda para o comando:
Migrator validate /helpComo sua primeira vez validando uma coleção, vamos mantê-la simples. Seu comando deve ter a seguinte estrutura:
Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}Onde
{name}fornece o nome do locatário do Microsoft Entra, por exemplo, para ser executado no DefaultCollection e no locatário fabrikam , o comando gostaria do exemplo:Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}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 nenhum dado ou estrutura na coleção. Ele lê a coleção apenas para identificar problemas.
Depois que a validação for concluída, você poderá exibir os arquivos de log e os resultados.
Durante a validação, você receberá um aviso se alguns de seus pipelines contiverem 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 em nível de projeto padrão. 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 importaçã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 erros de importação e migração.
Importar arquivos de log
Quando você abre 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 importar 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 o impedem de importar para os Serviços de DevOps do Azure.
Gerar arquivos de importação
A ferramenta de migração de dados validou a coleta 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 importação. Ao executar o prepare comando, você gera dois arquivos de importação:
- IdentityMapLog.csv: Descreve seu mapa de identidade entre o Active Directory e a ID do Microsoft Entra.
- import.json: exige que você preencha a especificação de importação que deseja usar para iniciar a migração.
Comando Preparar
O prepare comando auxilia na geração dos arquivos de importação necessários. Essencialmente, esse comando verifica a coleção para localizar uma lista de todos os usuários para preencher o log de mapa de identidade, IdentityMapLog.csv e, em seguida, tenta se conectar à ID do Microsoft Entra para localizar 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ório. O arquivo de especificação de importação, import.json, deve ser preenchido antes da importação.
Ao contrário do comando, preparerequer uma conexão com a validate Internet, porque ele precisa se conectar ao Microsoft Entra ID para preencher o arquivo de log do mapa de identidade. Se sua instância do Servidor de DevOps do Azure não tiver acesso à Internet, execute a ferramenta de uma máquina 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 seguinte exemplo:
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 com sua coleção desde a última validação completa. Se novos problemas forem detectados, nenhum arquivo de importaçã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 pertence ao domínio do locatário, que é especificado no comando. Certifique-se de que o locatário especificado do Microsoft Entra é aquele com o qual você deseja que sua organização futura receba backup. 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 importaçã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 importação de identidade quando você inicia a execução de produção com o locatário do Microsoft Entra de produção 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 importação. No diretório de log, localize uma pasta de logs e dois arquivos:
- import.json é o arquivo de especificação de importação. Recomendamos que você tenha tempo para preenchê-lo.
- IdentityMapLog.csv contém o mapeamento gerado do Active Directory para identidades do Microsoft Entra. Examine-o para obter integridade antes de iniciar uma importação.
Os dois arquivos são descritos com mais detalhes nas próximas seções.
O arquivo de especificação de importação
A especificação de importação, import.json, é um arquivo JSON que fornece configurações de importaçã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 tentar uma importação.
Os campos exibidos e as ações necessárias do arquivo import.json são descritos na tabela a seguir:
| Campo | Descrição | Ação necessária |
|---|---|---|
| Fonte | Informações sobre o local e os nomes dos arquivos de dados de origem que são usados para importaçã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 importaçã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 importaçã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 nesse processo. |
| Destino | Propriedades da nova organização para a qual importar. | 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 importação. | Forneça um nome. O nome pode ser alterado rapidamente mais tarde após a conclusão da importação. Observação : não crie uma organização com esse nome antes de executar a importação. A organização é criada como parte do processo de importação. |
| ImportType | O tipo de importação que você deseja executar. | Nenhuma ação é necessária. Em uma etapa posterior, selecione o tipo de importação a ser executado. |
| Dados de validação | Informações necessárias para ajudar a impulsionar sua experiência de importaçã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 importação. Não edite os valores nesta seção, ou sua importação pode falhar ao iniciar. |
Depois de concluir o processo anterior, você deve ter um arquivo semelhante ao exemplo a seguir.
Na imagem anterior, o planejador da importação da Fabrikam adicionou o nome da organização fabrikam-import e selecionou CUS (Central United States) como o local geográfico para importaçã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 a seco têm um '-dryrun' anexado automaticamente ao final do nome da organização, que pode ser alterado após a importação.
Localizações geográficas do Azure com suporte para importação
Os Serviços de DevOps do Azure estão disponíveis em vários locais geográficos do Azure. Mas, nem todos os locais onde os Serviços de DevOps do Azure estão disponíveis têm suporte para importação. A tabela a seguir lista os locais geográficos do Azure que você pode selecionar para importação. Também está incluído o valor que você precisa colocar no arquivo de especificação de importação para direcionar essa geografia para importaçã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 de mapa de identidade é de igual importância para os dados reais que você migra para os Serviços de DevOps do Azure. Ao examinar o arquivo, é importante entender como a importação de identidade opera e o que os resultados potenciais podem implicar. Quando você importa 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 podem.
Identidades ativas
As identidades ativas referem-se às identidades de usuário nos Serviços de DevOps do Azure após a importaçã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 de mais 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:
As colunas no arquivo de log do mapa de identidade são descritas na tabela a seguir:
Você e seu administrador do Microsoft Entra devem investigar os usuários marcados como Sem correspondência encontrada (Verificar sincronização de ID do Microsoft Entra) para entender por que eles não fazem parte do Microsoft Entra Connect Sync.
| 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 (Serviços de DevOps do Azure) | O endereço de entrada esperado do usuário correspondente em breve ou No Match Found (Check Microsoft Entra ID Sync), que indica que a identidade não foi encontrada durante o Microsoft Entra ID Sync e é importada como histórica. |
| Status de importação esperado | O status de importação de 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 na importação torna-se ativa. Histórico significa que as identidades se tornam históricas na importação. É importante examinar o arquivo de mapeamento gerado quanto à integridade e à correção.
Importante
A importação falhará se ocorrerem alterações importantes na sincronização da ID de segurança do Microsoft Entra Connect entre as tentativas de importação. Você pode adicionar novos usuários entre execuções secas e pode fazer correções para garantir que as identidades históricas importadas anteriormente se tornem ativas. No entanto, não há suporte para a alteração de um usuário existente que foi importado anteriormente como ativo no momento. Isso faz com que sua importação falhe. Um exemplo de alteração pode ser concluir uma importação a seco, 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, em seguida, tentar outra importação. Nesse caso, uma importação de identidade ativa tenta entre o Active Directory e a identidade recém-criada do Microsoft Entra, mas causa uma falha de importação.
Revise as identidades correspondidas 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 o Microsoft Entra ID.
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 foi preenchida na sua ID do Microsoft Entra (por exemplo, há um novo funcionário).
- A identidade não existe na 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 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, 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 importaçã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 importação dessa forma faz com que todos os usuários sejam 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 importação com todas as identidades históricas tem consequências que precisam ser consideradas com cuidado. Apenas 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 importar todas as identidades como históricas, siga as etapas descritas em seções posteriores. Quando você enfileira uma importação, a identidade usada para enfileirar a importaçã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 nenhuma de suas histórias, e não há como redirecionar essa história para a identidade do Microsoft Entra. No entanto, os usuários ainda podem procurar seu histórico de pré-importação pesquisando seu nome> de usuário do Active Directory de domínio.<><
A ferramenta de migração de dados exibirá um aviso se detectar o cenário de identidades históricas completas. 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 importação. Desde que as contas corporativas dos usuários sejam vinculadas corretamente, Azure DevOps Services aplica automaticamente seus benefícios de assinatura do Visual Studio na primeira entrada após a importação. Você nunca é cobrado por licenças atribuídas durante a importação, para que você possa lidar com assinaturas com segurança depois.
Você não precisará repetir uma importação de execução seca se as assinaturas do Visual Studio dos usuários não forem atualizadas automaticamente no Azure DevOps Services. A vinculação de assinatura do Visual Studio ocorre fora do escopo de uma importação. Desde que sua conta corporativa esteja vinculada corretamente antes ou depois da importação, as licenças dos usuários são atualizadas automaticamente na próxima entrada. Depois que suas licenças forem atualizadas com êxito, na próxima vez que você executar uma importação, os usuários serão atualizados automaticamente em sua primeira entrada na organização.
Preparar-se para importação
Agora você tem tudo pronto para executar em sua importação. 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 importação, carregue os ativos necessários gerados e uma cópia do banco de dados no Azure. A preparação para a importação consiste nas cinco etapas a seguir.
Etapa 1: coloque a coleção offline e desanexe-a.
O limite de tamanho da coleção para o método DACPAC é de 150 GB. 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 importação usando o método de VM (máquina virtual) SQL Azure. Ignore as etapas 2 a 5 nesse caso e siga as instruções fornecidas em Importar grandes coleções e continue na seção determinar o tipo de importação.
Etapa 2: gerar um arquivo DACPAC da coleção que você vai importar.
Etapa 3: carregue o arquivo DACPAC e importe arquivos para 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 importação.
Observação
Antes de executar uma importação de produção, é altamente recomendável que você conclua uma importação de execução seca. Com uma execução seca, você pode validar se o processo de importação funciona para sua coleção e que não há formas de dados exclusivas presentes que possam causar uma falha na importação de produção.
Etapa 1: Desanexar sua coleção
Desanexar a coleção é uma etapa crucial no processo de importaçã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 importação não pode ser executada. Recomendamos que você mantenha a coleção desanexada até que a importação seja concluída, pois não há uma maneira de importar as alterações que ocorreram durante a importação.
Para uma importação de execução seca (teste), recomendamos que você reanexe sua coleção depois de fazer backup dela para importação, para que você não esteja preocupado em ter os dados mais recentes para esse tipo de importação. Para evitar o tempo offline completamente, você também pode optar por empregar uma desanexação offline para corridas secas.
É importante pesar o custo de optar por incorrer em tempo de inatividade zero para uma corrida a seco. 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 tempo de inatividade para fazer o backup desanexado diretamente é 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, será necessário executar a importação usando o método SQL Azure VM (máquina virtual) fornecido em Importar grandes coleções.
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
- Quando você usa SqlPackage.exe, você deve usar a versão do .NET Framework do SqlPackage.exe para preparar o DACPAC. O instalador MSI deve ser usado para instalar a versão do .NET Framework do SqlPackage.exe. Não use a CLI dotnet ou as versões .zip (Windows .NET 6) do SqlPackage.exe porque essas versões podem gerar DACPACs incompatíveis com os Serviços de DevOps do Azure.
- 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 MSI Installer mais recente das notas de versão 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, lembre-se de duas considerações: 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 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 no banco de dados da 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 de salvamento 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 você 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 importação
Depois que o banco de dados de coleta 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 importar os dados. Esse login 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 essa entrada a '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 [Foo] SET RECOVERY SIMPLE;
USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'
Observação
Certifique-se de habilitar SQL Server e autenticação do Windows modo em SQL Server Management Studio na VM. Se você não habilitar o modo de autenticação, a importação falhará.
Configurar o arquivo de especificação de importação para direcionar a VM
Atualize o arquivo de especificação de importação para incluir informações sobre como se conectar à instância SQL Server. Abra o arquivo de especificação de importação e faça as seguintes atualizações.
Remova o parâmetro DACPAC do objeto de arquivos de origem.
A especificação de importação antes da alteração é mostrada no código a seguir.
A especificação de importação após a alteração é mostrada no código a seguir.
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 importação se parece com o exemplo a seguir.
Sua especificação de importação agora está configurada para usar uma VM SQL Azure para importação. Prossiga com o restante das etapas de preparação para importar para Azure DevOps Services. Após a conclusão da importação, exclua a entrada SQL ou gire a senha. A Microsoft não retém as informações de entrada após a conclusão da importaçã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 nos locais geográficos certos.
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 importação possa ser iniciada com êxito. Seus dados devem ser colocados no mesmo local geográfico para o qual você está importando. Colocar os dados em qualquer outro lugar faz com que a importaçã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.
| Localização geográfica de importaçã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 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. Você não pode importar seus dados para outros locais do Azure dos EUA no momento.
Você pode criar um contêiner de blob do portal do Azure. Depois de criar o contêiner, carregue o arquivo DACPAC de coleção.
Após a conclusão da importação, exclua o contêiner de blob e a conta de armazenamento que o acompanha com ferramentas de uso, como 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ê dê à Microsoft o nível mais baixo de privilégio necessário para acessar seus dados para executar a importação.
Os tokens SAS podem ser gerados usando o portal do Azure. Do ponto de vista de segurança, recomendamos:
- Selecione apenas Ler e Listar como permissões para seu token SAS. Nenhuma outra permissão é necessária.
- Estabeleça um prazo de validade não superior a sete dias no futuro.
- Restrinja o acesso somente aos IPs dos Serviços de DevOps do Azure.
- Coloque o token SAS em um local seguro.
Etapa 5: Concluir a especificação de importação
No início do processo, você preencheu parcialmente o arquivo de especificação de importação, conhecido como import.json. Neste ponto, você tem informações suficientes para concluir todos os campos restantes, exceto o tipo de importação. O tipo de importação é abordado posteriormente, na seção de importação.
No arquivo de especificação import.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 importação final deve se parecer com o exemplo a seguir.
Restringir o acesso somente a IPs Azure DevOps Services
Para obter mais informações, consulte Restringir o acesso somente a IPs dos Serviços de DevOps do Azure.
Opção 1: Usando tags de serviço
Você pode permitir facilmente conexões de todos os locais geográficos dos Serviços de DevOps do Azure adicionando a azuredevopsMarca de Serviço aos seus firewalls ou grupos de segurança de rede por meio do portal ou programaticamente.
Opção 2: Usando IpList
Use o IpList comando para obter a lista de IPs que precisam receber acesso para permitir conexões de um local geográfico específico dos Serviços de DevOps do Azure.
Incluídos na documentação de ajuda estão instruções e exemplos para executar o Migrador 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 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.
Determinar o tipo de importação
As importações podem ser enfileiradas como uma simulação ou uma execução de produção. O parâmetro ImportType determina o tipo de importação:
- DryRun: use uma simulação para fins de teste. O sistema exclui as execuções secas após 21 dias.
- ProductionRun: use uma execução de produção quando quiser manter a importação resultante e usar a organização em tempo integral em Azure DevOps Services após a conclusão da importação.
Dica
Sempre recomendamos que você conclua uma importação a seco primeiro.
Organizações de execução a seco
As importações a seco ajudam as equipes a testar a migração de suas coleções. Espera-se que as organizações não permaneçam por perto para sempre, mas existam por um curto período de tempo. Na verdade, antes que uma migração de produção possa ser executada, todas as organizações de execução a seco concluídas devem ser excluídas. Todas as organizações de dry-run 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 email de sucesso que você deve receber após a conclusão da importação. Anote essa data e planeje-se adequadamente.
A maioria das organizações a seco tem 15 dias antes de serem excluídas. As organizações de dry-run também poderão ter uma expiração de 21 dias se mais de 100 usuários tiverem uma licença básica ou maior no momento da importação. Após o período de tempo especificado, a organização de execução seca é excluída. Você pode repetir as importações de dry-run quantas vezes precisar antes de fazer uma migração de produção. Você precisa excluir as execuções secas 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 seca.
Para obter mais informações sobre atividades pós-importação, consulte o artigo pós-importação .
Se você encontrar problemas de importação, consulte Solucionar problemas de importação e migração.
Executar uma importação
Sua equipe agora está pronta para iniciar o processo de execução de uma importação. Recomendamos que você comece com uma importação de simulação bem-sucedida antes de tentar uma importação de execução de produção. Com as importações a seco, você pode ver com antecedência a aparência de uma importação, identificar possíveis problemas e ganhar experiência antes de entrar na produção.
Observação
- Se você precisar repetir uma importação concluída de execução de produção para uma coleção, como no caso de uma reversão, entre em contato com Azure DevOps Services Atendimento ao Cliente antes de enfileirar outra importaçã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, sua importaçã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.
- 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 sobre 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 importação. É altamente recomendável fazer uma execução seca para garantir que você possa testar as configurações de importação fornecidas à ferramenta de migração de dados para o Azure DevOps.
A reversão para a execução final de produção é bastante simples. Antes de enfileirar a importação, você desanexa a coleção de projetos de equipe do Servidor de DevOps do Azure, 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 no local novamente e informe sua equipe de que eles continuam a trabalhar normalmente enquanto sua equipe se reagrupa para entender quaisquer falhas potenciais.
Enfileirar uma importaçã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 importação falhará. Caso sua importação falhe, confira Solucionar problemas de erros de importação e migração.
Inicie uma importação usando o comando import da ferramenta de migração de dados. O comando import usa um arquivo de especificação de importação como entrada. Ele analisa o arquivo para garantir que os valores fornecidos sejam válidos e, se bem-sucedidos, ele enfileira uma importação para Azure DevOps Services. O comando import requer uma conexão com a Internet, mas não exige* uma conexão com sua instância do Servidor de DevOps do Azure.
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 importação:
Migrator import /help
O comando para enfileirar uma importação tem a seguinte estrutura:
Migrator import /importFile:{location of import specification file}
O exemplo a seguir mostra um comando de importação concluído:
Migrator import /importFile:C:\DataMigrationToolFiles\import.json
Depois que a validação passar, você será solicitado a entrar no Microsoft Entra ID. É importante entrar 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 é 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 importação, uma notificação por email é enviada ao usuário que enfileira a importação. Cerca de 5 a 10 minutos depois que ele enfileira a importação, sua equipe pode ir para a organização para marcar no status. Após a conclusão da importação, sua equipe é direcionada para entrar e uma notificação por email é enviada para o proprietário da organização.
Artigos relacionados
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de