GitHub Enterprise Server 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.
Les mises en production de fonctionnalité, généralement publiées tous les trimestres, incluent des nouveautés et des mises à niveau.
À compter de la version GitHub Enterprise Server 3.0, toutes les mises en production de fonctionnalité sont précédées d’au moins une version Release Candidate. Les versions Release Candidate sont des propositions de mises en production de fonctionnalité complètes. Elles peuvent contenir des bogues et présenter certains problèmes qui ne peuvent être identifiés qu’à l’aide des commentaires des clients utilisant effectivement GitHub Enterprise Server.
Vous pouvez accéder en avant-première aux fonctionnalités les plus récentes en testant une version Release Candidate dès sa mise à disposition.
Pour des raisons de performances, de stabilité et de sécurité :
- N’installez pas de RC dans un environnement de production. L’utilisation des builds RC (Release Candidate) est exclusivement réservée aux environnements intermédiaires ou de test.
- Ne mettez pas à niveau vers une version RC à partir d’une version antérieure prise en charge. Au lieu de cela, installez une version RC dans un nouvel environnement de test.
- Ne mettez pas à niveau une version RC vers les versions ultérieures lorsqu’elles sont publiées, y compris les versions en disponibilité générale. Au contraire, détruisez l’environnement de la version RC dès que la version en disponibilité générale est disponible.
Quand vous testez une version Release Candidate, envoyez vos commentaires en contactant le support. Pour plus d’informations, consultez « Documentation GitHub Support ».
Nous utiliserons vos commentaires pour appliquer des correctifs de bogues et toute autre modification nécessaire à la création d’une version de production stable. Chaque nouvelle version Release Candidate apporte des correctifs de bogues visant à résoudre les problèmes détectés dans les versions précédentes. Quand la version est prête pour une adoption généralisée, GitHub publie une version de fonctionnalité stable.
Les mises en production de patchs, qui incluent uniquement des patchs à chaud et des correctifs de bogues sont publiées plus fréquemment. Elles sont en disponibilité générale dès la première publication et ne sont pas précédées de versions Release Candidate. La mise à niveau vers une mise en production de patchs nécessite généralement moins de cinq minutes de temps d’arrêt.
Pour configurer une nouvelle instance GitHub Enterprise Server et configurer l’instance comme vous le souhaitez, consultez « Configuration d’une instance GitHub Enterprise Server » et « Configuration de GitHub Enterprise ».
Pour mettre à niveau votre instance existante vers une nouvelle version, consultez « Notes de publication » et « Mise à niveau de GitHub Enterprise Server ». Étant donné que vous pouvez effectuer une mise à niveau uniquement à partir d’une mise en production de fonctionnalité dont la version est antérieure de deux niveaux au maximum, utilisez l’Assistant Mise à niveau pour connaître le chemin de mise à niveau à partir de votre version actuelle.
Warning
Une mise à niveau vers une nouvelle mise en production de fonctionnalité entraîne quelques heures d’arrêt, pendant lesquelles aucun de vos utilisateurs ne pourra utiliser l’entreprise. Vous pouvez informer vos utilisateurs de ce temps d’arrêt en publiant une bannière d’annonce globale à l’aide de vos paramètres d’entreprise ou de l’API REST. Pour plus d’informations, consultez « Personnalisation des messages utilisateur pour votre entreprise » et « Points de terminaison d’API REST pour l’administration GitHub Enterprise ».
Pour aller plus loin
- GitHub public roadmap dans le dépôt
github/roadmap