Comment pouvons-nous inclure uniquement des fonctionnalités prêtes à être lancées dans nos versions de production toutes les deux semaines?

Je suis développeur de logiciels dans une équipe agile assez importante (nous avons huit développeurs apportant activement des modifications à un référentiel de code unique). Toutes les deux semaines, nous mettons en production une nouvelle version de notre logiciel. Voici notre flux de travail actuel:

• Lors du démarrage d'une nouvelle tâche, les développeurs créent une "branche de fonctionnalité" hors de la branche de développement principale (nous utilisons git ) et travaillent sur cette nouvelle branche
• Une fois qu'un développeur a fini de travailler sur sa tâche, il fusionne sa branche de fonctionnalités dans la branche de développement
• Le développeur fusionne la branche de développement dans la branche QA.
• Une génération est déclenchée à partir de la branche QA. La sortie de cette version est déployée dans notre environnement QA pour permettre aux testeurs de commencer leurs tests.

Il est assez courant pour nos testeurs de trouver des problèmes avec ces nouvelles fonctionnalités qui ont été fusionnées dans la branche QA. Cela signifie qu'à tout moment, l'environnement QA contient probablement plusieurs nouvelles fonctionnalités - certaines testées et sans bogues, et certaines cassées. Cela rend la publication difficile car il est rare que la version QA soit prête à la production.

Pour atténuer ce problème, nous avons essayé d'initier un "gel QA", ce qui signifie que les développeurs ne fusionnent pas notre branche de développement dans la branche QA quelques jours avant la sortie. Les corrections de bugs dans l'environnement QA sont effectuées directement sur la branche QA et fusionnées vers la branche développement. Théoriquement, cela empêche les nouvelles fonctionnalités cassées de l'AQ tout en nous permettant de résoudre les problèmes déjà dans l'AQ.

Bien que ce concept de «gel de l'AQ» ait partiellement réussi, il est difficile de le coordonner et les gens sont souvent confus quant à savoir s'ils sont autorisés à fusionner avec l'AQ. Il a également été difficile de fixer une date limite de "gel de l'assurance qualité" - tout le monde aime l'idée d'une certaine marge de manœuvre entre le gel et la sortie, mais en pratique, ils préfèrent avoir leur fonctionnalité dans la prochaine version plutôt que de respecter la date limite.

Existe-t-il un meilleur moyen de garantir que nous avons une version propre pour nos versions toutes les deux semaines?

Il y a quelques problèmes qui flottent dans ce qui causent des problèmes que vous rencontrez.

La première est la branche d'assurance qualité de longue date. Avoir une branche de longue durée parallèle à la ligne principale de développement peut être une source de confusion car il existe différents efforts qui doivent être répliqués à la fois dans la branche QA et dans la ligne principale. Cela signifie soit que vous archivez des correctifs sur la branche QA qui doivent être fusionnés avec la ligne principale (ce n'est pas une mauvaise chose), soit que vous vous connectez à la ligne principale qui est fusionnée dans la branche QA (une source de bogues possibles) .

L'autre problème avec la branche parallèle de longue durée est qu'il est possible que les fichiers soient perpétuellement désynchronisés. Un correctif de code qui n'est jamais fusionné ou une configuration nécessaire pour les builds de production qui n'est jamais testée et qui fait partie de la ligne principale de développement.

Ensuite, vous avez des rôles qui se gênent. Cela signifie que le rôle de conditionnement (plus à ce sujet plus tard) n'est pas suffisamment isolé.

Dans le modèle git-flow , la branche de publication est dérivée du développement ( pas le développement fusionné avec QA) et tous les correctifs sont archivés dans la branche de publication puis fusionnés de nouveau à la branche de développement.

Une partie de la philosophie du branchement peut être trouvée dans Advanced SCM Branching Strategies (je considère que c'est une excellente lecture). Cela se concentre sur les rôles que chaque branche peut jouer. La branche de publication assume le rôle d'emballage.

Le rôle de packaging est souvent confondu avec les rôles d'accumulation ou, plus communément, de ligne principale. Une fois que le développement et la maintenance prévus ont été effectués et que toute accumulation a été effectuée, il est temps de préparer le code pour la publication. Un tel effort peut ne pas être trivial, nécessitant une équipe d'ingénieurs de publication et des correctifs supplémentaires au-delà de ceux déjà effectués. La politique d'une branche emballage est très différente de celle d'une branche maintenance, comme le suggère le rôle de l'emballage, seuls les changements nécessaires pour rendre le produit libérable doivent être traités.

• Branche du point de développement à la branche de publication. La branche de publication à partir de laquelle QA construit obtient une branche et aucune fusion du développement.
  • Si vous souhaitez suivre cette voie, avec des noms et des hooks cohérents, il est possible d'empêcher une fusion dans une branche de publication.
• Corrigez tout ce qui doit être corrigé dans la branche de publication et fusionnez ces modifications dans la ligne principale.
• À la fin de l'effort de publication, fusionnez la branche de publication dans la branche "releases go here" et marquez-la comme telle.
  • Certains sites n'ont pas de branche "Les versions vont ici" et laissent simplement la fin de la branche des versions suspendue avec une balise.

Il faut sérieusement envisager d'appliquer l'intégralité de git-flow en place. Ce n'est pas trop loin de ce qui se fait actuellement et met un peu de discipline et de cohérence dans ce que signifie chaque branche et comment chaque branche interagit avec les autres.

Le problème me semble être que vous avez une seule branche QA.

Pour chaque version, créez une branche QA distincte du tronc / maître de développement principal. Fusionnez ensuite uniquement les correctifs de bogues pour les fonctionnalités de cette branche - jamais de nouvelles fonctionnalités. Demandez à QA de tester cette branche.

De cette façon, le "gel" est assez évident - c'est dans le nom de la branche. Vous pouvez utiliser quelque chose comme, je ne sais pas, release/26/10/2015. Ensuite, il est évident que personne ne devrait fusionner de nouvelles fonctionnalités après cela.

C'est particulièrement utile si vous ne bifurquez même pas la branche jusqu'au gel. Les gens peuvent fusionner pour maîtriser à tout moment, cela ne fera tout simplement pas partie de cette version s'il n'est pas fait à temps pour qu'il soit testé.

N'ayez pas une seule branche d'assurance qualité longue durée, ce n'est que des problèmes. Fork de la branche principale de développement pour chaque version et QA de cette branche.

Vous êtes en quelque sorte associé au modèle de branchement Développement-MAIN-Production présenté ci-dessous. La zone située au-dessus de MAIN serait la zone de développement. La zone en dessous de MAIN est la zone de production.

Points forts de ce modèle que je considère comme pertinent pour vous:

• Vos développeurs ont besoin de Transférer l'intégration (FI) (FI = fusionner loin de MAIN) fréquemment (2-3 fois par semaine) dans leurs branches DEV pour s'assurer que leurs derniers changements tiennent toujours compte des derniers développements globaux.
• Vos développeurs doivent inverser l'intégration (RI) (RI = fusionner vers MAIN) dans la branche TEST uniquement lorsqu'ils ont atteint un jalon d'achèvement de fonctionnalité qu'ils souhaitent exposer à QA et pour lequel ils sont prêts à fournir des correctifs rapides dans réponse aux commentaires de l'AQ. Les correctifs seront effectués sur la branche TEST et immédiatement FI dans leur branche DEV.
• Ne jamais RI d'une branche DEV dans MAIN
• Toujours RI de la branche TEST vers MAIN, exclusivement lorsque votre QA considère que la qualité du TEST est OK. Gardez un seuil de haute qualité pour la fusion dans MAIN. À tout le moins, votre chef de produit doit pouvoir toujours faire la démonstration d'une version de travail de votre produit à partir de la dernière validation dans MAIN.
• Créez des succursales dans la zone de production uniquement si nécessaire. Votre serveur de build doit toujours baliser toutes les branches, y compris celles de la zone de développement, et la source de toute build / version doit être identifiable à tout moment quelle que soit la branche dont elle provient.
• Prenez les versions de production uniquement à partir de MAIN ou de la zone de production. Si plus tard, vous devez fournir un correctif pour une version publiée exacte (c'est-à-dire que vous ne pouvez pas simplement fournir la dernière version de MAIN), créez une branche dans la zone de production à partir de la balise MAIN de la version défectueuse, lorsque le correctif est nécessaire. Corrigez toujours le problème sur la branche HotFix, puis immédiatement RI dans MAIN et FI dans TEST.

Je soupçonne que vous avez des problèmes parce que:

• Votre devs RI en code TEST qui n'est pas complet
• Vos développeurs RI dans TEST sans obtenir le feu vert de QA (c'est-à-dire que QA ne contrôle pas ce qui est injecté dans TEST)
• Lorsque QA signale un bogue sur TEST, vos développeurs le corrigent sur leur branche DEV puis RI dans TEST. C'est une mauvaise pratique majeure car la fusion apportera toujours d'autres conneries de développement incomplètes. Ils doivent toujours le corriger sur TEST puis sur FI dans leur branche DEV. Si ce n'est pas réparable sur TEST, ils ont livré la merde totale en premier lieu et vous avez de plus gros problèmes.
• Vos développeurs ne font pas assez souvent fi de TEST et donc ils déstabilisent TEST chaque fois qu'ils y livrent. C'est un art qui équilibre la fréquence à laquelle FI dans DEV. Reportez-le trop et ce sera extrêmement coûteux et risqué juste avant la livraison, ce que vous ne voulez jamais. Faites-le trop souvent et vous n'obtiendrez aucun travail de développement réel si vous chevauchez trop avec le travail fourni par d'autres personnes dans TEST dans l'intervalle.

Si je comprends bien la question, vous avez deux problèmes. (a) les fonctionnalités cassées sont fusionnées avec les bonnes fonctionnalités que vous souhaitez publier; (b) vous voulez pouvoir libérer les bonnes fonctionnalités tout en retenant celles cassées. En tant que contrainte sur les solutions possibles, je suppose que vous souhaitez que vos tests d'AQ final / officiel se déroulent sur une branche intégrée qui contient toutes les fonctionnalités prévues pour la prochaine version.

Quel que soit votre modèle de branchement SCM, je vous suggère d'essayer l'une des options suivantes ou les deux:

1. Attribuez une ressource QA à chaque équipe technique. Demandez-leur de faire des tests de fonctionnalités sur les versions de la branche de fonctionnalité, et donnez-leur le pouvoir de décider quand une fonctionnalité est suffisamment bonne pour fusionner. Idéalement, demandez-leur de travailler en collaboration avec (le reste de) l'équipe de fonctionnalités, afin que les éléments soient testés peu de temps après leur écriture. (Notez que cela ne signifie pas qu'ils doivent effectuer tous les tests eux-mêmes.)
2. Utilisez des bascules de fonction, à la place des branches de fonction ou en plus. Fait à droite, les bascules de fonctionnalité vous permettent de désactiver une fonctionnalité cassée sans essayer de la dissocier du code, afin que vous puissiez tester et libérer les autres fonctionnalités. Le type de bascule dont je parle n'est pas accessible aux clients; vous ne voulez pas qu'un nombre croissant de combinaisons exponentielles soit testé. Vous définissez les bascules sur la branche QA pour qu'elles correspondent aux fonctionnalités que vous prévoyez de publier, et si le plan change parce qu'une fonctionnalité n'est pas prête, vous changez cette bascule.

Une solution très simple que j'ai vue travailler dans une équipe un peu plus grande que la vôtre est de faire travailler et déployer tout le monde à partir d'une seule branche.

Vous dites que l'équipe est agile mais il n'est pas clair si vous travaillez dans des sprints (ie Scrum) ou une approche plus continue (ie Kanban). En supposant que vous faites des sprints, le but de l'équipe est d'avoir le code libérable à la fin de chaque sprint, pour votre sortie bimensuelle. Il n'y a aucune confusion quant à savoir si une fonctionnalité en cassera une autre car elles ont toutes été développées ensemble. Les testeurs peuvent être en mesure d'accéder à des fonctionnalités en plus petits morceaux car les frais généraux des développeurs pour leur fournir sont plus faibles. Et vous n'avez pas vraiment besoin d'un QA-Freeze, à la place, tout le monde sait quand la fin du sprint est et ne devrait pas prendre le travail qu'il ne peut pas terminer, ou laisser dans un état déployable (c'est-à-dire désactivé).

De toute évidence, il y a des avantages et des inconvénients à toute approche, je présente cela comme une option pas nécessairement la «meilleure façon».

La raison pour laquelle vous rencontrez ces problèmes est que votre code publié sur QA n'est pas de bonne qualité (et est-ce quiconque?!), Vous devez donc commencer à obtenir une meilleure version sur QA afin qu'ils n'aient pas besoin de recevoir des bigfix si souvent. la façon la plus simple de le faire est d'introduire une branche intermédiaire vers laquelle vous relâchez (appelons-la test). C'est toujours dans le cadre du développement, mais cela permet aux développeurs de continuer à travailler, tout en ayant une branche intégrée qui devrait être de bonne qualité pour être envoyée à QA.

Des tests d'intégration peuvent avoir lieu sur cette branche afin de trouver les bogues que QA trouve actuellement, les bogues peuvent être corrigés sur la branche d'origine, puis fusionnés à nouveau, et encore jusqu'à ce que ce soit à droite ou que des bogues puissent être corrigés directement sur cette branche (je recommande le ancien). Une fois qu'il a passé une charge de tests de base, il peut ensuite être envoyé à QA pour les `` doigts collants de l'utilisateur et ce qu'ils ont fait? '' essai.

Cette approche est donc conçue pour protéger la branche QA des fonctionnalités de développement défectueuses - que ce soit parce que la fonctionnalité n'a pas été suffisamment bien codée ou s'il y a eu des problèmes d'intégration inattendus n'a pas d'importance. Seules les branches de développement qui réussissent les tests d'intégration sont promues au QA.