Experiência do desenvolvedor no GHES

  • 5 minutos

Do ponto de vista da interface do usuário, o GHES parece familiar. No entanto, a experiência do desenvolvedor difere de maneiras significativas, especialmente em relação à automação, integrações e ferramentas.

Nesta unidade, você aprenderá

  • Como o GitHub Actions funciona no GHES

  • Quais ferramentas os desenvolvedores devem autogerenciar

  • Quais recursos nativos de nuvem não estão disponíveis

  • Como adaptar fluxos de trabalho a ambientes restritos

Ações do GitHub no GHES

  • Há suporte para o GitHub Actions, mas os fluxos de trabalho devem usar executores auto-hospedados.

  • Sua organização é responsável por provisionar, escalar, aplicar patches e manter esses executores.

  • Se os executores estiverem offline ou desatualizados, os fluxos de trabalho falharão, sem reversão automática.

  • Restrições de rede são comuns; proxies ou espelhos podem ser necessários para acesso externo.

  • O GHES depende principalmente de executores auto-hospedados. Os executores hospedados pelo GitHub disponíveis no GitHub Enterprise Cloud geralmente não estão disponíveis, embora alguns cenários híbridos possam ter suporte por meio do GitHub Connect, dependendo da configuração da empresa.

Pacotes, segurança e automação

  • Os pacotes do GitHub (npm, Docker etc.) estão disponíveis e hospedados internamente no GHES.

  • Recursos de Segurança Avançada (por exemplo, verificação de código, verificação secreta) têm suporte com o licenciamento adequado.

  • Esses recursos geralmente exigem configuração manual, como instalar mecanismos de verificação ou habilitar a detecção de segredos. No entanto, do ponto de vista do desenvolvedor, o processo de habilitação não é diferente do que no GitHub Enterprise Cloud (GHEC).

  • Muitos recursos são desabilitados por padrão e dependem da coordenação com o DevOps ou as equipes de plataforma.

Recursos sem suporte ou limitados

  • Não há suporte para codespaces do GitHub a partir do GHES 3.19.

  • Não há suporte para o GitHub Copilot no GHES. O Copilot pode ser usado como um recurso autônomo em IDEs com suporte, mas os recursos do Copilot não estão disponíveis na interface da Web GHES e a funcionalidade pode ser ainda mais limitada em ambientes com acesso restrito à Internet.

  • Acessar a biblioteca do GitHub Actions público diretamente do GitHub.com requer o GitHub Connect. Sem ela, as ações devem ser sincronizadas manualmente com sua instância local.

  • Embora webhooks e ferramentas SaaS não usem o GitHub Connect, eles exigem roteamento de rede de saída (Proxy/Firewall) para alcançar pontos de extremidade externos.

  • A disponibilidade de recursos varia, e os desenvolvedores devem confirmar o que está habilitado antes de confiar nos fluxos de trabalho na nuvem.

Os desenvolvedores devem verificar a disponibilidade antes de depender de fluxos de trabalho de nuvem.

Principais conclusões: a experiência do desenvolvedor do GHES é moldada por infraestrutura autogerenciada, automação, integrações, e até mesmo "recursos disponíveis" podem depender do que é implantado, licenciado e habilitado em seu ambiente.

Agora que você viu como o GHES pode diferir nos fluxos de trabalho de desenvolvimento diários, você está pronto para a próxima etapa.

A próxima unidade apresenta o GitHub Connect e cenários híbridos que estendem o GHES com recursos de GitHub.com selecionados.