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. Vous pouvez faire une mise à niveau vers une version Release Candidate à partir d’une version prise en charge, puis une mise à niveau de la version Release Candidate vers des versions plus récentes quand elles sont publiées. Vous devez mettre à niveau tout environnement exécutant une version Release Candidate dès que la version est en disponibilité générale. Pour plus d’informations, consultez « Conditions à remplir pour la mise à niveau ».
Les versions Release Candidate doivent être déployées sur des environnements de test ou de préproduction. 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 production stable.
Avertissement : la 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 ».
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 mettre à niveau votre entreprise 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.
Pour aller plus loin
- GitHub public roadmap dans le dépôt
github/roadmap