Hinweis
- 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. Besuchen Sie GitHub Enterprise-Support und kontaktieren Sie uns für Unterstützung, falls ein Paket nicht verfügbar ist.
- Wenn du das GitHub Enterprise Server-Clustering verwendest, findest du im Leitfaden zum GitHub Enterprise Server-Clustering unter Upgrade eines Clusters für das Clustering spezifische Anweisungen.
- Die Versionshinweise für GitHub Enterprise Server enthalten eine umfassende Liste der neuen Features jeder Version von GitHub Enterprise Server. Weitere Informationen finden Sie auf der Release-Seite.
Empfehlungen
- Du solltest möglichst wenig Upgrades in deinen Upgrade-Prozess einbeziehen. Anstatt ein Upgrade von GitHub Enterprise 3.18 auf 3.19 und auf 3.20 durchzuführen, könntest du ein Upgrade von GitHub Enterprise 3.18 auf 3.20 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 finden Sie unter Testinstanz einrichten.
- Stelle beim Ausführen mehrerer Upgrades sicher, dass Datenmigrationen und Upgradetasks, die im Hintergrund ausgeführt werden, vollständig abgeschlossen sind, bevor du mit dem nächsten Featureupgrade fortfährst. Der Status dieser Prozesse kann mit den Befehlszeilen-Hilfsprogrammen
ghe-migrationsundghe-check-background-upgrade-jobsgeprüft werden. Weitere Informationen finden Sie unter Befehlszeilenwerkzeuge. - Erstelle vor dem Upgrade deines virtuellen Computers eine Momentaufnahme. Weitere Informationen finden Sie unter Snapshot erstellen. Nachdem die Momentaufnahme erstellt wurde, solltest du automatische Momentaufnahmen deaktivieren, um mögliche Auswirkungen auf die Leistung während des Upgrades zu vermeiden.
- 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 eine Kapazitätsüberprüfung durchführen. Weitere Informationen finden Sie unter Überprüfen der Systemkapazität vor dem Upgrade.
- Du musst ein Upgrade aus einem Featurerelease durchführen, das mindestens zwei Releases zurückliegt. Um beispielsweise ein Upgrade auf GitHub Enterprise 3.20 durchzuführen, musst du über GitHub Enterprise 3.19 oder 3.18 verfügen.
- Wenn du mithilfe eines Upgradepakets ein Upgrade durchführst, solltest du ein Wartungsfenster für GitHub Enterprise Server-Endbenutzer*innen einplanen.
- 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. Sie werden bei Vorflugkontrollen benachrichtigt, falls nicht genügend Root-Datenträ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 Zeit und den Speicherplatz, die zum Wiederherstellen eines Snapshots benötigt werden. Ü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.
Nächste Schritte
Nachdem du diese Empfehlungen und Anforderungen gelesen hast, kannst du GitHub Enterprise Server upgraden. Weitere Informationen finden Sie unter Übersicht über den Upgradeprozess.