此版本的 GitHub Enterprise Server 已于以下日期停止服务 2024-07-09. 即使针对重大安全问题，也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能，请升级到最新版本的 GitHub Enterprise。 如需升级帮助，请联系 GitHub Enterprise 支持。

升级要求

对 GitHub Enterprise Server 进行升级之前，请查阅升级策略规划的建议和要求。

本文内容

注意：

  • enterprise.github.com 上提供了支持版本的升级包。 验证完成升级所需的升级包的可用性。 如果包不可用，请访问 GitHub Enterprise 支持 并联系我们，以获得帮助。
  • 如果使用的是 GitHub Enterprise Server 群集，请参阅 GitHub Enterprise Server 群集指南中的“升级集群”，了解群集特有的特定说明。
  • GitHub Enterprise Server 版本说明提供了 GitHub Enterprise Server 每一版本的新功能一览表。 有关详细信息，请参阅发布页面。

建议

  • 尽量减少升级过程中的升级次数。 例如，不要从 GitHub Enterprise 3.11 升级到 3.12 再升级到 3.13，而应从 GitHub Enterprise 3.11 升级到 3.13。 使用 升级助手 查找当前发行版本的升级路径。
  • 如果你的版本比最新版本低几个版本，请通过升级过程的每一步骤尽量将 你的 GitHub Enterprise Server 实例升级为更高版本。 在每次升级时尽可能使用最新版本，这样一来你可以充分利用性能改进和错误修复。 例如，你可以从 GitHub Enterprise 2.7 升级到 2.8 再升级到 2.10，但从 GitHub Enterprise 2.7 升级到 2.9 再升级到 2.10 会在第二步中使用更高版本。
  • 升级时使用最新补丁版本。 浏览到 GitHub Enterprise Server 版本页。 在要升级到的版本旁边，单击“下载”，然后单击“升级”选项卡 。
  • 使用暂存实例测试升级步骤。 有关详细信息，请参阅“设置暂存实例”。
  • 运行多个升级时， 可确保在后台运行的数据迁移和升级任务完全完成，然后再继续下一个功能升级。 要检查这些流程的状态，可以使用 ghe-migrations 和 ghe-check-background-upgrade-jobs 命令行实用程序。 要将 ghe-check-background-upgrade-jobs 与 GitHub Enterprise Server 3.9 一起使用，实例必须运行 3.9.7 版或更高版本。 有关详细信息，请参阅“命令行实用程序”。
  • 在升级虚拟机之前拍摄快照。 有关详细信息，请参阅“升级 GitHub Enterprise Server”。
  • 确保你最近成功备份了实例。 有关详细信息，请参阅 GitHub Enterprise Server Backup Utilities README.md 文件。

要求

  • 必须从最近两个版本的功能版本开始升级。 例如，要升级到 GitHub Enterprise 3.13，你必须使用 GitHub Enterprise 3.12 或 3.11。
  • 使用升级包进行升级时，请为 GitHub Enterprise Server 最终用户安排维护时段。
  • 可使用热补丁将 GitHub Enterprise Server 升级到最新的补丁版本。

您可以使用热更新来升级到更新的补丁版本，但不能升级到功能版本。 例如，你可从 2.10.1 升级到 2.10.5，因为它们位于同一功能系列中，但不能从 2.10.9 升级到 2.11.0，因为它们位于不同的功能系列中。

热补丁通常不要求重启。 如果热补丁确实要求重启，GitHub Enterprise Server 发行说明将说明此要求。

热补丁需要配置运行，这可能会导致 你的 GitHub Enterprise Server 实例 上的部分或所有服务短暂出现错误或无响应。 无需在热补丁安装期间启用维护模式，但这样做将保证用户看到维护页，而不是错误或超时。 有关详细信息，请参阅“启用和排定维护模式”。

  • 如果受影响的服务（例如内核、MySQL 或 Elasticsearch）需要重启 VM 或服务，热补丁可能需要停机一段时间。 需要重启时，系统会通知你。 你可以在稍后完成重启。
  • 通过热补丁升级时，必须提供额外的根存储，因为热补丁会安装某些服务的多个版本，直至升级完成。 如果根磁盘存储空间不足，运行前检查将发出通知。
  • 通过热补丁进行升级时，你的实例负荷不能过大，否则可能影响热补丁过程。
  • 升级到 GitHub Enterprise Server 2.17 会将你的审核日志从 ElasticSearchElasticSearch 迁移到 MySQL。 这种迁移还会增加恢复快照所需的时长和磁盘空间大小。 迁移之前，请使用此命令检查 ElasticSearch 审核日志索引中的字节数：
curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes

使用此数字估算 MySQL 审核日志将需要的磁盘空间大小。 该脚本还会在导入过程中监视可用磁盘空间大小。 在可用磁盘空间大小接近于迁移必需的磁盘空间大小时，监视此数字尤为重要。

升级时，通过预外部测试检查来评估实例是否满足有关系统硬件资源（例如内存、CPU 核心和用户和根磁盘存储）的最低要求。 如果预外部测试检查确定资源不足，或者因其他原因未通过检查，则系统会通知你并中止升级。

已知问题

查看可能与升级有关的已知问题。 有关详细信息，请参阅“有关对实例的升级的已知问题”。

后续步骤

查看这些建议和要求后，你可以对 GitHub Enterprise Server 进行升级。 有关详细信息，请参阅“升级 GitHub Enterprise Server”。