Skip to main content

Enterprise Server 3.20 ist derzeit als Release Candidate verfügbar.

Übersicht über den Upgradeprozess

Erfahre mehr über die Empfehlungen und Anforderungen für das Upgrade von GitHub Enterprise Server, damit du deine Upgradestrategie planen und testen kannst.

GitHub Enterprise Server wird ständig verbessert, und neue Funktionen und Fehlerkorrekturen werden über Feature- und Patchreleases eingeführt. Du bist für Upgrades deiner Instanz verantwortlich. Weitere Informationen findest du unter Über Upgrades auf neue Releases.

Um eine Instanz zu aktualisieren, musst du: 1. Deine Upgradestrategie planen. Wähle dazu deine Upgradeversion und das entsprechende Upgradepaket aus und plane ein Wartungsfenster ein. 1. Das Upgrade kommunizieren, vor und während des Upgradeprozesses. 1. Deine Sicherungsstrategie vorbereiten. Erstelle dazu ein Backup und eine Momentaufnahme des virtuellen Computers. 1. Das Upgradepaket mit dem entsprechenden Paket und Verfahren installieren. 1. Aufgaben nach dem Upgrade ausführen.

Der Prozess für die Anwendung eines Upgradepakets hängt von der Anzahl der Knoten in deiner Bereitstellungstopologie ab. Dieser Artikel enthält allgemeine Informationen zum Aktualisieren von Instanzen in einer eigenständigen oder hochverfügbaren Konfiguration.

Planen deiner Upgradestrategie

Upgrade planen

  • Überprüfe die Versionshinweise und dokumentierte bekannte Probleme, bevor du ein Upgrade durchführst. Weitere Informationen findest du unter Versionshinweise und Bekannte Probleme mit Upgrades für deine Instanz.
  • Überprüfe Upgrade-Anforderungen, um die Anforderungen und Empfehlungen für ein Upgrade zu verstehen.
  • Überprüfe, ob die Datenfestplatte von Ihre GitHub Enterprise Server-Instance mindestens zu 15 % frei ist. GitHub empfiehlt jedoch zusätzlichen freien Speicherplatz auf dem Datenträger. In einigen seltenen Fällen kann dieser Schwellenwert für Kundschaft mit großen Datenvolumen abweichen. Weitere Informationen findest du unter Speicherkapazität erhöhen.
  • Überprüfe, dass du über ausreichende Hardwareressourcen für GitHub Enterprise Server verfügst. 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.
  • Stelle sicher, dass du über eine Kopie aller benutzerdefinierten Firewallregeln für Ihre GitHub Enterprise Server-Instance verfügst, da angepasste Regeln nach dem Upgrade nicht beibehalten werden. Du musst alle benutzerdefinierten Regeln nach dem Upgrade erneut anwenden. Weitere Informationen findest du unter Integrierte Firewallregeln konfigurieren.
  • Überprüfe bei Instanzen in einer Konfiguration für hohe Verfügbarkeit, ob der Replikationsstatus vor dem Upgrade auf OK steht. Weitere Informationen findest du unter Überwachen einer Hochverfügbarkeitskonfiguration.
  • Erwäge die Konfiguration der IP-Ausnahmeliste für den Wartungsmodus, sodass du den Zugriff auf Ihre GitHub Enterprise Server-Instance vorübergehend einschränken kannst, um den Serverzustand nach einem Upgrade zu überprüfen. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.

Wählen Sie Ihre Version und Ihr Paket für das Upgrade

  • Bestimme eine Upgrade-Strategie, und wähle eine Version aus, auf die das Upgrade durchgeführt werden soll.
    • Du kannst eine GitHub Enterprise Server-Instanz auf ein neues Patchrelease oder ein neues Featurerelease aktualisieren.
    • Verwende den Upgrade-Assistent, um den Upgradepfad zu einem neuen Patch oder Featurerelease von deinem aktuellen Release aus zu finden.
  • Wähle ein Upgradepaket (Hotpatch oder Upgradepaket) aus.
    • Für ein Upgrade auf ein Patchrelease kannst du einen Hotpatch oder ein Upgradepaket verwenden. Für ein Upgrade auf ein Featurerelease musst du ein Upgradepaket verwenden.
    • Wenn du ein Upgradepaket verwendest, solltest du ein Wartungsfenster für GitHub Enterprise Server-Endbenutzer einplanen. Bei Verwendung eines Hotpatches muss der Wartungsmodus nicht verwendet werden.
    • Wenn di automatische Updateprüfungen aktiviert hast, werden die Websiteadministratoren benachrichtigt, dass ein Upgradepaket heruntergeladen wurde und verfügbar ist. Weitere Informationen findest du unter Prüfungen auf automatische Updates aktivieren.
    • Releasekandidat-Versionen sind ausschließlich für die Verwendung in einer Testumgebung vorgesehen. Installieren Sie keinen Release-Kandidat-Build in einem Produktionsumfeld. Führen Sie kein Upgrade vom Releasekandidaten auf spätere Versionen durch, einschließlich allgemein verfügbarer Releases.

Überlege, ob andere Anwendungsupdates erforderlich sind.

Überprüfe, ob die die folgenden Anwendungen aktualisieren musst:

  • GitHub Actions-Runners müssen aktualisiert werden, wenn Ihre GitHub Enterprise Server-Instance kurzlebige selbstgehostete Runner für GitHub Actions verwendet und automatische Updates deaktiviert sind. Aktualisiere die Ausführungsumgebungen auf die Mindestversion der Anwendung, die von deiner aktualisierten Instanz benötigt wird, bevor du das Upgrade durchführst. Die für dein Release erforderliche Mindestversion findest du unter Veröffentlichungen von GitHub Enterprise Server.

  • GitHub Enterprise Server Backup Utilities. Deine GitHub Enterprise Server Backup Utilities-Version muss dieselbe Version sein, oder höchstens zwei Versionen höher als Ihre GitHub Enterprise Server-Instance.

    • Möglicherweise musst du GitHub Enterprise Server Backup Utilities auf eine neuere Version aktualisieren, bevor du die Instanz aktualisierst.
    • Du kannst auch planen, GitHub Enterprise Server Backup Utilities auf eine neuere Version zu aktualisieren, nachdem du die Instanz aktualisiert hast.

    Siehe Konfigurieren von Sicherungen auf deiner Instanz mithilfe von Sicherungshilfsprogrammen und README in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.

Planen eines Wartungsfensters

  • Je nach Upgradestrategie sind möglicherweise erhebliche Ausfallzeiten notwendig.
  • Die erwartete Dauer der Ausfallzeiten kann am besten durch das Testen des Upgrades in einer Stagingumgebung bestimmt werden. Weitere Informationen findest du unter Testinstanz einrichten.
  • Das Wartungsfenster hängt vom Typ des Upgrades ab, das du ausführst.
    • Für Upgrades mittels Hotpatch ist in der Regel kein Wartungsfenster erforderlich. Manchmal ist ein Neustart erforderlich, den du später durchführen kannst.

      Hinweis

      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.

    • Das Upgrade mit einem Upgradepaket dauert in der Regel weniger als fünf Minuten.

    • Das Upgrade auf ein neues Featurerelease, die Datenmigrationen beinhaltet, kann abhängig von der Speicherleistung und der migrierten Datenmenge einige Stunden dauern. Während dieser Zeit kann kein Benutzer das Unternehmen verwenden. Möglicherweise stellst du fest, dass Upgrades auf ein neues Featurerelease weniger Zeit in Anspruch nehmen. Das liegt daran, dass selektive Datenbankübergänge jetzt gleichzeitig ausgeführt werden, wobei die Anzahl der gleichzeitigen Worker standardmäßig auf die Anzahl der CPU-Kerne festgelegt ist, bis zu einem Maximum von 16.

Kommunizieren des Upgrades

  • Vor dem Upgrade kannst du ein globales Ankündigungsbanner veröffentlichen, um wichtige Informationen für deine Benutzer hervorzuheben, z. B. zukünftige Änderungen oder mögliche Ausfallzeiten. Weitere Informationen findest du unter Anpassen von Benutzernachrichten für dein Unternehmen.
  • Zum Zeitpunkt des Upgrades kannst du den Wartungsmodus aktivieren und eine benutzerdefinierte Meldung festlegen, um Benutzer darüber zu informieren, dass die Instanz vorübergehend nicht verfügbar ist. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.

Vorbereiten der Backupstrategie

Erstellen eines Sicherungssnapshots

Stelle sicher, dass du über eine aktuelle, erfolgreiche Sicherungsmomentaufnahme des primären Knotens deiner Instanz verfügst, bevor du den Upgradevorgang startest. Siehe Konfigurieren von Sicherungen auf deiner Instanz mithilfe von Sicherungshilfsprogrammen und das README in der GitHub Enterprise Server Backup Utilities-Projektdokumentation.

Erstellen einer Momentaufnahme eines virtuellen Computers

Wenn du ein Upgrade auf eine neue Featureversion durchführst, ist eine Momentaufnahme eines virtuellen Computers (VM) erforderlich. Wenn du ein Upgrade auf ein Patchrelease durchführst, kannst du den vorhandenen Datenträger anhängen.

Erstelle unmittelbar vor dem Upgrade eine Momentaufnahme des virtuellen Computers (VM) des primären Knotens deiner Instanz. Tu dies erst, wenn der Wartungsmodus aktiviert oder die Instanz abgeschaltet wurde. Weitere Informationen findest du unter Snapshot erstellen.

Installieren eines Upgradepakets

Beachte die Überlegungen zu Upgrades und führe alle Schritt für die Vorbereitung wie oben beschrieben aus, bevor du mit der Installation eines Upgradepakets beginnst.

Die Anweisungen für das Upgrade deiner GitHub Enterprise Server-Instanz unterscheiden sich je nach Typ des ausgeführten Upgrades und Anzahl der Knoten deiner Instanz.

Ausführen von Aufgaben nach dem Upgrade

  • Überprüfe den Status von Hintergrundaufträgen und überprüfe das Upgradeprotokoll auf Fehler.
  • Überprüfe die grundlegenden GitHub Enterprise Server-Funktionalität. Stelle beispielsweise sicher, dass du dich über die Benutzeroberfläche anmelden kannst, und überprüfe, dass du auf mehrere deiner Organisationen, Repositorys und Issues wie erwartet zugreifen kannst. Außerdem empfiehlt es sich, mehrere Git-Abrufe, Klonen und Pushs mithilfe von SSH und/oder HTTPS manuell auszuführen und zu überprüfen, ob API-Anforderungen und Webhook-Lieferungen erfolgreich abgeschlossen wurden.
  • Wende die benutzerdefinierten Firewallregeln erneut an. Weitere Informationen findest du unter Integrierte Firewallregeln konfigurieren.
  • Lösche alle VM-Momentaufnahmen, die vor dem Upgrade erstellt wurden. Weitere Informationen findest du unter Snapshot erstellen.
  • Deaktiviere den Wartungsmodus, und aktualisiere alle Kommunikation zum Upgrade, z. B. Ankündigungsbanner. Weitere Informationen findest du unter Anpassen von Benutzernachrichten für dein Unternehmen und Wartungsmodus aktivieren und planen.
  • Überwache alle in die Warteschlange gestellten Hintergrundaufträge in deiner Instanz, um sicherzustellen, dass sie erfolgreich abgeschlossen wurden. Weitere Informationen findest du unter Befehlszeilenwerkzeuge.