Before upgrading GitHub Enterprise, review these recommendations and requirements.
- To upgrade from GitHub Enterprise 11.10.348 through 11.10.354, you must first migrate to GitHub Enterprise 2.1.23. For more information, see "Migrating from GitHub Enterprise 11.10.x to 2.1.23."
- Upgrade packages are available at enterprise.github.com for supported versions. Verify the availability of the upgrade packages you will need to complete the upgrade. If a package is not available, contact GitHub Enterprise Support for assistance.
- If you're using GitHub Enterprise Clustering, see "Upgrading a cluster" in the GitHub Enterprise Clustering Guide for specific instructions unique to clustering.
- Include as few upgrades as possible in your upgrade process. For example, instead of upgrading from GitHub Enterprise 2.12 to 2.13 to 2.14, you could upgrade from GitHub Enterprise 2.12 to 2.14.
- If you’re several versions behind, upgrade your GitHub Enterprise instance as far forward as possible with each step of your upgrade process. Using the latest version possible on each upgrade allows you to take advantage of performance improvements and bug fixes. For example, you could upgrade from GitHub Enterprise 2.7 to 2.8 to 2.10, but upgrading from GitHub Enterprise 2.7 to 2.9 to 2.10 uses a later version in the second step.
- Use the latest patch release when upgrading. Browse to the GitHub Enterprise Releases page, on the right side next to the release you are upgrading to, click Download, then click the Upgrading tab.
- Use a staging instance to test the upgrade steps. For more information, see "Setting up a staging instance."
- When running multiple upgrades, wait at least 24 hours between feature upgrades to allow data migrations and backgrounded upgrade tasks to fully complete.
- You must upgrade from a feature release that's at most two releases behind. For example, to upgrade to GitHub Enterprise 2.14, you must be on GitHub Enterprise 2.13 or 2.12.
You can upgrade GitHub Enterprise to the latest patch release using a hotpatch, which does not require a maintenance window and usually does not require a reboot. You can use hotpatching to upgrade to a newer patch release, but not a feature release. For example, you can upgrade from
2.10.5because they are in the same feature series, but not from
2.11.0because they are in a different feature series.
A hotpatch may require downtime if the affected services (like kernel, MySQL, or Elasticsearch) require a VM reboot or a service restart. You'll be notified when a reboot or restart is required. You can complete the reboot or restart at a later time.
- Additional root storage must be available when upgrading through hotpatching, as it installs multiple versions of certain services until the upgrade is complete. Pre-flight checks will notify you if you don't have enough root disk storage.
- When upgrading through hotpatching, your instance cannot be too heavily loaded, as it may impact the hotpatching process. Pre-flight checks will consider the load average and the upgrade will fail if the load average is too high.
After reviewing these recommendations and requirements you can upgrade GitHub Enterprise. For more information, see "Upgrading GitHub Enterprise."