Upgrade-Anforderungen

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.11 zu verwenden, muss Ihre Instanz die Version 3.11.1 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.

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.