Quand est-il approprié de commencer à utiliser la prochaine révision d'un outil lors de la pâtisserie?

Plus précisément, je travaille sur un outil qui intègre un DVCS et un système de build, mais j'imagine que le défi auquel je suis confronté se poserait à toute personne développant un outil "meta" (compilateur, VCS, système de build, testeur, etc.) qu'ils souhaitent se développer à travers le "dogfooding" .

Ma question est: dans un processus de version de style Scrum utilisant le flux de travail de branchement , à quel moment dois-je commencer à utiliser une version plus récente de l'outil dans le cycle de développement de l'outil?

Je recherche un processus pour créer un équilibre entre:

• utiliser constamment la developversion de l'outil: je constate que je romps mon propre développement à mesure que les changements sont incorporés.

• utiliser en permanence la masterversion de l'outil: tous les problèmes que je découvre via dogfooding sont des problèmes qui ont déjà été publiés.

La première chose à faire est de disposer de tests de régression hors ligne automatisés très approfondis. Faire passer ces tests une exigence minimale pour ce que vous utilisez officiellement.

Deuxièmement, vous avez besoin d'un moyen simple de revenir à la version de travail précédente, pour les problèmes que vos tests automatisés ne détectent pas.

Par exemple, mon noyau Linux a été patché personnalisé pendant un certain temps. Je patcherais et compilerais mon noyau sur le même ordinateur sur lequel je comptais l'utiliser, ce qui signifiait que je pourrais perdre mon environnement de développement si je créais un noyau défectueux. J'ai donc veillé à toujours garder un bon noyau connu dans mon menu GRUB, donc si je faisais une erreur, j'étais de retour à un bon environnement de développement avec un simple redémarrage.

Il est difficile de coordonner cela avec une équipe, mais je suppose qu'il s'agit principalement de permettre à quiconque de lancer une solution de repli et de communiquer les raisons. Dans le contrôle de version, une façon de désigner ce serait avec quelque chose comme une last_known_goodbranche, quelque part entre developet masterdans votre flux de travail. Rien n'y est poussé jusqu'à ce que vous ayez réussi à éduquer une construction.

Si cet outil est utilisé pour produire un logiciel de qualité de production (surtout s'il est utilisé de manière récursive, c'est-à-dire pour se développer), j'augmenterais vos efforts de test à l'avance, et j'attendrais la pâtisserie jusqu'à ce que la version soit suffisamment stable pour que vous soyez assez confiant que vous ne casserez pas le code de production en l'utilisant.

Si vous devez attendre que la version principale ait ce niveau de confiance, tant pis.

Git est également un tel outil et, évidemment, fait aussi de la pâtisserie. Mais il le fait à différents degrés dans différents environnements. Les serveurs publics exécutent uniquement la version alors que les développeurs travaillent généralement avec next(c'est le nom du projet git pour "développer") ou pu(encore plus développer que développer). Tout développeur bloqué par un problème peut revenir à nextou à la masterdernière version chaque fois qu'il est bloqué par quelque chose et que le référentiel principal n'est pas affecté, donc les problèmes peuvent être nettoyés en s'y référant.

Le modèle de branchement est similaire au précédent avec des noms légèrement différents. masterest à partir de ce que les grandes versions sont faites, maintest la branche de publication pour la prochaine version, nextest similaire à développer avec une légère différence que les fonctionnalités peuvent être fusionnées pour être maîtrisées séparément après avoir déjà été dans la prochaine au lieu d'être fusionnées dans leur intégralité.

Il y a une branche supplémentaire, pu. Ceci est créé en fusionnant toutes les branches d'entités dont l'intégration est envisagée next(la branche est supprimée et recréée à chaque fois). IIRC il n'est publié que s'il passe la suite de tests. La dernière fois, j'ai regardé Junio, le responsable, exécutait les scripts pour le construire régulièrement à la main, mais ces scripts pouvaient être exécutés par intégration continue tous les soirs et je crois que Gerrit le crée même automatiquement.

C'est donc ce genre de réponse. Vous dogfood la version la plus de développement que vous avez dans les environnements de développement, mais utilisez la version précédente pour les versions de construction.

Sur la base de la réponse acceptée , je vais développer le flux de travail de branchement pour maintenir des branches similaires à ce qui suit:

• master: fusionne avec release-*à la fermeture
• dogfood: branches de master; inclut des correctifs identifiés lors de la dogfooding; fusionne à partir du developmoment où le logiciel est jugé "stable" pour un usage interne; le chef de cette branche peut être reculé dans le temps si nécessaire
• develop: branches de master; inclut les modifications en cours, les corrections de bogues et les fusions dogfoodet feature-*branches
• feature-*: branches de develop; inclut des modifications pour une nouvelle fonctionnalité particulière
• release-*: branches à partir du dogfoodmoment où le logiciel est considéré comme "stable" pour un usage externe; inclut des mises à jour de la documentation et des corrections de bugs mineurs avant la fusion avecmaster