Upgrade-Anforderungen

Empfehlungen

• Sie sollten möglichst wenig Upgrades in Ihren Upgrade-Prozess einbeziehen. Anstatt beispielsweise ein Upgrade von GitHub Enterprise 2.16 auf 2.17 auf 2.18 vorzunehmen, können Sie ein Upgrade von GitHub Enterprise 2.16 auf 2.18 vornehmen.
• Wenn Sie mehrere Versionen zurückliegen, sollten Sie Ihre GitHub Enterprise Server-Instanz so weit wie möglich mit jedem Schritt Ihres Upgrade-Prozesses upgraden. Wenn Sie die nach Möglichkeit neueste Version für jedes Upgrade verwenden, können Sie von Leistungsverbesserungen und Bug-Korrekturen profitieren. So können Sie 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.
• Verwenden Sie beim Upgraden die neueste Patch-Veröffentlichung. Browse to the GitHub Enterprise Server Releases page. Next to the release you are upgrading to, click Download, then click the Upgrading tab.
• Verwenden Sie eine Testinstanz zum Testen der Upgrade-Schritte. Weitere Informationen finden Sie unter „Testinstanz einrichten“.
• Warten Sie beim Ausführen mehrerer Upgrades mindestens 24 Stunden zwischen den Feature-Upgrades, damit Datenmigrationen und Upgrade-Hintergrundaufgaben vollständig abgeschlossen werden.

Anforderungen

• Sie müssen ein Upgrade von einer Feature-Veröffentlichung vornehmen, die höchstens zwei Versionen zurückliegt. Wenn Sie beispielsweise ein Upgrade auf GitHub Enterprise 2.18 vornehmen, müssen Sie GitHub Enterprise 2.17 oder 2.16 verwenden.

• You can upgrade GitHub Enterprise Server 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.1 to 2.10.5 because they are in the same feature series, but not from 2.10.9 to 2.11.0 because they are in a different feature series.

• 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. Sie werden benachrichtigt, falls ein Neustart erforderlich ist. Sie können 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. Preflight-Checks benachrichtigen Sie, falls nicht genügend Root-Disk-Storage verfügbar ist.

• Beim Upgrade mittels Hotpatching darf Ihre Instanz keine zu große Auslastung aufweisen, da sich dies ggf. auf den Hotpatching-Prozess auswirkt. Preflight-Checks berücksichtigen die durchschnittliche Auslastung, und das Upgrade schlägt bei einer zu hohen durchschnittlichen Auslastung fehl.

• Beim Upgrade auf GitHub Enterprise Server 2.17 werden Ihre 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üfen Sie vor der Migration die Anzahl an Bytes in Ihren ElasticSearch-Auditprotokollindizes. Führen Sie dazu den folgenden Befehl aus:

  curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes

  Anhand der Zahl können Sie 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.

Nachdem Sie diese Empfehlungen und Anforderungen gelesen haben, können Sie GitHub Enterprise Server upgraden. Weitere Informationen finden Sie unter „Upgrade von GitHub Enterprise Server“.