Le plus simple au monde, celui qui reste compatible avec SVN et ses limitations (mais nous utilisons Git, ... à bon escient):
Le Trunk Base Development.
Une branche pour les gouverner tous.
Ponctuellement, une branche de hotfix peut-être nécessaire, mais les protagonistes de Continuous Deployment la proscrivent et privilégient la mise à disposition de correctifs dans le trunk.
Il est important de dissocier les différents niveaux de maturité en agilité.
Le premier est l'intégration continue. Tout est intégré au fil de l'eau
Le second est le continuous delivery. On fait en sorte que tout ce qui est intégré soit potentiellement déployable (build au vert et tests automatisés à gogo pour s'assurer de la qualité de la livraison)
Le niveau ultime est le continuous deployment. Le déploiement est automatisé lors de chaque build. C'est l’achèvement du DevOps (nous sommes loin de ce niveau de maturité hélas).
Wikipedia explique très bien la différence
Sinon, une autre raison invoquée pour mettre en oeuvre des branches (long-lived) et que je n'avais pas évoquée concerne les migrations techniques.
On peut-être tenté de créer une branche pour migrer vers un nouveau framework ou toute autre raison technique qui affecte son architecture
Là aussi ça devient complexe à gérer. Car il faut systématiquement reporter les évolutions livrées dans la branche de prod vers la nouvelle branche de migration technique.
Une autre stratégie peut-être mise en place. Le "Branching by Abstraction". Ceci consiste à développer une couche d'abstraction dans le trunk puis faire pointer ton architecture dessus, implémenter la nouvelle et basculer dessus. L'avantage c'est que par la force des choses ton architecture devient plus évolutive et par conséquent sa qualité s'améliore (la couche d'abstraction reste).
Et pour conclure, je cite souvent Martin Fowler. Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3. Dernière modification le 17 septembre 2016 à 20:41.
Le plus simple au monde, celui qui reste compatible avec SVN et ses limitations (mais nous utilisons Git, ... à bon escient):
Le Trunk Base Development.
Une branche pour les gouverner tous.
Et voici quelques ressources.
Ponctuellement, une branche de hotfix peut-être nécessaire, mais les protagonistes de Continuous Deployment la proscrivent et privilégient la mise à disposition de correctifs dans le trunk.
Il est important de dissocier les différents niveaux de maturité en agilité.
Sinon, une autre raison invoquée pour mettre en oeuvre des branches (long-lived) et que je n'avais pas évoquée concerne les migrations techniques.
On peut-être tenté de créer une branche pour migrer vers un nouveau framework ou toute autre raison technique qui affecte son architecture
Là aussi ça devient complexe à gérer. Car il faut systématiquement reporter les évolutions livrées dans la branche de prod vers la nouvelle branche de migration technique.
Une autre stratégie peut-être mise en place. Le "Branching by Abstraction". Ceci consiste à développer une couche d'abstraction dans le trunk puis faire pointer ton architecture dessus, implémenter la nouvelle et basculer dessus. L'avantage c'est que par la force des choses ton architecture devient plus évolutive et par conséquent sa qualité s'améliore (la couche d'abstraction reste).
Et pour conclure, je cite souvent Martin Fowler. Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile