Descrição geral da migração
Mudar 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 as execuções de teste antes da migração real para uma transição suave e bem-sucedida.
Abordagens da migração
É crucial avaliar os prós e contras de cada abordagem à migração, com base nas suas motivações específicas para adotar os Serviços de DevOps do Azure. A estratégia certa depende do seu contexto e requisitos únicos.
| 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 total fidelidade 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 mudar" 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 mudar do Servidor de DevOps do Azure para os Serviços de DevOps do Azure, também decidimos mudar do Controle de Versão do Team Foundation (TFVC) 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 TFVC e deixamos nosso histórico para trás no Azure DevOps Server. Também movemos nossos itens de trabalho ativos e deixamos para trás todos os nossos bugs antigos, histórias de usuário e tarefas concluídas e assim por diante.
Processo de migração manual
- Identifique os ativos mais importantes que você precisa migrar - normalmente 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.
- Identifique um momento adequado para fazer a transição.
- Prepare suas organizações-alvo. Crie as organizações e os projetos de equipe de que você precisa, provisione usuários e assim por diante.
- Migre seus dados.
- Considere tornar as implantações do Azure DevOps Server de origem somente leitura. Pode fazê-lo das seguintes formas:
- 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 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 para 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 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 detetável com um aviso. Vá para Configurações do>projeto Repositórios> seu repositório e, ao lado de Desativar 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 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 mude" 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 as 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 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 dados de que não precisa antes ou depois da migração.
Processo da Ferramenta de Migração
- Conclua os pré-requisitos, como atualizar o Azure DevOps Server para uma das duas versões mais recentes.
- Valide cada coleção que você deseja mover para os Serviços de DevOps do Azure.
- Gere arquivos de migração.
- Prepare tudo para a execução da migração.
- Execute uma execução de teste.
- Realizar uma migração.
- 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 aspetos 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 TFVC, feeds de pacote e artefatos de pipeline.
- Implicação: Este processo pode levar à perda de dados, gerar novos IDs e alterar datas de criação, modificação e encerramento.
- 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 potencialmente começar 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 Azure DevOps Server. Quando seu projeto estiver em XML hospedado, você poderá atualizá-lo para pós-migração herdada.
Princípios-chave
Ao migrar para os Serviços de DevOps do Azure, tenha em mente os 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 suporta vários idiomas, no entanto, atualmente, os Serviços de DevOps do Azure suportam apenas inglês. Se sua coleção usa o idioma diferente do inglês ou não o inglês no passado e você converteu o idioma para 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 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 do processo: A validação do processo da Ferramenta de Migração de Dados deteta 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 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 processos em nossa documentação.