Justement quand je lis son poste « SemanticConflict » que tu as cité et que je lis sa première phrase :
Those who hear my colleagues and I talk about FeatureBranch know that we're not big fans of that pattern. An important part of our objection is the observation that branching is easy, but merging is hard.
C'est pour moi exactement l'inverse, si quelque chose est difficile, il faut le faire plus souvent. Si on ne fait pas quelque chose parce qu'elle est difficile, elle restera forcément difficile. Alors que si tu te casse les dents dessus 2, 3, 20 ou 30 fois. Tu va mécaniquement t'améliorer et trouver des solutions pour résoudre tes problèmes.
Pour le feature branch, il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code (ce que je vois tous les jours) et le feature branche. C'est juste que ce dernier est nommé et est plus correctement outillé. Encore une fois plus ton équipe est petite et mieux ça se passe (les merges peuvent être fait à 2). Personnellement je n'ai jamais trouvé que les merges soient véritablement difficile quand tu n'a pas des gens qui passent des semaines sans faire de merge/rebase.
Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.
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
C'est un peu de l'argumentation d'autorité ça ;) M. Fowler est intéressant, mais c'est pas mal d'aller voir ce qui se fait ailleurs (surtout qu'il y a pleins de gens qui parlent de leur expérience sur ce genre de sujets).
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).
C'est surtout pas toujours faisable d'un point de vu non technique (si le déploiement consiste à aller en centrale nucléaire installer ta nouvelle version de logiciel qui met un bout de matos en indispo, pour te cité un cas que je connais et qui est extrême).
Mais je ne suis pas d'accord sur le fait que ta stratégie de branching va jouer sur ta stratégie de release/déploiement. Encore une fois les furets ne suivent pas du tout ton idée et ils font autant de déploiement qu'ils le souhaitent (de tête plusieurs par semaine, un déploiement se fait en ~ 2h). D'ailleurs je ne me souviens pas d'avoir entendu Sacha Labourey (si tu veux que je cite une autre référence) parler de stratégie de branchement pour parler de continus deployment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Workflow git
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
Justement quand je lis son poste « SemanticConflict » que tu as cité et que je lis sa première phrase :
C'est pour moi exactement l'inverse, si quelque chose est difficile, il faut le faire plus souvent. Si on ne fait pas quelque chose parce qu'elle est difficile, elle restera forcément difficile. Alors que si tu te casse les dents dessus 2, 3, 20 ou 30 fois. Tu va mécaniquement t'améliorer et trouver des solutions pour résoudre tes problèmes.
Pour le feature branch, il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code (ce que je vois tous les jours) et le feature branche. C'est juste que ce dernier est nommé et est plus correctement outillé. Encore une fois plus ton équipe est petite et mieux ça se passe (les merges peuvent être fait à 2). Personnellement je n'ai jamais trouvé que les merges soient véritablement difficile quand tu n'a pas des gens qui passent des semaines sans faire de merge/rebase.
Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.
C'est un peu de l'argumentation d'autorité ça ;) M. Fowler est intéressant, mais c'est pas mal d'aller voir ce qui se fait ailleurs (surtout qu'il y a pleins de gens qui parlent de leur expérience sur ce genre de sujets).
C'est surtout pas toujours faisable d'un point de vu non technique (si le déploiement consiste à aller en centrale nucléaire installer ta nouvelle version de logiciel qui met un bout de matos en indispo, pour te cité un cas que je connais et qui est extrême).
Mais je ne suis pas d'accord sur le fait que ta stratégie de branching va jouer sur ta stratégie de release/déploiement. Encore une fois les furets ne suivent pas du tout ton idée et ils font autant de déploiement qu'ils le souhaitent (de tête plusieurs par semaine, un déploiement se fait en ~ 2h). D'ailleurs je ne me souviens pas d'avoir entendu Sacha Labourey (si tu veux que je cite une autre référence) parler de stratégie de branchement pour parler de continus deployment.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)