Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite kann noch im Gange sein. Die neuesten Informationen findest Du in der englischsprachigen Dokumentation. Informieren Sie uns bitte, falls auf dieser Seite ein Problem mit den Übersetzungen vorliegt.

Diese Version von GitHub Enterprise wurde eingestellt am 2020-11-12. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Upgrade-Anforderungen

Lesen Sie vor dem Upgrade von GitHub Enterprise Server diese Empfehlungen und Anforderungen zum Planen Ihrer Upgrade-Strategie.

Inhalt dieses Artikels

Hinweise:

  • Um ein Upgrade von GitHub Enterprise 11.10.348 bis 11.10.354 durchzuführen, müssen Sie zunächst zu GitHub Enterprise 2.1.23 migrieren. Weitere Informationen finden Sie unter „GitHub Enterprise von 11.10.x zu 2.1.23 migrieren“.
  • Upgrade-Pakete stehen unter enterprise.github.com für unterstützte Versionen zur Verfügung. Verifizieren Sie die Verfügbarkeit der Upgrade-Pakete, die Sie zum Abschließen des Upgrades benötigen. Wenden Sie sich an GitHub Enterprise-Support oder GitHub Premium-Support, falls ein Paket nicht verfügbar ist.
  • Wenn Sie GitHub Enterprise Server Clustering verwenden, finden Sie im GitHub Enterprise Server Clustering-Leitfaden unter „Cluster-Upgrade“ 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 Veröffentlichungsseite.

Empfehlungen

  • Sie sollten möglichst wenig Upgrades in Ihren Upgrade-Prozess einbeziehen. Anstatt beispielsweise ein Upgrade von GitHub Enterprise 2.20 auf 2.21 auf 2.22 vorzunehmen, können Sie ein Upgrade von GitHub Enterprise 2.20 auf 2.22 vornehmen.
  • Wenn Sie mehrere Versionen zurückliegen, sollten Sie your GitHub Enterprise Server instance 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. Navigieren Sie zur Seite GitHub Enterprise Server-Veröffentlichungen. Klicke neben dem Release, auf den Du ein Upgrade durchführst, auf Download, und klicke dann auf die Registerkarte Upgrading (Aktualisieren).
  • 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.22 vornehmen, müssen Sie GitHub Enterprise 2.21 oder 2.20 verwenden.
  • Sie können ein Upgrade von GitHub Enterprise Server auf die neueste Patch-Version durchführen. Verwenden Sie dazu einen Hotpatch, für den kein Wartungsfenster und in der Regel kein Neustart erforderlich ist. Mittels Hotpatching kannst Du ein Upgrade auf einen neueren Patch-Release durchführen, jedoch keine Feature-Veröffentlichung. So kannst Du beispielsweise ein Upgrade von 2.10.1 auf 2.10.5 durchführen, da sie sich in derselben Featureserie befinden, jedoch nicht von 2.10.9 auf 2.11.0, da sie sich in unterschiedlichen Featureserien befinden.
  • 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. Bei den Vorflugprüfungen wird die durchschnittliche Auslastung berücksichtigt und das Upgrade schlägt fehl, wenn die durchschnittliche Auslastung zu hoch ist.- Der Upgrade-Vorgang auf GitHub Enterprise Server 2.17 migriert Deine Überwachungsprotokolle von Elasticsearch zu MySQL. 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“.