5. Transição para o GitHub

Serviços de DevOps do Azure

Quando a sincronização inicial terminar, o seu repositório estará pronto para a transição. Conclua a transição final no prazo de 21 dias após o início da sincronização inicial.

Importante

A transição fica normalmente concluída em menos de 30 minutos, período durante o qual o repositório do Azure DevOps fica em modo só de leitura. Embora o repositório seja apenas de leitura, as atualizações push e pull requests são bloqueadas, mas os utilizadores ainda podem navegar e clonar. Avise todas as equipas afetadas antes de agendar a transição.

Antes de agendar o cutover

Confirme as seguintes condições:

  • As sincronizações incrementais são saudáveis e atuais.
  • Ramos, etiquetas e pull requests do repositório GitHub estão presentes e corretos.
  • Todas as equipas afetadas são notificadas.
  • Os URLs do Azure DevOps codificados de forma rígida em pipelines, scripts e ferramentas são identificados para atualização.

Observação

O agendamento, a monitorização e a aprovação da transição são efetuados com recurso à CLI do Azure DevOps. Após o cutover, validas o repositório migrado no portal do GitHub. Para mais informações, consulte Completar tarefas pós-migração.

Agendar a transição

az devops migrations cutover set --org https://dev.azure.com/<org>
                                 --repository-id <repo-guid>
                                 --date "YYYY-MM-DDTHH:MM:SSZ"

Orientações sobre o fuso horário: Acrescente Z para UTC ou utilize um desvio, como -08:00, para a Hora do Pacífico. Se omitir o fuso horário, assume-se o seu fuso horário local. Para evitar ambiguidades entre as equipas, inclua Z ou um desfasamento explícito.

Cancelar um corte agendado

az devops migrations cutover cancel --org https://dev.azure.com/<org>
                                    --repository-id <repo-guid>

Observação

O cutover cancel comando funciona apenas enquanto a migração ainda está na fase de Sincronização . Quando o estágio avança para Cutover, o servidor rejeita o pedido de cancelamento e a CLI devolve um código de saída diferente de zero. Se precisares de parar um cutover que já está em curso, usa az devops migrations abandon ou contacta a equipa ELM.

O que acontece durante a transição

  1. O repositório Azure DevOps é colocado num estado controlado de apenas leitura.
  2. O ELM realiza a sincronização final. Os deltas restantes são aplicados ao GitHub.
  3. O GitHub torna-se o sistema autoritário de registo.
  4. Aparece um banner na página do repositório Azure DevOps que liga os utilizadores à nova localização do GitHub.
  5. O estado migratório está marcado como Migrado / Sucedido.

Acompanhar o progresso da transição

az devops migrations status --org https://dev.azure.com/<org>
                            --repository-id <repo-guid>

Espere até que a migração mostre status: Succeeded e stage: Migrated.

Observação

Os trabalhos ELM decorrem a cada 30 a 60 minutos. Se agendar a transição assim que a migração entrar na fase de cutover, pode demorar até 60 minutos para que a tarefa de cutover comece.

Importante

Depois da conclusão do cutover, os pull requests abertos no GitHub não são sincronizados de volta para o Azure DevOps.

Revisão da transição

Se a reconfiguração da conduta estiver ativada ou se persistirem falhas não resolvidas no tempo de corte programado, o ELM pausa a migração no ReviewForCutover em vez de proceder automaticamente. Por exemplo, esta condição pode ocorrer quando alguns pull requests não podem ser migrados. Revê as falhas e depois escolhe explicitamente se queres continuar.

Rever falhas de transição

az devops migrations cutover review --org https://dev.azure.com/<org>
                                    --repository-id <repo-guid>

O comando devolve um resumo dos itens não resolvidos:

Campo Description
failedCount Número de itens cuja migração falhou.
blockedCount Número de itens bloqueados por dependências.
pendingCount Número de itens ainda pendentes.
totalUnprocessedCount Itens totais a requerer aprovação.
failedItems Lista detalhada de itens não processados com estado, tipo e URL de pull-request.

Revê a failedItems lista cuidadosamente para perceberes quais os itens que não são migrados caso decidas continuar.

Opções no ReviewForCutover

Depois de rever as falhas, escolha uma das seguintes opções:

Opção O que faz Quando utilizar
Aprovar e prosseguir Aceita os fracassos e avança para o cutover. Já analisaste todas as falhas e estás bem em avançar sem esses itens.
Data de transição bem definida Repõe para Sincronização. A migração continua a sincronizar. Quer resolver os problemas primeiro e agendar um novo corte mais tarde.
Alteração do reagendamento Reinicia para Sincronização com uma nova data de transição. Execute az devops migrations cutover set --date <new> novamente para definir uma nova data. Se as falhas forem resolvidas até à nova data, a transição prossegue automaticamente. Queres mais tempo.
Apagar a migração Apaga o registo de migração. É escrito um evento de auditoria; o repositório Azure DevOps de origem mantém-se inalterado. Queres abandonar esta migração por completo.
Pausar a migração Suspende a sincronização até a retomares manualmente. Tens de pausar toda a atividade enquanto investigas.

Aprovar o corte

Se decidir continuar, autorize a transição aceitando o número de itens a ignorar:

az devops migrations cutover approve --org https://dev.azure.com/<org>
                                     --repository-id <repo-guid>
                                     --accept-failures <N>
                                     --pipelines-verified

Defina o valor de <N> como superior ou igual a totalUnprocessedCount na revisão de transição.

Inclua --pipelines-verified quando a revisão de corte regressar requiresPipelineVerificationAcknowledgment: true. Esta bandeira confirma que revistou e verificou todos os pipelines reconfigurados. Deve fornecer pelo menos um de --accept-failures ou --pipelines-verified.

Warning

A aprovação é irreversível. Não existe uma API para revogar uma aprovação. Se aprovar por engano, a única forma de recuperação é az devops migrations abandon, seguida de recriar a migração.

Observação

Se surgirem novas falhas depois de as rever e antes de aprovar, o comando é rejeitado com um erro HTTP 400, sinalizado através de CLIError, indicando que o número de falhas já não corresponde ao esperado. Executa cutover review novamente, nota o atualizado totalUnprocessedCounte tenta novamente a aprovação. Os scripts e os processos automatizados podem verificar se o código de saída é diferente de zero.

Após a aprovação, a migração passa para ReadyForCutover:

  • Se já estiver agendada uma data de transição, a transição ocorre automaticamente à hora agendada.
  • Se não estiver definida uma data de transição, agende-a para prosseguir.

Passo seguinte

Concluir tarefas pós-migração

Conteúdo relacionado

  • Last updated on