Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-09-25. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Upgrade-Anforderungen

Lese vor dem Upgrade von GitHub Enterprise Server diese Empfehlungen und Anforderungen, um deine Upgradestrategie zu planen.

Note

  • Upgradepakete für unterstützte Versionen sind unter enterprise.github.com verfügbar. Verifiziere die Verfügbarkeit der Upgrade-Pakete, die du zum Abschließen des Upgrades benötigst. Wenden Sie sich zwecks Unterstützung unter GitHub Enterprise Support an uns, falls ein Paket nicht verfügbar ist.
  • Wenn du GitHub Enterprise Server-Clustering verwendest, findest du im Leitfaden zum GitHub Enterprise Server-Clustering unter Cluster-Upgrade spezifische Anweisungen für das Clustering.
  • Die Versionshinweise für GitHub Enterprise Server enthalten eine umfassende Liste der neuen Features jeder Version von GitHub Enterprise Server. Weitere Informationen findest du auf der Releaseübersichtsseite.

Empfehlungen

  • Du solltest möglichst wenig Upgrades in deinen Upgrade-Prozess einbeziehen. Anstatt ein Upgrade von GitHub Enterprise 3.12 auf 3.13 und auf 3.14 durchzuführen, könntest du ein Upgrade von GitHub Enterprise 3.12 auf 3.14 durchführen. Verwende den Upgrade-Assistent, um den Upgradepfad aus deinem aktuellen Release zu finden.
  • Wenn du mehrere Versionen im Rückstand bist, aktualisiere Ihre GitHub Enterprise Server-Instance in jedem Schritt deines Upgradeprozesses so weit wie möglich. Wenn du nach Möglichkeit die neueste Version für jedes Upgrade verwendest, kannst du von Leistungsverbesserungen und Bug-Korrekturen profitieren. So kannst du beispielsweise ein Upgrade von GitHub Enterprise 2.7 auf 2.8 auf 2.10 vornehmen. Beim Upgrade von GitHub Enterprise 2.7 auf 2.9 auf 2.10 wird im zweiten Schritt jedoch eine neuere Version verwendet.
  • Verwende beim Upgraden die neueste Patch-Veröffentlichung. Navigiere zur Seite „GitHub Enterprise Server-Releases“. Klicke neben dem Release, auf welches das Upgrade durchgeführt wird, auf Herunterladen, und klicke dann auf die Registerkarte Upgrade.
  • Verwende eine Testinstanz zum Testen der Upgrade-Schritte. Weitere Informationen findest du unter Testinstanz einrichten.
  • Wenn mehrere Upgrades vorgenommen werden, muss sichergestellt werden, dass die im Hintergrund ablaufenden Datenmigrationen und Upgrade-Aufgaben vollständig abgeschlossen sind, bevor es mit dem nächsten Funktionsupgrade weitergehen kann. Der Status dieser Prozesse kann mit den Befehlszeilen-Hilfsprogrammen ghe-migrations und ghe-check-background-upgrade-jobs geprüft werden. Um ghe-check-background-upgrade-jobs mit GitHub Enterprise Server 3.10 zu verwenden, muss Ihre Instanz die Version 3.10.4 oder höher haben. Weitere Informationen sind unter „Befehlszeilenprogramme“ zu finden.
  • Erstelle vor dem Upgrade deines virtuellen Computers eine Momentaufnahme. Weitere Informationen findest du unter Snapshot erstellen.
  • Stelle sicher, dass du über eine aktuelle, erfolgreiche Sicherung deiner Instanz verfügst. Weitere Informationen findest du in der „README.md“-Datei GitHub Enterprise Server Backup Utilities.

Anforderungen

  • Du musst ein Upgrade aus einem Featurerelease durchführen, das mindestens zwei Releases zurückliegt. Um beispielsweise ein Upgrade auf GitHub Enterprise 3.14 durchzuführen, musst du über GitHub Enterprise 3.13 oder 3.12 verfügen.
  • Wenn du mithilfe eines Upgradepakets ein Upgrade durchführst, solltest du ein Wartungsfenster für GitHub Enterprise Server-Endbenutzer*innen einplanen.
  • Du kannst GitHub Enterprise Server auf das neueste Patchrelease mithilfe eines Hotpatches upgraden.

Mittels Hotpatching kannst Du ein Upgrade auf einen neueren Patch-Release durchführen, jedoch keine Feature-Veröffentlichung. Du kannst z. B. ein Upgrade von 2.10.1 auf 2.10.5 durchführen, da sich beide Releases in derselben Featureserie befinden. Ein Upgrade von 2.10.9 auf 2.11.0 ist hingegen nicht möglich, da diese Releases unterschiedlichen Featureserien angehören.

Hotpatches erfordern immer keinen Neustart. Wenn Sie den Hotpatch installieren, wird eine Meldung im Terminal angezeigt, wenn eines der Pakete einen Neustart benötigt, um das Update abzuschließen. Sie können diesen Neustart zu einem Ihnen passenden Zeitpunkt planen, es wird jedoch empfohlen, den Neustart so schnell wie möglich durchzuführen, insbesondere, wenn Sicherheitsupdates vorhanden sind.

Hotpatches erfordern eine Konfigurationsausführung, was für einige oder alle Dienste auf Ihre GitHub Enterprise Server-Instance zu einer kurzen Fehlerperiode oder zu einer ausbleibenden Reaktion führen kann. Du musst den Wartungsmodus während der Installation eines Hotpatches nicht aktivieren, aber dadurch wird sichergestellt, dass Benutzer*innen eine Wartungsseite anstelle von Fehlern oder Timeouts angezeigt wird. Weitere Informationen finden Sie unter „Wartungsmodus aktivieren und planen“.

  • Ein Hotpatch kann Ausfallzeiten nach sich ziehen, falls für die betroffenen Dienste (z. B. der Kernel, MySQL oder ElasticSearch) ein VM- oder Dienstneustart erforderlich ist. Du wirst benachrichtigt, falls ein Neustart erforderlich ist. Du kannst den Neustart zu einem späteren Zeitpunkt abschließen.
  • Beim Upgrade mittels Hotpatching muss zusätzlicher Root-Storage verfügbar sein, da bis zum Abschluss des Upgrades mehrere Versionen bestimmter Dienste installiert werden. Bei Preflightüberprüfungen werden Benachrichtigungen gesendet, falls nicht genügend Stammdatenträgerspeicher verfügbar ist.
  • Beim Upgrade mittels Hotpatching darf deine Instanz keine zu große Auslastung aufweisen, da sich dies gegebenenfalls auf den Hotpatchingprozess auswirkt.
  • Beim Upgrade auf GitHub Enterprise Server 2.17 werden deine Auditprotokolle von Elasticsearch zu MySQL migriert. Diese Migration erhöht die erforderliche Dauer und den Speicherplatz, die bzw. der zum Wiederherstellen eines Snapshots erforderlich ist. Überprüfe vor der Migration die Anzahl an Bytes in deinen ElasticSearch-Auditprotokollindizes. Führe dazu den folgenden Befehl aus:
curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes

Anhand der Zahl kannst du schätzen, wie viel Speicherplatz die MySQL-Auditprotokolle benötigen werden. Darüber hinaus überwacht das Skript den freien Speicherplatz, während der Import ausgeführt wird. Die Überwachung dieser Zahl ist besonders nützlich, wenn der freie Speicherplatz dem für die Migration erforderlichen Speicherplatz nahekommt.

Bei einem Upgrade bewerten Vorab-Flight-Prüfungen, ob die Mindestanforderungen für Systemhardwareressourcen wie Arbeitsspeicher, CPU-Kerne und Benutzer- und Stammdatenträgerspeicher für Ihre Instanz verfügbar sind. Wenn Vorab-Flight-Prüfungen feststellen, dass nicht genügend Ressourcen vorhanden sind oder anderweitig fehlschlagen, werden Sie benachrichtigt, und das Upgrade wird abgebrochen.

Bekannte Probleme

Überprüfe bekannte Probleme, die möglicherweise bei deinem Upgrade auftreten. Weitere Informationen findest du unter Bekannte Probleme mit Upgrades für deine Instanz.

Nächste Schritte

Nachdem du diese Empfehlungen und Anforderungen gelesen hast, kannst du GitHub Enterprise Server upgraden. Weitere Informationen findest du unter Übersicht über den Upgradeprozess.