Utiliser les branches de test dans Git

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?

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.

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.

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.)