Utiliser les branches de test dans Git


11

Nous avons quelqu'un (appelons-le Ted) qui est chargé de tester les nouvelles fonctionnalités et les corrections de bugs.

Nous utilisons Git et GitHub . masterdevrait être / est toujours déployable et developmentc'est là que nous validons / fusionnons les nouvelles fonctionnalités ou corrections de bugs, mais seulement après qu'elles ont été testées par Ted.

Le projet est en PHP.

J'aimerais que le processus de test se déroule comme suit:

  1. Un développeur veut travailler sur une nouvelle fonctionnalité (disons que la fonction / bug # 123 comme Ted documenté dans le suivi des problèmes), alors il tire origin/developmentà developmentson dépôt local et crée une nouvelle branche (disons issue-123) à partir de là.
  2. Une fois satisfait de son travail, il s'engage et pousse sa nouvelle branche vers origin.
  3. Ted se connecte à test.ourproject.com/choose-branchet voit une liste des branches originactivées et choisit de s'allumer issue-123(cela devrait être faisable via la page Web). Il continue ensuite test.ourproject.com, teste l'enfer de l'application Web (il est vraiment impitoyable) et après quelques allers-retours avec le développeur, il est satisfait de la fonctionnalité.
  4. Ted dit le développeur qu'il peut fusionner issue-123sur developmentle origin.
  5. Rincez et répétez.

Pour la troisième étape, je pourrais pirater quelque chose qui fait le travail (afficher et changer de branche à partir d'une page spécifique), mais je pense que ce que j'ai décrit est un modèle très courant.

Ma question est donc la suivante: s'agit -il d'un bon flux de travail / durable / maintenable pour la branche? Pouvez-vous sauvegarder votre réponse en citant quelques exemples d'autres projets suivant ce workflow?


"teste l'enfer de la webapp (il est vraiment imprudent) et après quelques va-et-vient avec le développeur, il est satisfait de la fonctionnalité." - Cette personne doit être proche du génie. Sait-il réellement de quoi parle le code en question? Il existe des projets comme celui-ci mais je doute vraiment des résultats de l'étape 3.
SChepurin

J'aurais dû clarifier la issue-123référence au bogue / fonctionnalité # 123 car Ted documente chaque bogue / nouvelle fonctionnalité de notre outil de suivi des problèmes.
CPA

@cpa: Qu'il soit plus clair. Les questions sont modifiables.
Jan Hudec

@SChepurin: Le testeur n'a besoin de rien savoir du code. Ils ont juste besoin d'avoir une liste des fonctionnalités et bogues requis et des cas de test pour eux.
Jan Hudec

1
@cpa Je ne sais pas trop ce que vous recherchez. Vous voulez un logiciel qui aide les testeurs à déterminer quelles branches sont disponibles pour les tests et à changer de branche pour eux? Ou un processus pour les testeurs à suivre?
mjs

Réponses:


5

Le flux de travail de la branche ressemble beaucoup à gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow et il existe des outils de support autour. C'est fortement recommandé.

S'il n'y a qu'un seul testeur, votre flux de travail de test sonne bien, mais s'il y a plusieurs personnes, le développement peut se déplacer entre le début et la fin, et bien sûr, les tests devraient idéalement être entièrement effectués après toute fusion. C'est là que les tests automatisés peuvent vraiment aider ou qu'un testeur lent (approfondi) pourrait ne jamais terminer!

Un autre problème est qu'avec de nombreuses fonctionnalités et branches, il devient difficile de mélanger et de faire correspondre les fonctionnalités dans une version (ou de choisir de les expulser après acceptation et fusion) ou peut-être si les fonctionnalités dépendent les unes des autres. Le problème est que si vous commencez à être tenté de réécrire l'historique (rebaser / supprimer un commit ou une fusion) sur une branche signifiée PUBLISHED qui a été poussée vers un référentiel multidév. C'est réécrire l'histoire publique. Cela peut être fait pour le bien ou pour le mal et même s'il est fait pour le bien, cela peut causer des problèmes aux imprudents, et la meilleure pratique est de l'éviter afin que la question ne se pose jamais. Cependant, certains workflows de branche d'intégration rendent cela très tentant, donc si vous avez une forte protection sur de telles branches (par exemple, restrictions de branche par gitolite par utilisateur) et que les gens s'attendent à une telle activité, alors rebasez toujours leur code sur une telle branche, continuez - avec prudence!

Je voudrais également recommander de lire http://sethrobertson.github.com/GitBestPractices/ qui traite de toutes ces questions et contient de nombreuses bonnes références.


git-flown'est pas exactement ce que je cherchais, mais c'est certainement quelque chose dont nous avons besoin! Merci!
cpa

2

Je ne suis pas sûr que la page de changement elle-même soit un modèle courant. La plupart des projets demandent simplement au testeur de le vérifier avec la commande git.

L'approche générale semble certainement raisonnable.

Google a même écrit Gerrit pour prendre en charge un style similaire; il s'agit davantage de réviser le code, mais l'approbation de l'intégration implique normalement à la fois une révision et des tests. Habituellement, il est également interconnecté avec un serveur d'intégration continue qui crée d'abord toutes les soumissions (je ne sais pas s'ils utilisent Jenkins dans Google, mais je crois avoir vu des connecteurs appropriés quelque part).

Git lui-même utilise une légère variation sur le thème. Son mainteneur dispose d'un script qui fusionne toutes les soumissions en attente dans une branche appelée pu(pour les «mises à jour proposées», probablement; la branche est supprimée et recréée à chaque fois car les soumissions en attente sont souvent rebasées). C'est que testé par diverses personnes. Si tout va bien, les soumissions considérées comme complètes sont fusionnées next(c'est la même chose que la vôtre development). Sinon, quelqu'un teste les soumissions individuelles pour voir laquelle est cassée. Cela rend le testeur un peu plus facile, car ils n'ont pas à changer de branche la plupart du temps; ils indiquent simplement si l'intégration du test fonctionne.


1

Si vos tests sont effectués automatiquement plutôt que manuellement, je pense que Travis (un système CI pour GitHub) fera à peu près ce que vous voulez - il exécute automatiquement des tests sur toutes les demandes d'extraction. ( Plus d'informations sur ce processus, y compris des captures d'écran. )

Notez que les tests ne sont pas exécutés sur la branche, mais la branche après avoir été fusionnée dans master. (c.-à-d. ce que vous obtiendriez après la fusion de la branche en maître - vous êtes assuré que les tests continueront de fonctionner avec succès après la fusion.)

Si des validations sont ajoutées à la branche, les tests sont réexécutés. (Bien que pour une raison quelconque, l'ajout de validations à master ne semble pas relancer les tests.)


Et si les tests échouent sur la branche? Voulez-vous vraiment avoir du code sur le maître avec des tests qui échouent? ... qui aurait pu être récupéré sur la branche elle-même avant de fusionner avec master? Personnellement, je pense que seul le code qui construit et réussit tous les tests unitaires, d'intégration et autres devrait être fusionné dans master, car c'est là que se trouvent les versions.
Ash

@Ash Le code n'est pas réellement fusionné dans master; si je comprends bien, les tests sont exécutés sur une branche essentiellement temporaire qui est le résultat de la fusion de la branche en cours de test en maître.
mjs
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.