发行频率和版本感知

  • 5 分钟

GHES 开发人员最重要的概念之一是版本感知。 与持续更新 GitHub.com 不同，GHES 遵循结构化发布模型。

在本单元中，你将学习

  • 如何计划和交付 GHES 发布版本

  • 为什么功能计时对开发人员很重要

  • 如何查找特定于版本的文档

  • 如何避免生成依赖于不可用功能的工作流

GHES 发布模型

GitHub Enterprise Server 遵循季度发布节奏（例如版本 3.17、3.18 和 3.19），而不是持续交付。

每个版本通常包括：

  • 已在 GitHub.com 上证明稳定且已准备好用于自承载环境的新功能

  • 企业级可靠性和合规性所需的安全修补程序和性能改进

  • 可能影响 API、工作流或集成的弃用和行为更改

由于升级是客户管理的：

  • 某些组织有意保留在较旧版本上，以满足验证、合规性或变更控制要求

  • 即使所有企业都使用 GHES，功能可用性也有很大差异

特定于版本的文档

GitHub Enterprise Server 文档已进行版本控制，开发人员必须始终引用与部署的版本匹配的文档。

例如，GHES 3.19 文档在以下位置提供：

GitHub.com 文档通常描述 GHES 环境中尚不存在的功能。

使用错误的文档可能会导致：

  • 有关可用功能的假设不正确

  • 工作流中断或配置不受支持

  • 故障排除或实现过程中的混淆

版本滞后的开发人员影响

通常受 GHES 版本差异影响的功能包括：

  • GitHub Actions 增强功能，例如新的工作流语法或作业功能

  • 安全扫描改进，包括对 CodeQL 或机密扫描行为的更新

  • API 更改和预览功能，这些功能可能不可用或行为可能有所不同

  • 首要优化 GitHub.com 用户界面和工作流以提高其可用性。

面向开发人员的实践指南：

  • 在设计工作流或自动化之前，请始终确认组织的当前 GHES 版本

  • 查看版本的发行说明，了解支持的内容和不支持的内容

  • 规划在已部署环境的约束范围内工作的解决方案，而不是最新的云功能

实用建议：在设计工作流或自动化之前，请确认 GHES 版本并查看发行说明。

关键要点：GHES 版本意识是一项核心开发技能，功能、API 和行为取决于组织已部署的内容，而不是目前 GitHub.com 提供的内容。

了解发布节奏如何影响功能计时后，下一单元将了解这些差异在日常开发人员体验中的显示方式，包括自动化、集成和工具约束。