Share via

Visão geral da migração

  • Artigo

Migrar do Servidor de DevOps do Azure para os Serviços de DevOps do Azure é 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 Servidor de DevOps do Azure local para os Serviços de DevOps do Azure baseados em nuvem.

Para obter informações sobre as principais diferenças entre o Servidor de DevOps do Azure local e os Serviços de DevOps do Azure baseados em nuvem, consulte Comparar os Serviços de DevOps do Azure com o Servidor de DevOps do Azure - 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 certificar-se de que tem tempo suficiente para execuções de teste antes da migração real para uma transição suave e bem-sucedida.

Abordagens de migração

É crucial avaliar os prós e contras de cada abordagem à migração, com base em suas motivações específicas para adotar os Serviços de DevOps do Azure. 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 oferece 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 "elevar e transferir" uma coleção do Servidor de DevOps do Azure para uma nova organização dos Serviços de DevOps do Azure, sem modificações. Para obter mais informações, consulte a seção 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. Baixa fidelidade, perda de dados e alterações de ID podem ocorrer. Para obter mais informações, consulte a seção Limitações.

Opção 1: Migração manual

Por exemplo, quando a equipe de DevOps do Azure na Microsoft optou por migrar do Servidor de DevOps do Azure para os Serviços de DevOps do Azure, também decidimos mudar 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 "dica" de nossas fontes do TFVC e deixamos nosso histórico para trás no Servidor de DevOps do Azure. Também movemos nossos itens de trabalho ativos e deixamos para trás todos os nossos bugs antigos, histórias de usuários e tarefas concluídas e assim por diante.

Processo de migração manual

  1. Identifique os ativos mais importantes que você precisa migrar - geralmente código-fonte, itens de trabalho ou ambos. Outros ativos no Servidor de DevOps do Azure - pipelines de compilação, 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 do Servidor de DevOps do Azure de origem 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 as funções de segurança nas configurações do Project.
    • 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.
    • Usar 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 criá-los. Você pode usar a extensão DevOps da CLI do Azure para listar todas as permissões e atualizá-las conforme necessário.
    • Desativar recurso de repositório: desabilita o acesso ao repositório, incluindo compilações e solicitações 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 Desativar repositório, mova o botão de alternância para Ativado.

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

A Ferramenta de Migração de Dados de DevOps do Azure é um conjunto de utilitários fornecidos pela Microsoft para facilitar a migração de dados do Servidor de DevOps do Azure para os Serviços de DevOps do Azure. 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ê "levante e desloque" uma Coleção de Servidores de DevOps do Azure para uma nova Organização de Serviço de DevOps do Azure, sem modificações pelos seguintes motivos:

  • Integridade e consistência dos dados:
    • Ao migrar dados, manter a integridade e a consistência é crucial. Permitir modificações durante a migração pode levar a corrupção de dados ou inconsistências.
    • 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 visa 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 modificações, a ferramenta garante um comportamento previsível durante a migração.
    • Os usuários podem confiar em resultados consistentes sem alterações inesperadas.
  • Foco na migração, não na transformação:
    • O principal objetivo 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 dados que não precisam antes ou depois da migração.

Processo da Ferramenta de Migração

  1. Conclua os pré-requisitos, como atualizar o Servidor de DevOps do Azure para uma das duas versões mais recentes.
  2. Valide cada coleção que você deseja mover para os Serviços de DevOps do Azure.
  3. Gerar arquivos de migração.
  4. Prepare tudo para a execução da migração.
  5. Execute uma execução de teste.
  6. Realizar 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, por algum motivo, você não puder usar a Ferramenta de Migração de Dados, mas ainda quiser uma migração de fidelidade maior do que a Opção 2, poderá escolher entre várias ferramentas que usam APIs públicas para mover dados.

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 maior 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 manté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 itens 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 do TFVC, feeds de pacotes e artefatos de pipeline.
    • Implicação: Esse processo pode levar à perda de dados, gerar novas 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 a geração de 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 para apenas um subconjunto de seu trabalho. Um novo trabalho pode ser iniciado diretamente nos Serviços de DevOps do Azure. Outros trabalhos, com requisitos de fidelidade menos rigorosos, poderiam ser migrados usando uma das outras abordagens.

Modelos de processo suportados

Os Serviços de DevOps do Azure dão suporte aos seguintes modelos de processo:

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

Principais princípios

Ao migrar para os Serviços de DevOps do Azure, lembre-se dos seguintes princípios e limitações principais:

  • Os Serviços de DevOps do Azure são apenas em inglês: o Servidor de DevOps do Azure dá suporte a vários idiomas, no entanto, atualmente, os Serviços de DevOps do Azure oferecem suporte apenas ao inglês. Se sua coleção usa o idioma diferente do inglês ou usado fora do inglês no passado e você converteu o idioma para o inglês durante uma atualização, não será possível 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 os Serviços de DevOps do Azure permitam 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, você deve atualizar cada processo XML hospedado separadamente.
  • Validação de processo: A validação de processo da Ferramenta de Migração de Dados detecta o modelo de processo de destino para cada projeto. Antes de poder migrar, você precisa corrigir quaisquer erros de validação de processo para os projetos XML hospedados. Você pode querer 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 DevOps do Azure