Ler em inglês

Compartilhar via

Visão geral da migração

  • Artigo

Migrar de Azure DevOps Server para Azure DevOps Services é uma etapa essencial para organizações que desejam aproveitar a colaboração, a escalabilidade e os recursos aprimorados baseados em nuvem. Nesta visão geral, exploramos as opções para transferir seus dados valiosos do Azure DevOps Server local para o Azure DevOps Services baseado em nuvem.

Para obter informações sobre as principais diferenças entre Azure DevOps Server local e Azure DevOps Services baseado em nuvem, consulte Comparar Azure DevOps Services com Azure DevOps Server – Azure DevOps.

Independentemente da opção de migração selecionada, recomendamos que você determine seus ativos mais importantes, como código-fonte e itens de trabalho. Você deve pensar no tamanho dos dados, na complexidade da organização e garantir que tenha tempo suficiente para execuções de teste antes da migração real para uma transição tranquila e bem-sucedida.

Abordagens de migração

É crucial avaliar os prós e os contras de cada abordagem de migração, com base em suas motivações específicas para adotar Azure DevOps Services. A estratégia certa depende do seu contexto e requisitos exclusivos.

Opções Cenários recomendados Limitações
1: Migração manual Use para projetos menores ou subconjuntos de dados específicos. Nem todos os dados podem ser migrados com fidelidade total e estão sujeitos a limitação. Essa migração não dá suporte à migração de modelos XML, portanto, você precisa recriar modelos de processo como modelos herdados.
2: Ferramenta de migração de dados do Azure DevOps Use para migrações de média a grande escala com tipos de dados variados e estruturas complexas. Você só pode "lift-and-shift" uma coleção Azure DevOps Server para uma nova organização Azure DevOps Services, sem modificações. Para obter mais informações, confira a Seção de Limitações.
3: Migração baseada em API Oferece flexibilidade e personalização para organizações com requisitos exclusivos de migração ou necessidades de automação. Podem ocorrer baixa fidelidade, perda de dados e alterações de ID. Para obter mais informações, confira a Seção de Limitações.

Opção 1: migração manual

Por exemplo, quando a equipe do Azure DevOps na Microsoft optou por migrar do Azure DevOps Server para o Azure DevOps Services, também decidimos migrar do TFVC (Controle de Versão do Team Foundation) para o Git. A migração exigiu muito planejamento, mas quando migramos, criamos um novo repositório Git usando a versão "tip" de nossas fontes TFVC e deixamos nosso histórico para trás em Azure DevOps Server. Também movemos nossos itens de trabalho ativos e deixamos para trás todos os nossos bugs antigos, concluímos histórias de usuário e tarefas e assim por diante.

Processo de migração manual

  1. Identifique os ativos mais importantes que você precisa migrar – normalmente código-fonte, itens de trabalho ou ambos. Outros ativos em Azure DevOps Server – pipelines de build, planos de teste e assim por diante – são mais difíceis de migrar manualmente.
  2. Identifique um momento adequado para fazer a transição.
  3. Prepare suas organizações-alvo. Crie as organizações e os projetos de equipe necessários, provisione usuários e assim por diante.
  4. Migrar os dados.
  5. Considere tornar as implantações de origem Azure DevOps Server somente leitura. Você pode fazer isso das seguintes maneiras:
    • Ajustar permissões no nível do projeto: defina as permissões para todos os usuários ou grupos como somente leitura no nível do projeto, o que você pode fazer modificando os direitos de acesso nas configurações do projeto.
    • Modificar configurações do repositório: para cada repositório, você pode alterar as configurações para torná-las somente leitura, o que envolve ajustar as permissões de cada usuário ou grupo para permitir apenas ações de leitura.
    • Use grupos de segurança internos: utilize os grupos de segurança internos para gerenciar permissões com mais eficiência. Você pode atribuir usuários a grupos como "Leitores" para fornecer acesso somente leitura.
    • Alterações de permissão de script: se você tiver muitos projetos ou repositórios, talvez seja necessário criar scripts para eles. Você pode usar a extensão do DevOps da CLI do Azure para listar todas as permissões e atualizá-las conforme necessário.
    • Desabilitar recurso de repositório: desabilita o acesso ao repositório, incluindo builds e solicitações de pull, mas mantém o repositório detectável com um aviso. Vá para Configurações do>projeto Repositórios> seu repositório e, ao lado de Desabilitar repositório, mova a alternância para Ativado.

Opção 2: Ferramenta de Migração de Dados do Azure DevOps

A Ferramenta de Migração de Dados do Azure DevOps é um conjunto de utilitários fornecidos pela Microsoft para facilitar a migração de dados do Azure DevOps Server para o Azure DevOps Services. Essas ferramentas oferecem uma abordagem simplificada para migrar vários artefatos, incluindo código-fonte, itens de trabalho, casos de teste e outros dados relacionados ao projeto.

Antes de iniciar o processo de migração, as ferramentas podem executar uma análise de pré-migração para avaliar a prontidão do ambiente de origem e identificar possíveis problemas ou dependências que possam afetar a migração. Avalie a prontidão, para que você possa planejar e mitigar possíveis desafios com antecedência.

Limitações da ferramenta de migração

A ferramenta permite que você "lift-and-shift" de uma coleção Azure DevOps Server para uma nova organização de serviços Azure DevOps, sem modificações pelos seguintes motivos:

  • Integridade e consistência dos dados:
    • Quando você migra dados, manter a integridade e a consistência é crucial. Permitir modificações durante a migração pode levar à corrupção ou inconsistências de dados.
    • A ferramenta garante que os dados permaneçam intactos durante o processo de transferência, minimizando o risco de erros.
  • Preservação dos dados de origem:
    • A ferramenta de migração tem como objetivo replicar fielmente os dados de origem no ambiente de destino.
    • As modificações podem alterar os dados originais, potencialmente causando discrepâncias entre os dados migrados e os dados de origem.
  • Comportamento previsível:
    • Ao restringir as modificações, a ferramenta garante um comportamento previsível durante a migração.
    • Os usuários podem contar com resultados consistentes sem alterações inesperadas.
  • Foco na migração, não na transformação:
    • O objetivo principal da ferramenta de migração é mover dados de um local para outro.
    • A transformação de dados (como a modificação de valores) normalmente é tratada separadamente após a migração.

Você pode limpar os dados desnecessários antes ou depois da migração.

Processo da Ferramenta de Migração

  1. Conclua os pré-requisitos, como atualizar Azure DevOps Server para uma das duas versões mais recentes.
  2. Valide cada coleção que você deseja mover para Azure DevOps Services.
  3. Gere arquivos de migração.
  4. Prepare tudo para a execução da migração.
  5. Execute uma execução de teste.
  6. Realize uma migração.
  7. Confirme se os usuários e os dados foram migrados e se a coleção está funcionando conforme o esperado.

Opção 3: migração baseada em API

Se você não puder usar a Ferramenta de Migração de Dados, mas ainda quiser uma migração de fidelidade maior do que opção 2, considere usar várias ferramentas que aproveitam APIs públicas para mover dados. Essas ferramentas incluem extensões disponíveis no do Visual Studio Marketplace.

Limitações de migração baseadas em API

As seguintes limitações ocorrem com a migração baseada em API:

  • Migração de baixa fidelidade:
    • Limitação: as ferramentas baseadas em API fornecem uma fidelidade mais alta do que a cópia manual, mas ainda são relativamente baixas.
    • Implicação: embora essas ferramentas ofereçam alguma fidelidade, elas não preservam todos os aspectos de seus dados.
      • Exemplo: nenhum deles retém as datas originais dos conjuntos de alterações do TFVC (Controle de Versão do Team Foundation).
      • Muitos também não preservam as datas alteradas das revisões de item de trabalho.
  • Perda de dados e alterações de ID:
    • Limitação: durante a migração, as ferramentas reproduzem alterações de item de trabalho, conjuntos de alterações TFVC, feeds de pacotes e artefatos de pipeline.
    • Implicação: esse processo pode levar à perda de dados, gerar novos IDs e alterar as datas de criação, modificação e fechamento.
      • Exemplo: o contexto histórico vinculado a datas específicas pode se perder, afetando os relatórios e a rastreabilidade.

Processo de migração baseado em API

Em geral, só recomendamos essa abordagem se a fidelidade extra além de uma cópia manual for crítica. Se você decidir adotar essa abordagem, considere contratar um consultor que tenha experiência com uma ou mais das ferramentas e fazer uma migração de teste antes da migração final.

Muitas organizações precisam de uma migração de alta fidelidade apenas para um subconjunto de seu trabalho. O novo trabalho pode começar diretamente no Azure DevOps Services. Outros trabalhos, com requisitos de fidelidade menos rigorosos, podem ser migrados usando uma das outras abordagens.

Modelos de processo suportados

Azure DevOps Services dá suporte aos seguintes modelos de processo:

Por padrão, o XML hospedado está desativado em Azure DevOps Services. Ativaremos o modelo de processo XML hospedado durante a migração somente se você personalizou um projeto em Azure DevOps Server. Depois que seu projeto estiver no XML hospedado, você poderá atualizá-lo para a pós-migração herdada.

Principais princípios

Ao migrar para Azure DevOps Services, tenha em mente os seguintes princípios e limitações principais:

  • Azure DevOps Services é somente em inglês: Azure DevOps Server dá suporte a vários idiomas, no entanto, hoje, Azure DevOps Services dá suporte apenas ao inglês. Se sua coleção usa o idioma diferente do inglês ou usou o idioma diferente do inglês no passado e você converteu o idioma para o inglês durante uma atualização, não poderá usar a Ferramenta de Migração de Dados.
  • Herança: um projeto, que foi criado a partir do modelo de processo Agile, Scrum ou CMMI e nunca foi personalizado, está no modelo de processo de herança após a migração.
  • XML hospedado: qualquer projeto com personalizações usa o modelo de processo XML hospedado.
  • Processo por projeto personalizado: embora Azure DevOps Services permita que os projetos compartilhem um processo, a Ferramenta de Migração de Dados cria um processo XML hospedado para cada projeto de equipe personalizado. Por exemplo, se você tiver 30 projetos personalizados, terá 30 processos XML hospedados para gerenciar. Se você quiser personalizar ainda mais seu processo XML hospedado para todos os seus projetos, deverá atualizar cada processo XML hospedado separadamente.
  • Validação do processo: a validação do processo da Ferramenta de Migração de Dados detecta o modelo de processo de destino para cada projeto. Antes de migrar, você precisa corrigir quaisquer erros de validação de processo para os projetos XML hospedados. Você pode querer considerar atualizar o processo de seus projetos para corresponder a um de nossos processos (Agile, Scrum ou CMMI) para aproveitar o modelo de processo de herança. Saiba mais sobre os tipos de validação de processo em nossa documentação.

Recursos

Próximas etapas

Introdução à Ferramenta de Migração de Dados do Azure DevOps