Se você for membro de uma organização que migrou de Azure DevOps para GitHub, este guia explicará as alterações em seus fluxos de trabalho para tornar a migração o mais suave possível.
Estrutura
Em Azure DevOps, os repositórios são aninhados dentro de projetos team, portanto, a estrutura do seu ambiente tem esta aparência:
- Organização
- Projeto da equipe
- Repositórios
- Projeto da equipe
- Repositórios
- Projeto da equipe
As permissões e a visibilidade são definidas a partir do projeto da equipe.
GitHub é estruturado de forma diferente. Os repositórios estão aninhados diretamente dentro das **organizações**, que também contêm equipes:
- Conta empresarial
- Organização
- Equipes
- Repositórios
- Organização
- Equipes
- Repositórios
- Organização
As permissões e a visibilidade são determinadas por uma combinação de associação da organização, associação à equipe e permissões individuais.
O conceito de um projeto de equipe, que é usado para agrupar repositórios em Azure DevOps, não existe em GitHub e tratar organizações em GitHub como o equivalente de projetos de equipe não é recomendado.
Embora você possa inicialmente encontrar cada organização GitHub migrada com uma longa lista de repositórios desorganizada, você pode conceder acesso e permissões por meio de equipes de membros da organização, o que facilita muito a navegação nos repositórios da organização.
Autenticação, permissões e equipes
Há dois métodos de autenticação no GitHub. Qual método você usar dependerá de como a conta corporativa está configurada.
Se sua conta corporativa usar Enterprise Managed Users, você entrará no GitHub por meio do provedor de identidade (por exemplo, Entra ID) e usará uma conta provisionada vinculada à conta corporativa.
Caso contrário, você usará uma conta pessoalGitHub . Essa conta será convidada para a conta corporativa e para todas as organizações nas quais você trabalhar. Se a conta corporativa estiver configurada com restrições de acesso SAML adicionais, sua conta pessoal será vinculada ao IdP. Você será solicitado a autenticar com o IdP quando precisar acessar recursos na conta corporativa.
Em uma empresa no GitHub, os repositórios podem ser públicos, privados ou internos. Repositórios privados só são visíveis para pessoas e equipes com acesso explícito, e repositórios internos são visíveis para todos os membros da sua empresa, mas não para pessoas de fora da empresa. Repositórios internos são úteis quando várias organizações na mesma empresa precisam descobrir e reutilizar código. Se sua empresa usar Enterprise Managed Users, as contas de usuário não poderão criar repositórios públicos ou outro conteúdo público.
Usar o Git
Para continuar trabalhando em seus repositórios usando o Git, você precisará fazer algumas alterações.
- Atualize URLs remotas para apontar para GitHub. Confira Gerenciar repositórios remote.
- Atualize como você se autentica.
- Para usar a autenticação HTTPS, você precisará criar uma personal access token. Confira Gerenciar seus tokens de acesso pessoal.
- Para usar a autenticação SSH, você precisará criar ou adicionar uma chave SSH existente.GitHub Confira Conectando-se ao GitHub com o SSH.
- Se sua empresa ou organização usar o SSO (Single Sign-On) do SAML, você deverá autorizar sua personal access token chave SSH antes que ela possa acessar recursos.
Fluxo de solicitações de pull
Com a base de código agora hospedada GitHub, você proporá alterações usando solicitações de pull criadas em seus GitHub repositórios.
Se sua empresa integrou o Azure Boards e os Pipelines, ambos funcionarão com GitHub. Você pode continuar a referenciar itens de trabalho em suas mensagens de confirmação e solicitações de pull. Por exemplo: Fix login bug (AB#1234).
Você pode continuar exibindo e gerenciando seus itens de trabalho no Azure Boards. Você também pode vincular branches, confirmações e pull requests a itens de trabalho dentro do Azure. Consulte Link GitHub confirmações, solicitações de pull, branches e problemas para itens de trabalho no Azure Boards no Microsoft Learn.
Proteções de ramificação
Pessoas com acesso administrativo a um repositório podem configurar regras de proteção de branch em GitHub. Eles são semelhantes às políticas de branch no Azure DevOps e definem regras, como um número mínimo de revisores aprovadores, checagens de status bem-sucedidas e a exigência de commits assinados.
GitHub também dá suporte à atribuição automática de revisores com base nos padrões de arquivo, pasta e padrões globais no arquivo CODEOWNERS de um repositório. Confira [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
Pacotes e artefatos
Em Azure DevOps, você pode ter usado Azure Artifacts para publicar e consumir pacotes (por exemplo, pacotes NuGet, pacotes npm ou pacotes Maven) e armazenar artefatos de build produzidos por Azure Pipelines.
Em GitHub, os pacotes normalmente são publicados no GitHub Packages e associados a um repositório ou organização. Dependendo de como sua empresa concluiu a migração, você pode continuar publicando pacotes para Azure Artifacts, mover pacotes para GitHub Packages ou usar uma combinação de ambos.
Se você não conseguir mais restaurar dependências após a migração, verifique a configuração de origem do pacote. Por exemplo, talvez seja necessário atualizar uma URL do Registro ou credenciais em arquivos como nuget.config, .npmrcou settings.xmlem sua configuração de pipeline.
Para saber mais, confira Introdução ao GitHub Packages.
GitHub Copilot
Hospedar seus repositórios em GitHub desbloqueia todo o poder de Copilot. Sua base de código fornece Copilot todo o contexto de que precisa para responder perguntas em Bate-Papo Copilot, examinar e fazer sugestões em seus pull requests e até mesmo fazer alterações em seu lugar com agente de nuvem Copilot.
Confira Início Rápido para GitHub Copilot.