Mais pour que ce soit intéressant il faut CI avec déploiement continu.
Pas forcément du continuous deployment. Ceci implique que tout changement est déployé en automatique et dans la vraie vie c'est rarement le cas (sauf che les equipes de GitHub ;-)
En moins ambitieux on peut se limiter au continuous delivery. On s'assure que tout changement est potentiellement déployable.
Le déploiement effectif en recette se fait sur une base régulière qui regroupe plusieurs changement mais ne fait fait qu'officialiser la livraison. Par exemple si pratiques vraiment le continuous delivery avec Scrum, une livraison à la fin d'un sprint est presqu'un n on événement. C'est juste un tag à poser sur un commit pour satisfaire le time boxing mais rien de plus. Ca fournit des indicateurs sur la gestion de projet mais c'est tout.
Les équipes Scrum qui se limitent à la CI sont souvent confrontée à un mini effet tunnel ou on essaie de stabiliser la branche à l'arrache
avant la fin du sprint alors que le continuous delivery sécurise ça tout au long du sprint.
C'est vraiment bien expliquer dans ce post: http://kief.com/iterations-considered-harmful.html
Dans ton cas, effectivement même le continuous delivery n'est pas possible car vous n'avez pas l'assurance de la qualité.
La question est donc de savoir comment gérer au mieux l'activation sélective des fonctionnalités.
Soit par le code (feature flipping ?), soit avec des branches d'intégration.
Si vous vous limitez à une seule branche d'intégration et que vous avez besoin d'ôter une feature, tu peux reprendre à partir du dernier commit avant la feature à desactiver et rebaser les autres features par dessus. Ton approche avec des rebases+merge pour l'intégration fonctionnera très bien. (plus propre que revert amha)
Si vous souhaitez avoir plusieurs configurations de features activées différents et donc plusieurs branches d'intégration, vous devez procéder par merge pour l'intégration (sans rebase) d'une feature et ne jamais vous réaligner dedans. (merge d'une branche d'intégration vers la feature branch proscrit)
Une branche de feature reste donc isolée complètement et une fois complétée, elle est intégrée par merge dans une ou plusieurs branches
Avantage plus de souplesse pour switcher des fonctionnalités.
Inconvénient: Merge d'intégration plus conséquents (git rerere à gogo)
Sinon avec votre workflow actuel, dans mon post initial, je ne voyais pas avec ton approche par rebase comment obliger le dev à rebaser à chaque commit sur l'intégration, mais un "simple" hook pre-commit qui empêche le push de la feature branch si la base n'est pas le denier commit d'integ suffit.
[^] # Re: Quelques retours ...
Posté par El Titi . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 2.
Pas forcément du continuous deployment. Ceci implique que tout changement est déployé en automatique et dans la vraie vie c'est rarement le cas (sauf che les equipes de GitHub ;-)
En moins ambitieux on peut se limiter au continuous delivery. On s'assure que tout changement est potentiellement déployable.
Le déploiement effectif en recette se fait sur une base régulière qui regroupe plusieurs changement mais ne fait fait qu'officialiser la livraison. Par exemple si pratiques vraiment le continuous delivery avec Scrum, une livraison à la fin d'un sprint est presqu'un n on événement. C'est juste un tag à poser sur un commit pour satisfaire le time boxing mais rien de plus. Ca fournit des indicateurs sur la gestion de projet mais c'est tout.
Les équipes Scrum qui se limitent à la CI sont souvent confrontée à un mini effet tunnel ou on essaie de stabiliser la branche à l'arrache
avant la fin du sprint alors que le continuous delivery sécurise ça tout au long du sprint.
C'est vraiment bien expliquer dans ce post:
http://kief.com/iterations-considered-harmful.html
Dans ton cas, effectivement même le continuous delivery n'est pas possible car vous n'avez pas l'assurance de la qualité.
La question est donc de savoir comment gérer au mieux l'activation sélective des fonctionnalités.
Soit par le code (feature flipping ?), soit avec des branches d'intégration.
Si vous vous limitez à une seule branche d'intégration et que vous avez besoin d'ôter une feature, tu peux reprendre à partir du dernier commit avant la feature à desactiver et rebaser les autres features par dessus. Ton approche avec des rebases+merge pour l'intégration fonctionnera très bien. (plus propre que revert amha)
Si vous souhaitez avoir plusieurs configurations de features activées différents et donc plusieurs branches d'intégration, vous devez procéder par merge pour l'intégration (sans rebase) d'une feature et ne jamais vous réaligner dedans. (merge d'une branche d'intégration vers la feature branch proscrit)
Une branche de feature reste donc isolée complètement et une fois complétée, elle est intégrée par merge dans une ou plusieurs branches
Avantage plus de souplesse pour switcher des fonctionnalités.
Inconvénient: Merge d'intégration plus conséquents (git rerere à gogo)
Sinon avec votre workflow actuel, dans mon post initial, je ne voyais pas avec ton approche par rebase comment obliger le dev à rebaser à chaque commit sur l'intégration, mais un "simple" hook pre-commit qui empêche le push de la feature branch si la base n'est pas le denier commit d'integ suffit.