Grande question. Je ne pense pas qu'il y ait une réponse correcte «officielle» à cela. Cela dépend de la vitesse à laquelle vous pouvez tester.
Le problème essentiel est que chaque fusion, compilation ou même déploiement peut potentiellement créer un bug. Plus la chaîne que vous testez est avancée, plus vous êtes au courant des bogues, mais aussi plus vous devez tester à nouveau.
Afin de vous assurer que vous avez testé le logiciel que les clients utilisent, vous devez vraiment tester le déploiement en direct avant que le trafic des clients (en supposant une application Web) soit acheminé vers ces serveurs via un modèle de déploiement bleu / vert.
Mais évidemment, c'est un peu tard dans la journée pour être la première fois que vous vérifiez le code!
Si vous testez une branche de publication dans un environnement qa, vous pouvez prendre le risque et réduire les tests en direct aux tests de fumée uniquement. et appliquer des corrections de bogues à la branche de publication. Mais vous ne pouvez pas évaluer si une fonctionnalité est complète avant de créer une version
Si vous testez le développement, vous obtenez des mini-branches de correction de bogues. Les fonctionnalités sont toujours fusionnées avant d'être évaluées, et les fonctionnalités de la prochaine version peuvent entrer en collision avec le test de la version actuelle.
Si vous testez des branches de fonctionnalités, vous avez besoin d'un million d'environnements et devez orchestrer l'ordre des fusions et tester les approbations. plus beaucoup de nouveaux tests.
D'après mon expérience, je recommanderais:
test rapide de la branche de fonctionnalité sur la machine de développement. assurez-vous simplement que sa fonctionnalité est complète et que les testeurs / développeurs conviennent de la signification des exigences.
Tests quotidiens / tests automatisés sur la branche de développement déployée sur les serveurs qa. Vous permet de tester toutes les fonctionnalités ensemble et de dire quand vous êtes prêt à sortir.
Si toutes les fonctionnalités sont présentes mais que le test n'est pas terminé. par exemple, le sprint est terminé. créer une branche de publication et déployer dans un deuxième environnement qa. Cela permet de corriger / corriger les bogues de la version 1 en même temps que les fonctionnalités de la version 2.
(Les passionnés de Scrum diront que vous ne devriez mettre que des corrections de bugs dans le sprint 2 mais soyons pratiques)
Tests de fumée sur le déploiement vert / bleu en direct avant le basculement. Celles-ci sont super importantes car vous récupérerez des erreurs de configuration / d'environnement que personne ne recherche vraiment lors du développement.