Stratégie de branchement Git intégrée au processus de test/QA

Question

Notre équipe de développement a utilisé le GitFlow stratégie de branchement et c'est génial !

Récemment, nous avons recruté un couple de testeurs pour améliorer la qualité de nos logiciels. L'idée est que chaque fonctionnalité devrait être testée/QA par un testeur.

Dans le passé, les développeurs travaillaient sur des fonctionnalités sur des branches de fonctionnalités séparées et les fusionnaient à nouveau dans la branche de la develop branche quand c'est fait. Le développeur testera lui-même son travail sur cette feature branche. Maintenant, avec les testeurs, nous commençons à poser cette question

Sur quelle branche le testeur doit-il tester les nouvelles fonctionnalités ?

Évidemment, il y a deux options :

• sur la branche des caractéristiques individuelles
• sur le develop branche

Test sur la branche de développement

Au départ, nous pensions que c'était la voie à suivre, car.. :

• La fonctionnalité est testée avec toutes les autres fonctionnalités fusionnées à la develop depuis le début de son développement.
• Tout conflit peut être détecté plus tôt que plus tard
• Cela facilite le travail du testeur, qui ne s'occupe que d'une seule branche ( develop ) à tout moment. Il n'a pas besoin de demander au développeur quelle branche correspond à quelle fonctionnalité (les branches de fonctionnalité sont des branches personnelles gérées exclusivement et librement par les développeurs concernés).

Les plus gros problèmes avec ça sont :

• El develop La branche est polluée par des bogues.

  Lorsque le testeur trouve des bogues ou des conflits, il les signale au développeur, qui corrige le problème sur la branche de développement (les branches de fonctionnalités sont abandonnées une fois fusionnées), et d'autres corrections peuvent être nécessaires par la suite. De multiples commits ou fusions subséquents (si une branche est recréée à partir de la branche de développement). develop pour corriger les bogues) permet d'annuler la fonctionnalité à partir de la branche de la develop branche très difficile si possible. Il y a de multiples fonctionnalités qui fusionnent et sont corrigées sur la branche develop à différents moments. Cela crée un gros problème lorsque nous voulons créer une version avec seulement certaines des fonctionnalités de la branche develop branche

Test sur la Feature Branch

Nous avons donc réfléchi à nouveau et décidé que nous devions tester les fonctionnalités sur les branches de fonctionnalités. Avant de tester, nous fusionnons les changements de la branche develop vers la branche des fonctionnalités (pour rattraper le retard de la develop branche ). C'est une bonne chose :

• Vous testez toujours la fonctionnalité avec d'autres fonctionnalités dans le courant dominant.
• Un développement ultérieur (par exemple, la correction d'un bogue, la résolution d'un conflit) ne polluera pas le site Web de l'UE. develop branche ;
• Vous pouvez facilement décider de ne pas diffuser la fonctionnalité avant qu'elle ne soit entièrement testée et approuvée ;

Cependant, il y a quelques inconvénients

• Le testeur doit effectuer la fusion du code et, en cas de conflit (très probable), il doit demander l'aide du développeur. Nos testeurs sont spécialisés dans les tests et ne sont pas capables de coder.
• une fonctionnalité pourrait être testée sans l'existence d'une autre nouvelle fonctionnalité. Par exemple, les fonctionnalités A et B sont toutes deux testées en même temps, les deux fonctionnalités ne sont pas au courant l'une de l'autre parce qu'aucune d'entre elles n'a été fusionnée à l'ensemble des fonctionnalités. develop branche. Cela signifie que vous devrez tester contre la develop lorsque les deux fonctionnalités seront fusionnées dans la branche de développement de toute façon. Et vous devez vous souvenir de tester cela à l'avenir.
• Si les fonctionnalités A et B sont toutes deux testées et approuvées, mais qu'un conflit est identifié lors de la fusion, les deux développeurs des deux fonctionnalités pensent que ce n'est pas leur faute ou leur travail parce que leur branche de fonctionnalité a passé le test. Il y a une surcharge de communication, et parfois la personne qui résout le conflit est frustrée.

---

Ci-dessus, notre histoire. Avec des ressources limitées, j'aimerais éviter de tout tester partout. Nous sommes toujours à la recherche d'une meilleure façon de faire face à cette situation. J'aimerais savoir comment d'autres équipes gèrent ce genre de situation.

Answer 1

Avant le test, nous fusionnons les changements de la branche de développement vers la branche de fonctionnalité.

Non, ne le faites pas, surtout si le "nous" est le testeur AQ. La fusion impliquerait la résolution de conflits potentiels, ce qui est mieux fait par les développeurs (ils connaissent leur code), et non par le testeur AQ (qui devrait passer aux tests aussi vite que possible).

Faites en sorte que le développeur fasse un rebasement de son feature sur le dessus de devel y pousser que feature branche (qui a été validée par le développeur comme compilant et fonctionnant au-dessus de la plus récente devel état de la branche).
Cela permet :

• une intégration très simple sur la branche des fonctionnalités (fusion rapide triviale).
• ou, comme recommandé par Aspasia en dessous de dans les commentaires , a demande de retrait (GitHub) o demande de fusion (GitLab) le responsable effectue une fusion entre la branche PR/MR de la fonctionnalité et la branche develop mais seulement si aucun conflit n'est détecté par GitHub/GitLab.

Chaque fois que le testeur détecte un bug, il le signale au développeur et supprimer la branche de la fonctionnalité actuelle.
Le développeur peut :

• fixer le bug
• rebase sur une branche de développement récemment récupérée (encore une fois, pour être sûr que son code fonctionne en intégration avec les autres fonctionnalités validées).
• pousser le feature branche.

Idée générale : s'assurer que la partie fusion/intégration est effectuée par le développeur, en laissant les tests à l'AQ.

Answer 2

La meilleure approche est intégration continue où l'idée générale est de fusionner les branches de fonctionnalité dans la branche de développement aussi fréquemment que possible. Cela réduit les frais généraux de la fusion des douleurs.

Faites confiance aux tests automatisés autant que possible, et faites en sorte que les constructions démarrent automatiquement avec des tests unitaires par Jenkins. Demandez aux développeurs de faire tout le travail de fusion de leurs modifications dans la branche principale et de fournir des tests unitaires pour tout leur code.

Les testeurs/QA peuvent participer aux revues de code, vérifier les tests unitaires et écrire des tests d'intégration automatisés qui seront ajoutés à la suite de régression au fur et à mesure de l'achèvement des fonctionnalités.

Pour plus d'informations, consultez ce site lien .

Answer 3

Nous utilisons ce que nous appelons "or", "argent" et "bronze". On pourrait appeler cela prod, staging, et qa.

J'en suis venu à appeler cela le modèle du melting-pot. Il fonctionne bien pour nous, car nous avons un besoin énorme d'assurance qualité pour le côté commercial des choses, car les exigences peuvent être difficiles à comprendre par rapport aux aspects techniques.

Lorsqu'un bogue ou une fonctionnalité est prêt à être testé, il passe dans la catégorie "bronze". Cela déclenche une construction Jenkins qui pousse le code vers un environnement pré-construit. Nos testeurs (qui ne sont d'ailleurs pas de grands techniciens) cliquent simplement sur un lien et ne se soucient pas du contrôle de la source. Ce build exécute également les tests, etc. Nous avons fait des allers-retours pour que ce build pousse réellement le code vers l'environnement de test. \qa environnement si les tests (unitaires, d'intégration, selenium) échouent. Si vous testez sur un système séparé (nous l'appelons lead), vous pouvez empêcher les changements d'être poussés vers votre environnement QA.

La crainte initiale était que nous ayons beaucoup de conflits entre ces fonctionnalités. Il arrive que la fonctionnalité X donne l'impression que la fonctionnalité Y est en rupture, mais c'est assez rare et c'est en fait utile. Cela permet d'obtenir un large éventail de tests en dehors de ce qui semble être le contexte du changement. Souvent, par chance, vous découvrirez comment votre changement affecte le développement parallèle.

Une fois qu'une fonctionnalité a passé avec succès le test d'assurance qualité, nous la déplaçons dans la section "silver" ou "staging". Un build est lancé et les tests sont à nouveau effectués. Chaque semaine, nous transférons ces changements vers notre arbre "gold" ou prod, puis nous les déployons sur notre système de production.

Les développeurs commencent leurs modifications à partir de l'arbre d'or. Techniquement, vous pouvez commencer à partir de l'arbre d'essai puisque celui-ci sera bientôt disponible.

Les réparations d'urgence sont placées directement dans l'arbre d'or. Si un changement est simple et difficile à évaluer, il peut être placé directement dans l'arbre argenté qui se retrouvera dans l'arbre de test.

Après la sortie de la version, nous poussons les changements de la version or (prod) vers la version bronze (testing) pour que tout reste synchronisé.

Vous pouvez vouloir rebaser avant de le pousser dans votre dossier de test. Nous avons constaté que purger l'arbre de test de temps en temps le garde propre. Il arrive que des fonctionnalités soient abandonnées dans l'arbre de test, surtout si un développeur part.

Pour les grandes fonctionnalités multi-développeurs, nous créons un repo partagé séparé, mais nous le fusionnons dans l'arbre de test de la même manière lorsque nous sommes tous prêts. Les choses ont tendance à rebondir à partir de l'AQ, il est donc important de garder vos jeux de modifications isolés afin que vous puissiez les ajouter et ensuite les fusionner dans votre arbre de test.

La "cuisson" est également un effet secondaire agréable. Si vous avez un changement fondamental que vous voulez laisser reposer pendant un certain temps, il y a un bon endroit pour cela.

Gardez également à l'esprit que nous ne maintenons pas les anciennes versions. La version actuelle est toujours la seule version. Même ainsi, vous pourriez probablement avoir un arbre de cuisson maître où vos testeurs ou votre communauté peuvent voir comment les différents contributeurs interagissent.

Answer 4

Dans notre entreprise, nous ne pouvons pas utiliser le développement agile et nous avons besoin de l'approbation de l'entreprise pour chaque changement, ce qui cause beaucoup de problèmes.

Notre approche pour travailler avec GIT est la suivante ;

Nous avons mis en œuvre "Git Flow" dans notre entreprise. Nous utilisons JIRA et seuls les tickets JIRA approuvés doivent être mis en production. Pour l'approbation des tests, nous l'avons étendu en créant une branche de test distincte.

Les étapes du traitement d'un ticket JIRA sont les suivantes :

1. Créer une nouvelle branche à partir de Develop-Branch
2. Effectuer les changements de code sur la branche de la fonctionnalité
3. Extraire de Feature les changements vers la branche Test/QA
4. Après l'approbation de l'entreprise, nous transférons le changement de la branche des fonctionnalités à la branche de développement.
5. Le développement passe fréquemment dans une version et finalement dans la branche master.

Le fait de diviser chaque demande en une fonctionnalité propre garantit que seules les modifications approuvées sont mises en production.

Le processus complet ressemble à ceci :

Answer 5

Je ne me fierais pas uniquement aux tests manuels. J'automatiserais les tests de chaque branche de fonctionnalité avec Jenkins. J'ai installé un laboratoire VMWare pour exécuter les tests Jenkins sur Linux et Windows pour tous les navigateurs. Il s'agit d'une solution de test multi-navigateurs et multi-plateformes vraiment impressionnante. Je teste les fonctions et l'intégration avec Selenium Webdriver. Mes tests Selenium s'exécutent sous Rspec. Et je les ai écrits spécialement pour être chargés par jRuby sous Windows. J'exécute les tests unitaires traditionnels sous Rspec et les tests Javascript sous Jasmine. J'ai mis en place des tests sans tête avec Phantom JS.