Skip to main content

Upgrade-Anforderungen

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

Hinweise:

  • 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. Wende dich an GitHub Enterprise Support, falls ein Paket nicht verfügbar ist.
  • Wenn du GitHub Enterprise Server-Clustering verwendest, lies Upgraden eines Clusters im GitHub Enterprise Server-Clusteringleitfaden für clusteringspezifische Anweisungen.
  • 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.5 auf 3.6 und auf 3.7 durchzuführen, könntest du ein Upgrade von GitHub Enterprise 3.5 auf 3.7 durchführen. Verwende den Upgrade assistant, um den Upgradepfad aus deinem aktuellen Release zu finden.
  • Wenn du mehrere Versionen im Rückstand bist, aktualisiere your 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 Einrichten einer Staginginstanz.
  • Warte beim Durchführen mehrerer Upgrades mindestens 24 Stunden zwischen den Feature-Upgrades, damit im Hintergrund laufende Datenmigrationen und Upgrade-Aufgaben vollständig abgeschlossen werden.
  • Erstelle vor dem Upgrade deines virtuellen Computers eine Momentaufnahme. Weitere Informationen findest du unter Eine Momentaufnahme 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.

Requirements (Anforderungen)

  • Du musst ein Upgrade aus einem Featurerelease durchführen, das mindestens zwei Releases zurückliegt. Um beispielsweise ein Upgrade auf GitHub Enterprise 3.7 durchzuführen, musst du über GitHub Enterprise 3.6 oder 3.5 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, weil sich beide Releases in derselben Featurereihe befinden. Ein Upgrade von 2.10.9 auf 2.11.0 ist hingegen nicht möglich, weil diese Releases unterschiedlichen Featurereihen 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 your 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 „Aktivieren und Planen des Wartungsmodus“.

  • 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.

Nächste Schritte

Nachdem du diese Empfehlungen und Anforderungen gelesen hast, kannst du GitHub Enterprise Server upgraden. Weitere Informationen findest du unter Upgrade für GitHub Enterprise Server durchführen.