Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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.
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
- 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.
- Identifique um momento adequado para fazer a transição.
- Prepare suas organizações-alvo. Crie as organizações e os projetos de equipe necessários, provisione usuários e assim por diante.
- Migrar os dados.
- 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ê "levante e mude" uma coleção de servidores do Azure DevOps para uma nova Organização do Azure DevOps Services, sem modificações pelos seguintes motivos:
Por que nenhuma modificação é permitida
- Integridade e consistência de dados: modificações durante a migração podem levar à corrupção de dados ou inconsistências.
- Preservação de dados de origem: a ferramenta replica fielmente os dados de origem sem alterações que podem causar discrepâncias.
- Comportamento previsível: restringir modificações garante resultados de migração consistentes e confiáveis.
- Foco de migração, não transformação: a ferramenta move dados; A transformação ocorre separadamente após a migração.
Cenários de migração sem suporte
- Movendo projetos de uma organização do Azure DevOps Services para outra organização do Azure DevOps Services
- Migrando de uma instância do Servidor do Azure DevOps para outra instância do Servidor do Azure DevOps
Limitações regionais
A Ferramenta de Migração de Dados só tem suporte em regiões específicas do Azure. As organizações devem ser criadas em regiões com suporte e qualquer infraestrutura temporária (como VMs do SQL para migrações grandes) também deve ser implantada nessas regiões. Consulte regiões com suporte para migração para a lista completa.
Processo da Ferramenta de Migração
- Conclua os pré-requisitos, como atualizar Azure DevOps Server para uma das duas versões mais recentes.
- Valide cada coleção que você deseja mover para Azure DevOps Services.
- Gere arquivos de migração.
- Prepare tudo para a execução da migração.
- Execute uma execução de teste.
- Realize uma migração.
- Confirme se os usuários e os dados foram migrados e se a coleção está funcionando conforme o esperado.
Dica
Você pode limpar dados que não precisam antes ou depois da migração para reduzir o tempo de migração e os requisitos de armazenamento.
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 a Opção 2, considere usar várias ferramentas que usam 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.