s’améliore constamment grâce aux mises en production de fonctionnalités et de patchs. Celles-ci incluent en effet 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 mises en production.
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 est gratuit d’au moins 15 %. GitHub recommande de vous assurer qu’il y a davantage de stockage libre 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.
- Pour les instances d’une configuration à haute disponibilité, vérifiez que l’état des rapports de réplication
OKavant la mise à niveau. Consultez Surveillance d’une configuration de haute disponibilité. - Envisagez de configurer la liste d’exceptions IP pour le mode maintenance. Vous pouvez donc limiter temporairement l’accès à votre instance GitHub Enterprise Server pour valider l’intégrité 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 instance GitHub Enterprise Server vers une nouvelle version corrective ou vers une nouvelle version de fonctionnalité.
- Se référer à Assistant Mise à niveau pour trouver le chemin de mise à niveau de votre version actuelle vers une nouvelle version de correctif ou de fonctionnalité.
- Choisissez un package de mise à niveau (patch à chaud ou package 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 les utilisateurs finaux de GitHub Enterprise Server. 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. Ne mettez pas à niveau une version finale (RC) vers les versions ultérieures, y compris les versions en disponibilité générale.
Déterminez si d’autres mises à jour d’application sont requises
Vérifiez si vous devez mettre à niveau les applications suivantes :
-
Les exécuteurs GitHub Actions doivent être mis à jour si votre instance GitHub Enterprise Server utilise des exécuteurs 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 Versions de GitHub Enterprise Server.
-
GitHub Enterprise Server Backup Utilities. Votre version GitHub Enterprise Server Backup Utilities doit être identique à, ou au plus deux versions ultérieures à votre instance GitHub Enterprise Server.
- Vous devrez peut-être mettre à niveau GitHub Enterprise Server Backup Utilities vers une version plus récente, avant de mettre à niveau votre instance.
- Vous pouvez également planifier la mise à niveau de GitHub Enterprise Server Backup Utilities vers une version plus récente après la mise à niveau de votre instance.
Consultez Configuration des sauvegardes sur votre instance et le README dans la documentation du projet GitHub Enterprise Server Backup Utilities.
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.
Note
Les patchs à chaud nécessitent une exécution de configuration, qui peut provoquer 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 de fonctionnalité qui inclut des migrations de données peut entraîner quelques heures de temps d’arrêt, 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.
-
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 Configuration des sauvegardes sur votre instance et le README dans la documentation du projet GitHub Enterprise Server Backup Utilities.
Créer un instantané de la machine virtuelle
Si vous effectuez une mise à niveau vers une nouvelle version de fonctionnalité, un instantané de machine virtuelle est requis. Si vous effectuez une mise à niveau vers une version corrective, vous pouvez joindre le disque de données existant.
Créez un instantané de machine virtuelle du nœud principal de votre instance immédiatement avant la mise à niveau, et uniquement lorsque le mode maintenance a été activé ou que l’instance a été mise hors tension. Consultez Capture d’un instantané.
Installation d’un package de mise à niveau
Passez en revue les considérations relatives aux mises à niveau et effectuez les étapes de préparation décrites ci-dessus avant de commencer à installer un package de mise à niveau.
Les instructions de mise à niveau de votre instance GitHub Enterprise Server diffèrent selon le type de mise à niveau que vous effectuez et le nombre de nœuds dont votre instance dispose.
Exécution des tâches postérieures à la mise à niveau
- 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 de GitHub Enterprise Server. Par exemple, vérifiez que vous pouvez vous connecter via l’interface utilisateur et vérifier que plusieurs de vos organisations, référentiels et problèmes peuvent être atteints 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.