Reconhecimento de versão e cadência de lançamento

  • 5 minutos

Um dos conceitos mais importantes para desenvolvedores de GHES é o reconhecimento de versão. Ao contrário do GitHub.com, que é atualizado continuamente, o GHES segue um modelo de versão estruturado.

Nesta unidade, você aprenderá

  • Como os lançamentos do GHES são agendados e entregues

  • Por que o tempo de lançamento de funcionalidades é importante para os desenvolvedores

  • Como localizar a documentação específica da versão

  • Como evitar a criação de fluxos de trabalho que dependem de recursos indisponíveis

Modelo de versão do GHES

O GitHub Enterprise Server segue uma cadência de versão trimestral (por exemplo, versões 3.17, 3.18 e 3.19), em vez de entrega contínua.

Cada versão normalmente inclui:

  • Novos recursos que já se mostraram estáveis em GitHub.com e estão prontos para ambientes auto-hospedados

  • Patches de segurança e melhorias de desempenho necessários para confiabilidade e conformidade de nível empresarial

  • Descontinuações e alterações de comportamento que podem afetar APIs, fluxos de trabalho ou integrações

Como as atualizações são gerenciadas pelo cliente:

  • Algumas organizações permanecem intencionalmente em versões mais antigas para atender aos requisitos de validação, conformidade ou controle de alterações

  • A disponibilidade de recursos pode variar significativamente entre as empresas, mesmo quando todas elas usam GHES

Documentação específica da versão

A documentação do GitHub Enterprise Server tem versão e os desenvolvedores sempre devem referenciar a documentação que corresponde à versão implantada.

Por exemplo, a documentação do GHES 3.19 está disponível em:

A documentação do GitHub.com frequentemente descreve recursos que ainda não existem em seu ambiente GHES (GitHub Enterprise Server).

Usar a documentação errada pode levar a:

  • Suposições incorretas sobre recursos disponíveis

  • Fluxos de trabalho quebrados ou configurações sem suporte

  • Confusão durante a solução de problemas ou implementação

Impacto do atraso de versão para os desenvolvedores

Os recursos comumente afetados pelas diferenças de versão do GHES incluem:

  • Aprimoramentos do GitHub Actions, como nova sintaxe de fluxo de trabalho ou recursos de trabalho

  • Aprimoramentos de verificação de segurança, incluindo atualizações no CodeQL ou comportamento de verificação secreta

  • Alterações de API e recursos de visualização, que podem estar indisponíveis ou se comportar de forma diferente

  • Primeiramente, refinamentos de interface do usuário e fluxo de trabalho que melhoram a usabilidade no GitHub.com

Diretrizes práticas para desenvolvedores:

  • Sempre confirme a versão atual do GHES da sua organização antes de criar fluxos de trabalho ou automação

  • Examine as notas sobre a versão para entender o que tem suporte e o que não é

  • Planejar soluções que funcionam dentro das restrições do seu ambiente implantado, não dos recursos de nuvem mais recentes

Conselho prático: antes de criar fluxos de trabalho ou automações, confirme sua versão do GHES e verifique as notas de versão.

Principais pontos: a conscientização sobre a versão do GHES é uma competência essencial para desenvolvedores — funcionalidades, APIs e comportamento dependem do que sua organização implantou, não do que está disponível no GitHub.com hoje.

Agora que você entende como a cadência da versão afeta o tempo do recurso, a próxima unidade analisa como essas diferenças aparecem na experiência diária do desenvolvedor, incluindo automação, integrações e restrições de ferramentas.