Upgrade-Anforderungen

Empfehlungen

• Du solltest möglichst wenig Upgrades in deinen Upgrade-Prozess einbeziehen. Anstatt ein Upgrade von GitHub Enterprise 3.10 auf 3.11 und auf 3.12 durchzuführen, könntest du ein Upgrade von GitHub Enterprise 3.10 auf 3.12 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. Für die Verwendung von ghe-check-background-upgrade-jobs mit GitHub Enterprise Server 3.8 muss die Instanz die Version 3.8.12 oder eine höhere Version haben. Weitere Informationen sind unter „Befehlszeilenprogramme“ zu finden.
• Erstelle vor dem Upgrade deines virtuellen Computers eine Momentaufnahme. Weitere Informationen findest du unter Upgrade von GitHub Enterprise Server.
• 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.12 durchzuführen, musst du über GitHub Enterprise 3.11 oder 3.10 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 in der Regel keinen Neustart. Wenn ein Hotpatch einen Neustart erfordert, geben die GitHub Enterprise Server-Versionshinweise die Anforderung an.

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 findest du 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.

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 Upgrade von GitHub Enterprise Server.