Relis le lien que je t'ai donné qui fait la différence entre le continuous deployment et les approches agiles traditionnelles (Scrum) .
Avec les méthodes agile les livraisons ne sont pas conditionnées par le périmètre fonctionnel mais par le découpage du temps. On peur revenir sur ce périmètre mais pas sur la date de livraison (sprint). Les équipes ont parfois tendance à repousser les efforts d'intégration et de test à la fin (même avec de la CI derrière). Parfois elles sont à la bourre et bizarrement la course à l’échalote recommence comme au bon vieux temps du cycle en V. Et là ca y va à cou de branches temporaires ou de revert pour virer des stories ... c'est l'effet mini-tunnel décrit par l'auteur.
Si on se met dans l'état d'esprit d'accepter que chaque User story complétée est potentiellement déployable (continuous deliveries) ou "pire" si l'on sait qu'elle est vraiment livrée (continuous deplopyment) dès qu'elle est prête pplutôt que de la grouper avec d'autre, alors plus d'effort d'intégration à la dernière minute.
Pour assurer ca, il faut pouvoir facilement désactiver une feature tant qu'il y des commits intermédiaire et que la story n'est pas complète ou de corriger rapidement (pas facile avec une appli dont on ne maîtrise pas le déploiement comme les applis mobiles).
Quand on ne peut pas garantir ça. Le seul moyen qui reste est donc une branche par feature qu'on intègre par merge d'es qu'elle est complétée même si c'est décrié par les agilistes puristes.
Pour assurer la CI. On peut automatiser le merge de chaque commit sur le trunk vers chaque branche de feature.
S'il casse le build, il faut la corriger illico. Du coup on reste en contact avec le trunk et plus de Big Bang merge.
voir ici : http://testonsteroid.tumblr.com/post/14231829163/continuous-integration-flow
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2. Dernière modification le 10 janvier 2014 à 15:52.
C'est bien ça.
Relis le lien que je t'ai donné qui fait la différence entre le continuous deployment et les approches agiles traditionnelles (Scrum) .
Avec les méthodes agile les livraisons ne sont pas conditionnées par le périmètre fonctionnel mais par le découpage du temps. On peur revenir sur ce périmètre mais pas sur la date de livraison (sprint). Les équipes ont parfois tendance à repousser les efforts d'intégration et de test à la fin (même avec de la CI derrière). Parfois elles sont à la bourre et bizarrement la course à l’échalote recommence comme au bon vieux temps du cycle en V. Et là ca y va à cou de branches temporaires ou de revert pour virer des stories ... c'est l'effet mini-tunnel décrit par l'auteur.
Si on se met dans l'état d'esprit d'accepter que chaque User story complétée est potentiellement déployable (continuous deliveries) ou "pire" si l'on sait qu'elle est vraiment livrée (continuous deplopyment) dès qu'elle est prête pplutôt que de la grouper avec d'autre, alors plus d'effort d'intégration à la dernière minute.
Pour assurer ca, il faut pouvoir facilement désactiver une feature tant qu'il y des commits intermédiaire et que la story n'est pas complète ou de corriger rapidement (pas facile avec une appli dont on ne maîtrise pas le déploiement comme les applis mobiles).
Quand on ne peut pas garantir ça. Le seul moyen qui reste est donc une branche par feature qu'on intègre par merge d'es qu'elle est complétée même si c'est décrié par les agilistes puristes.
Pour assurer la CI. On peut automatiser le merge de chaque commit sur le trunk vers chaque branche de feature.
S'il casse le build, il faut la corriger illico. Du coup on reste en contact avec le trunk et plus de Big Bang merge.
voir ici :
http://testonsteroid.tumblr.com/post/14231829163/continuous-integration-flow