Nous commençons à rencontrer un problème au fur et à mesure que nous grossissons, où les fonctionnalités arrivent au test pour le test, mais au moment où tout est testé et les nouvelles fonctionnalités approuvées sont en cours de test pour le test.

Cela crée un environnement dans lequel nous ne pouvons presque jamais pousser vers la production car nous avons une combinaison de fonctionnalités testées et non testées. Je suis sûr que c'est un problème courant, mais je n'ai pas encore trouvé de bonnes ressources pour nous.

Quelques spécificités:

• GIT sur BitBucket
• Jenkins pour le déploiement par script sur Azure

Ce que j'espère, c'est un moyen d'isoler les fonctionnalités au fur et à mesure qu'elles se déplacent dans les environnements et ne poussent que ce qui est prêt à produire.

Il semble que vous ayez quelques problèmes ici:

1. Identification des fonctionnalités d'une version spécifique

Il s'agit d'un problème de gestion de projet et d'un problème de coordination. Est-ce que cette fonction soit libéré avant, en même temps que, ou après cette autre fonction? Si les versions veulent se produire une fonctionnalité à la fois, identifiez-le. Si les fonctionnalités vont être regroupées dans des versions, déterminez quels sont les regroupements et appliquez-les aux développeurs et aux décideurs. Utilisez votre système de suivi des problèmes ou de billetterie pour baliser les versions. Expliquez clairement que si une fonctionnalité d'une version spécifique est interdite, alors toutes le sont.

2. Stratégies de branchement

Git-flow est la réponse facile à de tels problèmes, et souvent les gens utilisent une variante de git-flow même s'ils ne savent pas ce que c'est. Je ne vais pas dire que c'est un fourre-tout pour tous les problèmes, mais cela aide beaucoup.

On dirait que vous rencontrez un problème avec les stratégies de publication non déterministes, où les fonctionnalités sont approuvées en scattershot et quelque chose qui a commencé le développement il y a longtemps pourrait être publié après quelque chose qui a commencé plus récemment - les fonctionnalités de saut de grenouille.

Les branches de fonctionnalités à longue durée de vie ou les branches de versions simultanées sont probablement la meilleure réponse à ce type de problèmes. Fusionnez (ou rebasez, si vous êtes à l'aise avec) la dernière version de master dans vos branches de longue date. Faites attention à ne fusionner que les fonctionnalités déjà en ligne, sinon vous rencontrerez les problèmes que vous rencontrez actuellement (trop de fonctionnalités mélangées sur une branche).

Les branches "Hotfix" ou "bugfix" sont une partie essentielle de ce processus; utilisez-les pour de petites corrections ponctuelles qui ont un cycle d'assurance qualité court.

D'après votre description, il pourrait même être préférable de ne pas maintenir une branche officielle de «développement». Plutôt, branchez toutes les fonctionnalités hors du maître et créez des branches de versions fusionnées une fois qu'une version est identifiée.

3. Environnements

Ne faites pas correspondre les branches git à vos environnements, sauf pour la production == master. La branche «développement» doit être supposée cassée. Les branches de publication sont poussées pour tester les environnements, qu'il s'agisse d'un environnement QA ou d'un environnement de transfert. Si vous en avez besoin, envoyez une branche de fonctionnalité spécifique à un environnement.

Si vous avez plusieurs branches de fonctionnalités qui doivent être publiées séparément mais sont testées en même temps ..... ¯ \ _ (ツ) _ / ¯ .... vous lancez un autre serveur? Peut-être les fusionner ensemble dans une branche jetable ... valider les correctifs / modifications dans les branches originales et re-fusionner dans la branche jetable; faire l'approbation finale et l'UAT sur les branches de publication individuelles.

4. Suppression de fonctionnalités non approuvées d'une succursale

C'est ce que les pensées ci-dessus tentent d'éviter, car c'est sans aucun doute la chose la plus douloureuse à essayer. Si vous êtes chanceux, les fonctionnalités ont été fusionnées dans vos branches de développement ou de test de manière atomique à l'aide des validations de fusion. Si vous n'avez pas de chance, les développeurs se sont directement engagés dans la branche développement / test.

De toute façon, si vous vous préparez pour une libération et avoir des changements non approuvés, vous aurez besoin d'utiliser Git pour reculer les commits non approuvés de la branche de sortie; la meilleure idée est de le faire avant de tester la version.

Bonne chance.

Voici une idée, arrêtez d'utiliser les branches de publication. Au lieu de cela, commencez à intégrer des bascules de fonctionnalités et à les gérer via la configuration. De cette façon, vous fusionnez toujours les branches de fonctionnalités dans master et vous ne devriez jamais vous demander quelle version est en test ou en prod. Si vous avez une question sur les fonctionnalités / implémentations actives dans un environnement, vérifiez simplement le fichier de configuration.

Cela devrait être une simple question de coordination entre le test et la production. Si vous utilisez des branches de fonctionnalités dans Git, arrêtez simplement de pousser les branches de fonctionnalités terminées vers Test pendant un cycle de test et reprenez lorsque le test est terminé.

Si vous avez besoin d'un meilleur contrôle, séparez Test en un serveur de développement et un serveur de test d'acceptation, et coordonnez les branches qui seront transmises au serveur de test d'acceptation avec l'équipe de test. Quelqu'un peut alors être responsable du lancement du déploiement final du test d'acceptation à la production.

Le travail s'accumule

C'est un problème universel dans mon expérience. Je l'aborde avec:

• Bonne gestion des versions des fonctionnalités par le propriétaire du produit
• Assurez-vous que les branches sont supprimées lors de leur fusion
• Limiter le travail en cours (avec des limites de colonne dans Jira)
• Revue trimestrielle des anciens tickets qui languissent, bugs et fonctionnalités
• Rétrospectives pour discuter des composants du problème
• Encouragement constant pour les révisions de code par tous
• Opportunités de jumelage pour résoudre les problèmes et les problèmes de longue date
• Réunions trimestrielles pour examiner et nettoyer les anciens billets
• Approche d'équipe pour que les développeurs, les produits et l'AQ / QE travaillent en étroite collaboration
• Bons rapports et outils pour rendre les nouvelles fonctionnalités du produit et l'arriéré évidents
• Revoir les sessions pour parcourir les anciennes branches et les supprimer

Branches

Vous avez besoin de quelques branches pour contrôler ce processus:

• caractéristique : ces branches sont nées du maître. Utilisez une application de gestion de projet pour identifier chaque branche de fonctionnalité avec une tâche. Par exemple, si vous utilisez TRAC, vous finirez si des branches comme: 1234-user-crud, 1235-bug-delete-catalog, etc. Identifiez vos commits avec le numéro de tâche aussi, cela vous aidera beaucoup quand vous avez des problèmes dans les fusions (vous).
• test : toutes les branches de fonctionnalités effectuées seront fusionnées dans la branche de test. Vous ne fusionnez jamais la branche de test dans une branche de fonctionnalité , car vous ne voulez pas de code provenant d'une autre fonctionnalité qui n'est pas dans la production (maître). Il en va de même pour la releasebranche.
• version : lorsque vous décidez quelles fonctionnalités testées peuvent être dans la production, vous fusionnez (encore ...) ces branches dans cette branche. Vous devez tester à nouveau toutes les fonctionnalités, car cette fusion peut entraîner de nouveaux problèmes. Lorsque la version est testée et terminée, vous fusionnez cette branche à master et créez une balise sur master pour la version.
• maître : contient uniquement le code de production.

Voir le git flow:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

Environnements

Très simple:

• test : cet environnement utilise la branche test.
• release : cet environnement utilise la branche de release réelle.

Les développeurs travaillent sur sa machine, chacun utilisant sa propre base de données. Si ce n'est pas possible chaque développeur a une base de données individuelle (à cause des licences, de la taille de la base de données, etc.), vous aurez beaucoup de problèmes à partager une base de données entre les développeurs: quand quelqu'un supprime une colonne ou une table dans sa branche, les autres branches compte toujours avec cette colonne / table dans la base de données.

Problèmes

Le plus gros problème de ce processus est la fusion.

Vous devez refaire les mêmes fusions dans testet release. Cela sera pénible si un bon refactorisateur est créé dans le code, comme supprimer une classe, déplacer / renommer des méthodes, etc. Comme vous ne pouvez pas obtenir le code de la branche test(ou release) dans la branche de fonctionnalité, les validations de fusion ne peuvent être résolues que dans le test(ou release). Donc, vous finissez par résoudre les mêmes conflits dans deux branches différentes, produisant probablement du code différent dans chaque fusion et, à l'avenir, vous découvrirez que l'équipe de test devra tester les fonctionnalités deux fois: dans les branches testet release, car chaque fusion peut entraîner différents bugs.

Un autre problème est la testbranche. Vous devrez "recycler" cette branche (supprimer et créer une nouvelle à partir de master) de temps en temps, car certaines anciennes branches (ou anciennes fusions, branches fusionnées qui ont été supprimées) peuvent entraîner de nombreux problèmes pour le nouveau code, divergeant beaucoup de ce qui est dedans master. En ce moment, vous avez besoin du contrôle des branches que vous souhaitez fusionner à nouveau dans letest .

La meilleure solution est que l'équipe commerciale sait ce qui doit être fourni dans la prochaine version et tout le monde travaille dans une branche unique (branche de développement). C'est bien pour eux la possibilité de choisir la fonctionnalité "terminée" qu'ils aimeraient être dans la prochaine version à tout moment (je pense que c'est votre scénario), mais c'est un cauchemar pour les développeurs et (je crois) pour le équipe de test.

On dirait que vous fusionnez changements de votre branche d'intégration dans votre branche de production, ce qui à mon humble avis n'est pas une bonne pratique, exactement pour les raisons que vous mentionnez. Dès qu'une branche de production pour une certaine version est retirée de la branche d'intégration principale, la branche d'intégration peut, à tout moment, diverger (après tout, elle est supposée évoluer vers la prochaine version). La fusion de la branche d'intégration dans la branche de version actuelle peut entraîner des modifications incompatibles avec cette version.

À mon humble avis, un processus approprié serait:

• retirer une branche de production de la branche d'intégration uniquement lorsqu'elle est jugée suffisamment proche du niveau de qualité souhaité, de sorte que seule une poignée de modifications devraient permettre de terminer la version. En d'autres termes, l'achèvement des fonctionnalités doit être évalué (en continu) sur la branche d'intégration, avant de tirer la branche de production.
• une fois la branche de production retirée, seules les modifications choisies sont apportées, traitées comme des modifications autonomes / corrigées - c'est-à-dire vérifiées qu'elles fonctionnent réellement comme prévu (ce n'est pas parce qu'une modification fonctionne dans une branche qu'elle fonctionne également dans une autre branche).

Personnellement, cela semble être plus un problème de processus qu'un problème d'outillage. Quelques choses que je suggérerais ici:

• Je ne sais pas si vous avez des groupes de développement et d'assurance qualité distincts. Si vous le faites, assurez-vous que Dev et QA participent aux réunions de planification et d'estimation du sprint. Dans l'une de mes entreprises précédentes, nous nous sommes assurés que le nombre de points d'histoire que nous avons attribués à une histoire représentait à la fois des efforts de développement et de test. (Vous pouvez également théoriquement avoir deux estimations distinctes pour l'effort de développement et d'assurance qualité, mais dans les deux cas, vous avez besoin que votre estimation inclue les deux; le temps requis pour une histoire est le temps nécessaire pour la livrer réellement). Même si vous n'avez pas de groupe AQ ​​distinct, assurez-vous toujours d'inclure l'effort de test dans vos estimations.
• Dans la même veine que ci-dessus, convenez à l'avance du nombre d'histoires que vous allez inclure dans un sprint particulier. Le nombre de points d'histoire que vous acceptez est basé sur le montant que vos développeurs peuvent terminer dans leur sprint et le nombre d'éléments que QA peut tester dans leur sprint. (Je suppose, bien sûr, que les sprints QA sont derrière les sprints Dev, mais vous pouvez l'adapter à votre processus). Si vos développeurs peuvent terminer 200 points d'histoire mais que votre AQ ne peut en terminer que 150, vous ne pouvez évidemment faire que 150 points d'histoire avant que le travail ne commence à "s'accumuler" et vous vous retrouvez avec un cas comme celui que vous décrivez. (Dans un cas comme celui-ci, vous voudrez peut-être enquêter sur la cause du barrage routier pour tenter de l'atténuer).
• Personne ne pousse quoi que ce soit vers le contrôle qualité jusqu'à ce que tout ce qui se trouve actuellement dans le contrôle qualité soit testé et livré .
• Une fonctionnalité complète est celle qui a été testée et livrée. S'il n'est pas livré, ce n'est pas fait.
• De toute évidence, vous voulez essayer de le faire sur une sorte d'horaire fixe. L'une des idées derrière l'intégration continue et l'agilité est l'itération. Par définition, l'itération implique une livraison fréquente. Des intégrations et des livraisons fréquentes minimisent le risque de chacune.

Honnêtement, je pense que le plus important sera la discipline concernant le moment où vous livrez et le nombre de tâches que vous pouvez réellement terminer complètement dans un délai donné.

Pour résumer: ne livrez à QA que lorsque vous avez terminé de tester et de livrer les anciennes fonctionnalités.

Lorsque "tout est testé et approuvé", déployez ce qui a été testé et approuvé en production. Cela pourrait être un commit particulier, ou ce pourrait être un artefact de build particulier généré par Jenkins.

Peu importe que les validations ultérieures sur la même branche ne soient pas encore testées.