Conditions à remplir pour la mise à niveau

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.12 vers 3.13 et 3.14, effectuez plutôt une mise à niveau de GitHub Enterprise 3.12 vers 3.14. Utilisez l’Assistant Mise à niveau pour trouver le chemin de mise à niveau de votre version actuelle.
• Si vous avez plusieurs versions de retard, mettez à niveau votre instance GitHub Enterprise Server 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 de préproduction ».
• Lors de l’exécution de plusieurs mises à niveau, vérifiez que les tâches de migration des données et de mise à niveau s’exécutant en arrière-plan sont entièrement terminées avant de passer à la prochaine mise à niveau de fonctionnalités. Pour vérifier l’état de ces processus, vous pouvez utiliser les utilitaires de ligne de commande ghe-migrations et ghe-check-background-upgrade-jobs. Pour utiliser ghe-check-background-upgrade-jobs avec GitHub Enterprise Server 3.10, votre instance doit exécuter la version 3.10.4 ou une version ultérieure. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».
• 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.14, vous devez être sur GitHub Enterprise 3.13 ou 3.12.
• 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, parce qu’ils sont dans la même série de fonctionnalités, mais pas de 2.10.9 vers 2.11.0 parce qu’ils sont dans des séries de fonctionnalités différentes.

Les mises à jour correctives à chaud ne nécessitent pas toujours de redémarrage. Lorsque vous installez le correctif à chaud, un message s’affiche dans le terminal si l’un des packages a besoin d’un redémarrage pour terminer la mise à jour. Vous pouvez planifier ce redémarrage à un moment commode, mais nous vous recommandons de redémarrer dès que possible, en particulier s’il existe des correctifs de sécurité.

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 ».

• 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.

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.

Problèmes connus

Passez en revue les problèmes connus pouvant s’appliquer à votre mise à niveau. Pour plus d’informations, consultez « Problèmes connus avec les mises à niveau de votre instance ».

Étapes suivantes

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