Vue d'ensemble du processus de mise à niveau

GitHub Enterprise Server s’améliore constamment grâce aux mises en production de fonctionnalités et de patchs, qui incluent de nouvelles fonctionnalités et des correctifs de bogues. Vous êtes responsable des mises à niveau vers votre instance. Consultez À propos des mises à niveau vers de nouvelles versions.

Pour mettre à niveau une instance, vous devez :

Planifiez votre stratégie de mise à niveau en choisissant votre version de mise à niveau et le package de mise à niveau approprié et en planifiant une fenêtre de maintenance.
Communiquez la mise à niveau avant et pendant le processus de mise à niveau.
Préparez votre stratégie de sauvegarde en créant une sauvegarde et en prenant un instantané de machine virtuelle.
Installez le package de mise à niveau à l’aide du package et de la méthode appropriés.
Effectuez les tâches postérieures à la mise à niveau.

Le processus que vous devez suivre pour appliquer un package de mise à niveau dépend du nombre de nœuds dans votre topologie de déploiement. Cet article fournit des informations générales sur la mise à niveau d’instances dans une configuration autonome ou haute disponibilité uniquement.

Planification de votre stratégie de mise à niveau

Planifier votre mise à niveau

Passez en revue les notes de publication et les problèmes connus documentés avant d’effectuer une mise à niveau. Consultez Notes de publication et Problèmes connus avec les mises à niveau de votre instance.
Passez en revue Conditions à remplir pour la mise à niveau pour vous assurer que vous comprenez les exigences et les recommandations relatives à la mise à niveau.
Vérifiez que le disque de données de votre instance GitHub Enterprise Server dispose d’au moins 15 % d’espace libre. GitHub recommande de s’assurer qu’il existe un stockage gratuit supplémentaire sur le disque. Dans certains cas rares, pour les clients avec de grands volumes de données, ce seuil peut différer. Consultez Augmentation de la capacité de stockage.
Vérifiez que vous disposez de ressources matérielles suffisantes pour GitHub Enterprise Server. Lors de la mise à niveau, les vérifications de préversion évaluent si la configuration minimale requise pour les ressources matérielles système, telles que la mémoire, les cœurs de processeur et le stockage sur disque racine et utilisateur, sont disponibles pour votre instance. Si les vérifications de préversion déterminent qu’il y a des ressources insuffisantes ou échouent, vous êtes averti et la mise à niveau est abandonnée.
Vérifiez que vous disposez d’une copie de toutes les règles de pare-feu personnalisées pour votre instance GitHub Enterprise Server, car les règles personnalisées ne persistent pas après la mise à niveau. Vous devez réappliquer toutes les règles personnalisées suivant la mise à niveau. Consultez Configuration de règles de pare-feu intégrées.
Dans le cas d’une configuration à haute disponibilité, par exemple, vérifiez que l’état de la réplication indique OK avant de procéder à la mise à niveau. Consultez Surveillance d’une configuration de haute disponibilité.
Pensez à configurer la liste des exceptions IP pour le mode de maintenance, afin de pouvoir limiter temporairement l’accès à votre instance GitHub Enterprise Server et valider le bon fonctionnement de votre serveur après une mise à niveau. Consultez Activation et planification du mode de maintenance.

Choisir votre version et votre package de mise à niveau

Établissez une stratégie de mise à niveau et choisissez la version cible de la mise à niveau.
- Vous pouvez mettre à niveau une GitHub Enterprise Server instance vers une nouvelle version de correctif ou vers une nouvelle version de fonctionnalité.
- Reportez-vous à la section Assistant de mise à niveau pour trouver le chemin de mise à niveau de votre version actuelle vers une nouvelle version corrective ou une version de fonctionnalité.
Choisissez un paquet de mise à niveau (correctif à chaud / paquet de mise à niveau).
- Pour effectuer une mise à niveau vers une version corrective, vous pouvez utiliser un patch à chaud ou un package de mise à niveau. Pour effectuer une mise à niveau vers une version de fonctionnalité, vous devez utiliser un package de mise à niveau.
- Si vous utilisez un package de mise à niveau, planifiez une fenêtre de maintenance pour GitHub Enterprise Server les utilisateurs finaux. Si vous utilisez un patch à chaud, le mode maintenance n’est pas obligatoire.
- Si vous avez activé les vérifications de mise à jour automatique, les administrateurs de site sont avertis qu’un package de mise à niveau a été téléchargé et est disponible. Consultez Activation de la recherche de mises à jour automatiques.
- L’utilisation des builds version finale (RC) est exclusivement réservée aux environnements de test. N'installez pas une version finale (RC) dans un environnement de production. Abstenez-vous d’effectuer une mise à niveau d’une version candidate vers des versions ultérieures, y compris vers les versions généralement disponibles.

Déterminez si d’autres mises à jour d’application sont requises

Vérifiez si vous devez mettre à niveau les applications suivantes :

GitHub Actions Les runners doivent être mis à jour si votre instance GitHub Enterprise Server utilise des runners auto-hébergés éphémères pour GitHub Actions et que les mises à jour automatiques sont désactivées. Mettez à niveau les exécuteurs vers la version minimale de l’application requise par votre instance mise à niveau, avant d’effectuer votre mise à niveau. Pour trouver la version minimale requise pour votre version, consultez Publications de GitHub Enterprise Server.
GitHub Enterprise Server Backup Utilities. Votre version GitHub Enterprise Server Backup Utilities doit être identique à celle de votre instance GitHub Enterprise Server, ou avoir au maximum deux versions d’avance sur votre instance GitHub Enterprise Server.
- Vous devrez peut-être effectuer une mise à niveau vers une version plus récente avant de mettre GitHub Enterprise Server Backup Utilities à niveau votre instance.
- Vous pouvez également planifier la mise à niveau GitHub Enterprise Server Backup Utilities vers une version plus récente après la mise à niveau de votre instance.
Consultez Configurer les sauvegardes sur votre instance à l’aide des Utilitaires de sauvegarde et README dans la documentation du GitHub Enterprise Server Backup Utilities projet.

Planifier une fenêtre de maintenance

Selon votre stratégie de mise à niveau, un temps d’arrêt important peut être nécessaire.
La meilleure façon de déterminer la durée attendue du temps d’arrêt consiste à tester d’abord votre mise à niveau dans un environnement intermédiaire. Consultez Configuration d’une instance de préproduction.
La fenêtre de maintenance de votre mise à niveau dépend du type de mise à niveau que vous effectuez.
- Les mises à niveau utilisant un patch à chaud ne nécessitent généralement pas de fenêtre de maintenance. Parfois, un redémarrage est exigé, ce que vous pouvez faire ultérieurement.
  
  Remarque
  
  Les correctifs à chaud nécessitent l’exécution d’une configuration, ce qui peut entraîner une brève période d’erreurs ou d’absence de réponse pour tout ou partie des services sur votre instance GitHub Enterprise Server. Vous n’êtes pas obligé d’activer le mode maintenance pendant l’installation d’un patch à chaud, mais cela garantit que les utilisateurs voient une page de maintenance au lieu de messages d’erreur ou d’expiration de délai. Consultez Activation et planification du mode de maintenance.
- Les mises à jour de correctifs à l'aide d'un package de mise à niveau nécessitent généralement moins de cinq minutes de temps d’arrêt.
- La mise à niveau vers une nouvelle version incluant des migrations de données peut entraîner quelques heures d'indisponibilité, en fonction des performances de stockage et de la quantité de données migrées. Pendant ce temps, aucun de vos utilisateurs ne pourra utiliser l’entreprise. Vous remarquerez peut-être que les mises à niveau vers une nouvelle version de fonctionnalité prennent moins de temps. Cela s’explique par le fait que les transitions sélectives de bases de données s’exécuteront désormais en parallèle, le nombre de processus de travail simultanés étant par défaut égal au nombre de cœurs du processeur, dans la limite de 16.

Communication de votre mise à niveau

Avant votre mise à niveau, vous pouvez publier une bannière d’annonce globale pour mettre en évidence des informations importantes pour vos utilisateurs, telles que les modifications entrantes ou les temps d’arrêt possibles. Consultez Personnalisation des messages utilisateur pour votre entreprise.
Au moment de la mise à niveau, vous pouvez activer le mode maintenance et définir un message personnalisé pour informer les utilisateurs que l’instance n’est pas disponible temporairement. Consultez Activation et planification du mode de maintenance.

Préparation de votre stratégie de sauvegarde

Créer un instantané de sauvegarde

Vérifiez que vous disposez d’un instantané de sauvegarde récent et réussi du nœud principal de votre instance avant de démarrer le processus de mise à niveau. Consultez Configurer les sauvegardes sur votre instance à l’aide des Utilitaires de sauvegarde et README dans la documentation du GitHub Enterprise Server Backup Utilities projet.

Vérifiez l’état des travaux en arrière-plan et examinez le journal de mise à niveau pour les erreurs.
Vérifiez les fonctionnalités de base GitHub Enterprise Server . Assurez-vous, par exemple, que vous pouvez vous connecter via l'interface utilisateur et vérifiez que plusieurs de vos organisations, référentiels et problèmes sont accessibles comme prévu. Il est également judicieux d’exécuter manuellement plusieurs extractions, clones et envois (push) Git à l’aide de SSH et/ou HTTPS, et de vérifier que les demandes d’API et les remises de webhook se terminent correctement.
Réappliquez toutes les règles de pare-feu personnalisées. Consultez Configuration de règles de pare-feu intégrées.
Supprimez les instantanés de machine virtuelle pris avant la mise à niveau. Consultez Capture d’un instantané.
Désactivez le mode maintenance et mettez à jour toutes les communications de pré-mise à niveau, telles que les bannières d’annonce. Consultez Personnalisation des messages utilisateur pour votre entreprise et Activation et planification du mode de maintenance.
Surveillez tous les travaux en arrière-plan mis en file d’attente sur votre instance pour vous assurer qu’ils se terminent correctement. Consultez Utilitaires de ligne de commande.

Dans cet article