Skip to main content

Conditions à remplir pour la mise à niveau

Avant de mettre à niveau GitHub Enterprise Server, passez en revue ces recommandations et autres conditions pour planifier votre stratégie de mise à niveau.

Remarques :

  • Les packages de mise à niveau sont disponibles sur enterprise.github.com pour les versions prises en charge. Vérifiez la disponibilité des packages de mise à niveau dont vous aurez besoin pour effectuer la mise à niveau. Si un package n’est pas disponible, contactez le GitHub Enterprise Support pour obtenir de l’aide.
  • Si vous utilisez GitHub Enterprise Server Clustering, consultez « Mise à niveau d’un cluster » dans le Guide de GitHub Enterprise Server Clustering pour obtenir des instructions spécifiques propres au clustering.
  • Les notes de publication de GitHub Enterprise Server dressent une liste complète des nouvelles fonctionnalités pour chaque version de GitHub Enterprise Server. Pour plus d’informations, consultez la page concernant les versions.

Recommandations

  • Incluez le moins de mises à niveau possible dans votre processus de mise à niveau. Par exemple, au lieu d’effectuer une mise à niveau de GitHub Enterprise 3.5 vers 3.6 et 3.7, effectuez plutôt une mise à niveau de GitHub Enterprise 3.5 vers 3.7. Utilisez l’Upgrade assistant pour trouver le chemin de mise à niveau de votre version actuelle.
  • Si vous avez plusieurs versions de retard, mettez à niveau your GitHub Enterprise Server instance vers la version la plus haute possible à chaque étape de votre processus de mise à niveau. L’utilisation de la version la plus récente possible à chaque mise à niveau vous permet de tirer parti des améliorations sur le plan des performances et des correctifs de bogues. Par exemple, vous pourriez effectuer une mise à niveau de GitHub Enterprise 2.7 vers 2.8 et 2.10, mais en effectuant une mise à niveau de GitHub Enterprise 2.7 vers 2.9 et 2.10, vous utilisez une version plus récente à la deuxième étape.
  • Utilisez la dernière version corrective lors de la mise à niveau. Accédez à la page des versions de GitHub Enterprise Server. En regard de la version vers laquelle vous effectuez une mise à niveau, cliquez sur Télécharger, puis sur l’onglet Mise à niveau.
  • Utilisez une instance intermédiaire pour tester les étapes de mise à niveau. Pour plus d’informations, consultez « Configuration d’une instance intermédiaire ».
  • Quand vous exécutez plusieurs mises à niveau, attendez au moins 24 heures entre les mises à niveau de fonctionnalités pour permettre aux migrations de données et aux tâches de mise à niveau s’exécutant en arrière-plan de se terminer entièrement.
  • Capturez un instantané avant de mettre à niveau votre machine virtuelle. Pour plus d’informations, consultez « Capture d’un instantané ».
  • Vérifiez que vous disposez d’une sauvegarde récente et réussie de votre instance. Pour plus d’informations, consultez le fichier README GitHub Enterprise Server Backup Utilities.

Spécifications

  • Vous devez effectuer une mise à niveau à partir d’une mise en production de fonctionnalité dont l’antériorité ne doit pas être supérieure à deux versions. Par exemple, pour effectuer une mise à niveau vers GitHub Enterprise 3.7, vous devez être sur GitHub Enterprise 3.6 ou 3.5.
  • Quand vous effectuez une mise à niveau à partir d’un package de mise à niveau, planifiez une fenêtre de maintenance pour les utilisateurs finaux de GitHub Enterprise Server.
  • Vous pouvez mettre à niveau GitHub Enterprise Server vers la dernière version corrective en utilisant un patch à chaud.

Vous pouvez utiliser la mise à niveau à chaud pour effectuer une mise à niveau vers une version de correctif plus récente, mais pas une mise en production de fonctionnalité. Par exemple, vous pouvez effectuer une mise à niveau de 2.10.1 vers 2.10.5, car ils sont dans la même série de fonctionnalités, mais pas de 2.10.9 à 2.11.0, car ils se trouvent dans des séries de fonctionnalités différentes.

Les patchs à chaud ne nécessitent généralement pas de redémarrage. Si un patch à chaud nécessite un redémarrage, les notes de publication de GitHub Enterprise Server indiquent la configuration requise.

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 your GitHub Enterprise Server instance. 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. Pour plus d’informations, consultez « Activation et planification du mode maintenance ».

  • Un patch à chaud peut nécessiter un temps d’arrêt si les services affectés (comme le noyau, MySQL ou Elasticsearch) nécessitent un redémarrage de machine virtuelle ou un redémarrage de service. Vous serez averti en cas de redémarrage nécessaire. Vous pouvez effectuer le redémarrage à un moment ultérieur.
  • Vous devez disposer d’un stockage racine supplémentaire quand vous effectuez une mise à niveau via une mise à jour corrective à chaud, car cette opération passe par l’installation de plusieurs versions de certains services. Si vous n’avez pas suffisamment de stockage de disque racine, vous en serez averti par des vérifications préalables.
  • Quand vous effectuez une mise à niveau via une mise à jour corrective à chaud, votre instance ne peut pas être trop chargée, car cela peut avoir un impact sur le processus de mise à jour corrective à chaud.
  • Avec une mise à niveau vers GitHub Enterprise Server 2.17, vos journaux d’audit sont migrés de Elasticsearch vers MySQL. Cette migration a aussi pour effet d’accroître la durée et l’espace disque nécessaires à la restauration d’un instantané. Avant de procéder à la migration, vérifiez le nombre d’octets dans vos index de journal d’audit Elasticsearch avec cette commande :
    curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes
    Utilisez le nombre pour estimer la quantité d’espace disque dont les journaux d’audit MySQL auront besoin. Le script supervise aussi votre espace disque libre pendant l’importation. La supervision de ce nombre est particulièrement utile si votre espace disque libre est proche de la quantité d’espace disque nécessaire à la migration.

Étapes suivantes

Après avoir pris connaissance de ces recommandations et exigences, vous pouvez mettre à niveau GitHub Enterprise Server. Pour plus d’informations, consultez « Mise à niveau de GitHub Enterprise Server ».