Vous êtes sur la bonne voie, mais j'élargirais un peu votre diagramme:
Fondamentalement (si votre contrôle de version le permet, c'est-à-dire si vous utilisez hg / git), vous voulez que chaque paire développeur / développeur ait sa propre branche "personnelle", qui contient une seule histoire utilisateur sur laquelle ils travaillent. Une fois la fonctionnalité terminée, ils doivent entrer dans une branche centrale, la branche "Release". À ce stade, vous voulez que le développeur obtienne une nouvelle branche, pour la prochaine chose sur laquelle il doit travailler. La branche de fonction d'origine doit être laissée telle quelle, de sorte que toutes les modifications qui doivent y être apportées peuvent être apportées isolément (ce n'est pas toujours applicable, mais c'est un bon point de départ). Avant qu'un développeur ne revienne travailler sur une ancienne branche de fonctionnalité, vous devez tirer sur la dernière branche de version, pour éviter des problèmes de fusion étranges.
À ce stade, nous avons un candidat de version possible sous la forme de la branche "Release", et nous sommes prêts à exécuter notre processus CI (sur cette branche, vous pouvez évidemment le faire sur chaque branche de développeur, mais c'est assez rare dans les grandes équipes de développement, il encombre le serveur CI). Cela peut être un processus constant (c'est idéalement le cas, le CI doit s'exécuter chaque fois que la branche "Release" est modifiée), ou il peut être nocturne.
À ce stade, vous voudrez exécuter une build et obtenir un artefact de build viable à partir du serveur CI (c'est-à-dire quelque chose que vous pourriez déployer de manière faisable). Vous pouvez ignorer cette étape si vous utilisez un langage dynamique! Une fois que vous êtes construit, vous allez vouloir exécuter vos tests unitaires, car ils sont la base de tous les tests automatisés du système; ils sont susceptibles d'être rapides (ce qui est bien, car tout l'intérêt de CI est de raccourcir la boucle de rétroaction entre le développement et les tests), et il est peu probable qu'ils aient besoin d'un déploiement. S'ils réussissent, vous souhaiterez déployer automatiquement votre application sur un serveur de test (si possible) et exécuter tous les tests d'intégration dont vous disposez. Les tests d'intégration peuvent être des tests d'interface utilisateur automatisés, des tests BDD ou des tests d'intégration standard utilisant un cadre de tests unitaires (c'est-à-dire "unité"
À ce stade, vous devriez avoir une indication assez complète de la viabilité de la construction. La dernière étape que je configurerais normalement avec une branche "Release" consiste à la faire déployer automatiquement la version candidate sur un serveur de test, afin que votre service d'assurance qualité puisse effectuer des tests de fumée manuels (cela se fait souvent tous les soirs au lieu de chaque enregistrement afin de pour éviter de gâcher un cycle de test). Cela donne juste une indication humaine rapide de savoir si la version est vraiment adaptée à une version en direct, car il est assez facile de manquer des choses si votre pack de test est moins complet, et même avec une couverture de test à 100%, il est facile de manquer quelque chose que vous pouvez 't (ne devrait pas) tester automatiquement (comme une image mal alignée ou une faute d'orthographe).
Il s'agit vraiment d'une combinaison d'intégration continue et de déploiement continu, mais étant donné que dans Agile, l'accent est mis sur le codage simplifié et les tests automatisés en tant que processus de première classe, vous souhaitez viser à obtenir une approche aussi complète que possible.
Le processus que j'ai décrit est un scénario idéal, il existe de nombreuses raisons pour lesquelles vous pouvez en abandonner certaines parties (par exemple, les branches de développement ne sont tout simplement pas réalisables dans SVN), mais vous souhaitez viser autant que possible .
En ce qui concerne la façon dont le cycle de sprint Scrum s'inscrit dans cela, idéalement, vous voulez que vos versions se produisent aussi souvent que possible, et ne pas les laisser jusqu'à la fin du sprint, car obtenir un retour rapide pour savoir si une fonctionnalité (et la construction dans son ensemble) ) est viable pour un passage à la production est une technique clé pour raccourcir votre boucle de rétroaction à votre Product Owner.