Ali Spivak, Dave Camp et Sylvestre Ledru de Mozilla ont publié un billet dans le blog des développeurs Mozilla Hacks pour expliquer la simplification des canaux de distribution de Firefox et l’amélioration de la stabilité de l’édition pour développeur. Une FAQ sur le blog Mozilla Releases est aussi disponible.
Rationaliser notre processus de sorties de versions et amener de nouvelles fonctionnalités stables aux utilisateurs et aux développeurs est une priorité pour Firefox. En examinant très attentivement nos canaux de distribution, il est devenu clair qu’Aurora n’était pas à la hauteur de nos attentes comme premier canal de stabilisation.
À compter du 18 avril, le canal Aurora de Firefox arrêtera de se mettre à jour et au cours des prochaines semaines, la version Aurora sera supprimée du cycle des trains de sorties. La Developer Edition sera basée sur la version bêta. Les utilisateurs de la Developer Edition conserveront leurs thème, outils et préférences depuis l’édition pour développeur, garderont leur profil actuel et ne devraient endurer aucune perturbation.
Ce changement bénéficie aux développeurs de plusieurs façons :
- des choix plus clairs dans les canaux de préversions – Nightly pour les fonctionnalités expérimentales et Developer Edition/bêta pour la stabilité.
- une plus grande qualité et un environnement plus stable pour les utilisateurs de la Developer Edition.
- des cycles de versions plus rapides pour les fonctionnalités de la plateforme (ce qui profitera à tout le monde !).
Voici le calendrier : le 18 avril, le code de Firefox 54 passera d’Aurora à bêta comme d’habitude, tandis que Firefox 55 restera en Nightly pour un second cycle d’affilée (soit 14 semaines). Le prochain jour de fusion, le 12 juin, Firefox Aurora sur ordinateur – desktop – (54) continuera à recevoir des mises à jour pour des problèmes de sécurité critiques et les personnes sous Aurora et Developer Edition seront migrées vers le canal de mis à jour bêta. Sur Android, les utilisateurs d’Aurora seront migrés vers Nightly.
Aurora a en premier lieu été créé en 2011 pour fournir davantage de retours des utilisateurs après que Firefox est passé de la version 5 au cycle de sorties à grande vitesse. Aujourd’hui, en 2017, nous avons des processus plus modernes sous-jacents à notre modèle de train et estimons que nous pouvons livrer des produits stables et riches en fonctionnalités sans la phase supplémentaire Aurora de 6 à 8 semaines.
Un mécanisme de déploiement progressif similaire à ce que nous faisons aujourd’hui avec le canal Release sera utilisé pour les premières semaines du canal bêta. Notre processus de travail pour l’ingénierie et la gestion des versions continuera à déployer des contrôles et contre-contrôles pour nous assurer de livrer une version de grande qualité. Une nouvelle fonctionnalité se fondera de Nightly en bêta seulement quand nous l’estimerons prête, en fonction sur des critères préétablis définis par nos équipes d’ingénierie, produit et intégrité des produits. Si les fonctionnalités ne sont pas prêtes, elles ne passeront pas de Nightly en bêta.
Le billet de MozHacks se termine par la liste des nouveaux outils et processus de contrôle. La FAQ vous apportera des précisions sur ce projet.
Nous nous concentrerons sur la découverte et la correction des régressions au cours du cycle Nightly et soulagerons le stress provoqué par la date butoir pour livrer la version afin de réduire le nombre de correctifs habituellement déployés sur Aurora (400 à 600 ces temps-ci).
Calendrier de la transition
FAQ
Que va-t-il advenir de la population Aurora sur desktop ?
Les personnes en Aurora seront migrées vers le canal de mise à jour bêta le 17 avril. Nous prévoyons de les maintenir dans un canal de mise à jour « pré-bêta » séparé du reste de la population bêta. Nous nous servirons de cette audience pré-bêta pour tester et améliorer la stabilité et la qualité des versions bêta initiales jusqu’à ce que nous soyons prêts verser 100 % de la population en bêta. Parce que nous avons présenté Aurora comme un produit stable dans le passé, le canal bêta est le plus proche en termes de stabilité et de qualité.
À compter de la prochaine fusion (le 18 avril 2017), les utilisateurs en Aurora 54 resteront dans le canal Aurora, mais les mises à jour seront désactivées. En cas de problème de sécurité critique, nous pourrons pousser de nouvelles mises à jour vers ces utilisateurs du canal Aurora. Les utilisateurs du canal Aurora seront migrés vers le canal bêta en avril 2017. Pour que cela se produise, nous devons nous assurer que les fonctionnalités de la Developer Edition fonctionnent de la même façon dans le canal de mise à jour bêta (thème, profil, etc.).
Que va-t-il arriver à la population sous Android ?
Parce que le Google Play n’autorise pas la migration de la population d’une application à une autre, la population dans Fennec nom de code de Firefox pour Android Aurora sera migré vers l’application Nightly. Pour l’instant, nous prévoyons de réutiliser l’actuelle application Aurora du Google Play et la remplacer par Nightly pour conserver l’actuelle population.
Pourquoi adopter des approches différentes pour les populations sur ordinateur (desktop) et sur Android ?
Le canal Aurora sur desktop existe depuis longtemps et a une base d’utilisateurs finaux substantielle qui bénéficiera au canal bêta.
Fennec Aurora sur le Google Play est un ajout récent et nous estimons que fusionner cette audience avec Nightly a plus de sens. Cela simplifie aussi la mise en œuvre.
J’utilise une Developer Edition. Que va-t-il m’arriver ?
L’édition pour développeur, actuellement basée sur Aurora, sera mise à jour pour pouvoir recevoir des versions de la branche bêta. Il n’y a rien que les utilisateurs de la Developer Edition ont à faire. Ils seront automatiquement mis à jour vers la version bêta en conservant les thèmes, outils et préférences de la Developer Edition, ainsi que le profil actuel.
Pourrais-je encore tester les extensions avec Developer Edition ?
Vous pouvez continuer à tester les extensions non signées sur les versions Nightly ou installer temporairement des WebExtensions dans les versions bêta et Release.
Nous continuons à fournir des versions sans marque des branches bêta et Release qui sont en capacité d’exécuter des extensions non signées – dont des bootstrapped – pour le développement et l’expérimentation. Ces versions ne seront pas vérifiées par la QE|Quality Engineering, mais recevront des mises à jour, ce qui est une amélioration aux versions sans marque que nous fournissons actuellement pour le développement des extensions.
Comment allez-vous atténuer le risque en matière de qualité représenté par le retranchement de 6 à 8 semaines de stabilisation dans le cycle ?
Au lieu de déployer les mises à jour en une fois auprès de 100 % de la population bêta, nous allons utiliser un mécanisme de déploiement progressif pour les proposer à un sous-ensemble de la population bêta. Pour la première phase, nous viserons l’ancienne population Aurora. Dans une seconde phase, nous ciblerons des populations spécifiques (système d’exploitation, carte graphique, etc.).
En parallèle, la QE fera aussi des approbations préliminaires en Nightly pour détecter de potentiels problèmes de bonne heure. La gestion des mises en production sera plus agressive en termes de désactivation des fonctionnalités.
Enfin et surtout, le cycle Aurora était utilisé pour finaliser certaines fonctionnalités. Au lieu de cela, la stabilisation de fonctionnalités sera réalisée au cours du cycle Nightly.
Que faisons-nous pour améliorer la qualité de Nightly ?
Pour améliorer la qualité globale de Nightly, quelques initiatives vont aider.
Les critères de fusion de Nightly
Les nouvelles fonctionnalités orientées vers l’utilisateur final embarquant dans les versions Nightly devraient répondre aux critères pour être prêts pour bêta avant qu’elles puissent être poussées dans le canal bêta.
Analyseurs statiques
Afin de détecter les problèmes dans la face d’examen, des analyseurs statiques seront intégrés dans le cadre du flux de travail. Ils seront capables d’identifier les défauts potentiels mais aussi limiter la dette technologique.
La couverture de code
Les résultats de la couverture de code vont être utilisés pour analyser la qualité de la suite de tests et du risque introduit par le changement.
Évaluation des risques
En corrélant diverses sources de données (VCS, Bugzilla, etc.), nous estimons que nous pouvons identifier les risques qu’impliquent les changements avant même qu’ils embarquent. L’idée est d’identifier les fonctions dans lesquelles une modification a plus de chance d’introduire une régression.
À quel rythme les versions bêta seront-elles mises à jour ?
Nous continuerons à pousser deux versions bêta pour desktop et une pour la version Fennec pour Android chaque semaine du cycle bêta.
L’édition pour développeur continuera-t-elle à disposer d’un profil distinct ?
Oui. Le profil séparé de la Developer Edition est une obligation de la transition. Si pour une raison quelconque cette fonctionnalité ne pouvait pas être terminée d’ici la fin de l’année, nous devrons revenir à créer des reconstructions de la Developer Edition comme fait précédemment pour nous assurer que ces utilisateurs ne soient pas laissés de côté.
Que va-t-il arriver à la branche Aurora après que Firefox 54 sera passé en bêta ?
Les mises à jour sur la chaîne Aurora seront désactivées le 18 avril. Les populations desktop et Android Aurora seront migrées comme décrit ci-dessus.
Quels critères vont-ils être utilisés pour évaluer le degré de préparation pour passer en bêta ?
Nous allons surveiller les taux de plantage, les approbations de la QE, les données de télémétrie et les nouvelles régressions pour déterminer la qualité globale de Nightly et le degré de préparation des fonctionnalités pour fusionner en bêta.
Comment et qui va décider si une fonctionnalité est prête pour passer en bêta ?
Les fonctionnalités exposées à l’utilisateur final seront examinées pour leur préparation pour la bêta avant qu’elles soient poussées dans le canal bêta. Ci-dessous figure une liste de critères qui seront utilisés pour évaluer le degré de préparation pour fusionner en bêta :
- pas de problèmes de stabilité significatifs
- des plans de tests manquants
- des tests insuffisants
- une fonctionnalité que ne serait pas Code Complete
- trop de bogues ouverts
Des critères plus détaillés sont définis dans ce document.
Y a-t-il des changements aux canaux Release ou ESR ?
Aucun changement n’est prévu pour les utilisateurs des canaux Release ou ESR.
Ceci changera-t-il la fréquence avec laquelle nous poussons les versions de la voie principale vers le canal Release ?
Non, mais les changements ajoutés en Nightly pourront arriver en version Release environ 6 à 8 semaines plus tôt qu’ils ne le font maintenant.
Que va-t-il arriver au processus l10n quand nous supprimerons Aurora ?
La concentration des efforts de localisation va passer de mozilla-aurora à mozilla-central. Les outils de localisation (Pootle et Pontoon) liront les chaînes en-US dans un clone de mozilla-central spécial : les l10n-drivers passeront en revue les patchs ajoutant des chaînes dans le dépôt officiel mozilla-central, fourniront des retours aux développeurs si nécessaire et mettront ce dépôt spécial à jour tous les 2-3 jours. Les contenus localisés seront poussés dans les dépôts l10n-central.
Il n’y a pas de changement pour les développeurs travaillant sur Firefox : Nightly et mozilla-central restent ouverts aux changements de chaînes, y compris pour les six semaines supplémentaires que Firefox 55 passera en Nightly, alors que le canal bêta est toujours considéré comme ayant les chaînes gelées et les requêtes pour promouvoir des changements touchant les chaînes sont évaluées au cas par cas.
Les utilisateurs qui souhaitent participer à la localisation sont encouragés à télécharger Nightly dans leur langue.
Que va-t-il arriver au processus l10n à la fin de l’année ?
Pour Firefox et Firefox pour Android nous allons passer à un modèle avec un seul dépôt pour tous les canaux pour chaque langue. Ce changement se reflétera dans les outils de localisation, permettant aux localisateurs de faire une modification d’une chaîne et voir la mise à jour appliquée dans tous les canaux à la fois.
Quel impact aura Dawn sur le planning de l’ingénierie pour l’embarquement des fonctionnalités ?
La plus grande transformation est que les fonctionnalités devront être terminées avant le jour de la fusion. Les développeurs ne pourront pas finaliser le développement de la fonctionnalité au cours du prochain cycle de la branche (de la façon dont Aurora est utilisé actuellement). Voir aussi la question « Comment et qui va décider si une fonctionnalité est prête pour passer en bêta ? »
Quel impact aura Dawn sur les correctifs de bogues et les fonctionnalités non suivis par la direction du projet ?
L’embarquement des correctifs de bogues dans le dépôt Nightly continue comme avant. Le développement des fonctionnalités, qui ne sont pas directement visibles par l’utilisateur final et non suivis par les EPM (chefs de projet technique) et la gestion de la mise en production continuent comme avant.
Si la qualité et la stabilité de Nightly est affectée par ces fonctionnalités ou correctifs de bogue non suivis, nous discuterons d’options d’atténuation potentielle telles que : des retraits, stabiliser les problèmes de qualité avant de continuer de travail de développement de la fonctionnalité, retarder la date de fusion, imposer un gel du code dans Nightly jusqu’à ce que les problèmes bloquants soient résolus, etc.
Voilà, vous devez tout savoir sur la fin du canal Aurora et le projet Dawn. S’il vous reste des questions vous pouvez les poser en commentaire, sur Twitter, sur Facebook et pourquoi pas sur Mastodon.
@Mozinet, relu par la communauté dont Sylvestre, Théo et Hellosct1