Release candidate (RC) : définition et mode d'emploi

Une release candidate (RC) est un build que l’équipe estime prêt à être livré. Il est complet fonctionnellement, il a passé les tests prévus, et il devient la version finale sans modification, sauf si quelqu’un trouve un bug assez grave pour la bloquer. L’étiquette est une promesse sur le build : pas de nouvelle fonctionnalité, seulement des corrections de blocages. Si une correction est nécessaire, l’équipe produit une nouvelle candidate et relance le compte à rebours.

Qu’est-ce qu’une release candidate en logiciel ?

C’est la dernière étape de pré-release avant la disponibilité générale. L’idée est que le build est candidat à la version finale, et que la release se fait en promouvant ce même build plutôt qu’en en fabriquant un nouveau. L’article de Wikipédia sur le cycle de vie des versions logicielles décrit la même séquence alpha, bêta, release candidate et release, et ces termes sont largement compris dans les projets open source et chez les éditeurs.

Quelle est la différence entre bêta et release candidate ?

Une bêta peut encore changer. Les fonctionnalités peuvent être ajustées, les interfaces peuvent bouger, et le but est d’apprendre ce qui manque ou ce qui ne va pas. Une release candidate a cessé de changer de cette façon, et le but est de confirmer que rien ne bloque la release. Le test pratique est ce que l’équipe fait d’un rapport de bug. Dans une bêta, un rapport peut mener à un changement de conception. Dans une RC, un rapport mène à une correction seulement si le bug empêche de livrer, et tout le reste est mis en file pour la version suivante.

Comment versionner une release candidate ?

Utilisez un suffixe de pré-release sur la version que vous allez livrer. Avec le Semantic Versioning, un trait d’union suivi d’identifiants séparés par des points marque une pré-release, donc la première candidate pour 2.4.0 est 2.4.0-rc.1, la suivante 2.4.0-rc.2, et la release est simplement 2.4.0.

La précédence suit la spécification : 2.4.0-rc.1 se classe sous 2.4.0-rc.2, et toute pré-release se classe sous la release. Comme les identifiants sont comparés un par un et que les nombres se comparent numériquement, rc.10 se classe au-dessus de rc.9. Les noms alpha, beta et rc se trient aussi dans le bon ordre alphabétique, ce qui explique en partie pourquoi les équipes les utilisent. Taguez chaque candidate dans git, comme décrit dans tags git et releases, pour que le commit exact soit consigné.

Quels sont les critères de sortie d’une release candidate ?

Écrivez-les avant de produire la première RC. Un ensemble réaliste :

• La suite de tests automatisés passe sur le commit exact qui a été construit.
• Le chemin de mise à niveau depuis la release précédente a été testé avec des données réalistes.
• Les problèmes connus sont triés, et aucun n’est jugé bloquant.
• Les performances et les taux d’erreur correspondent à la release précédente, dans une marge convenue.
• Les release notes sont rédigées et relues par rapport à la liste finale des changements.
• Un chemin de rollback existe et quelqu’un l’a lu.

Quand chaque ligne est vraie pour une candidate, cette candidate est la release. Si une ligne échoue, la correction produit une nouvelle candidate et les vérifications repartent. La version en sept étapes de ce flux, avec un responsable pour chacune, se trouve dans le processus de release management.

Que faire du build quand une RC est validée ?

Promouvoir le même artefact. Ne reconstruisez pas depuis le tag, car une reconstruction peut embarquer une autre dépendance ou une autre sortie de compilateur, et les tests que vous avez faits s’appliquaient au build d’origine. Beaucoup d’équipes renomment la candidate en re-taguant ou en repointant une étiquette de registre, pour que les octets testés soient ceux que les utilisateurs téléchargent.

Pour les paquets, publiez les candidates sur un canal séparé afin que les utilisateurs ordinaires ne les reçoivent pas par accident. Avec npm, npm publish --tag rc laisse le tag latest par défaut où il était, et seules les personnes qui demandent @rc obtiennent la candidate. Les images de conteneurs et les builds mobiles ont la même idée sous d’autres noms : un tag de pré-release, un déploiement progressif ou une piste de type TestFlight.

Comment rédiger les release notes d’une release candidate ?

Commencez les notes à la première RC et tenez-les à jour au fil des candidates. Les testeurs doivent savoir ce qui a changé, ce qu’il faut vérifier et ce qu’on sait cassé, et rédiger tôt fait remonter les entrées dont personne ne se souvient à la fin. Marquez la page ou la release GitHub comme pré-release pour que personne ne la prenne pour la version finale, et déplacez le texte terminé vers la release GA à sa sortie. La structure et le contenu sont dans les release notes logiciel, et le côté GitHub dans les release notes GitHub.

Les équipes SaaS ont-elles besoin de release candidates ?

Les équipes qui déploient en continu en ont rarement besoin, car le déploiement en production est le test et un feature flag contrôle qui voit un changement. Les release candidates trouvent leur place quand les utilisateurs installent eux-mêmes le logiciel et qu’on ne peut pas faire marche arrière par un déploiement : bibliothèques, applications de bureau et mobiles, produits auto-hébergés et API avec des clients de longue durée. Pour un produit hébergé qui expose les changements progressivement, l’équivalent est un déploiement progressif, que l’article sur les release notes avec feature flags traite du côté de la communication.

FAQ

Que signifie RC en logiciel ? RC signifie release candidate. C’est un build que l’équipe compte livrer comme version finale sauf si les tests trouvent un bug bloquant. Il suit les étapes alpha et bêta et précède la disponibilité générale.

Une release candidate est-elle assez stable pour la production ? Généralement oui pour des tests en staging ou en production limitée, avec un risque que la release finale n’a pas, car les tests peuvent ne pas être terminés. Considérez-la comme du code de qualité production encore à l’essai.

Combien de release candidates faut-il pour une release ? Autant qu’il en faut, et la plupart des releases en demandent une à trois. Une longue série de candidates signifie en général que le gel a été déclaré trop tôt ou que la couverture de tests attrape les problèmes trop tard.

Une release candidate peut-elle devenir la release finale sans changement ? Oui, et c’est le résultat visé. La release finale doit être le même build que la dernière candidate, simplement renommé ou ré-étiqueté en GA.

Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Documentation développeurs, Modèle de release notes