Discussion :

[Marco46]

Si des personnes font de l'intégration continue en utilisant git comme SCM, j'aimerais avoir votre avis sur ce sujet. Je parle ici de CI dans le but d'aller vers du continuous delivery (être en capacité de livrer quand on veut) puis du continuous deployment (livrer à chaque commit), il ne s'agit pas d'avoir un Jenkins parce que c'est à la mode.

Le principe de l'intégration continue, c'est de merger le travail des développeurs le plus souvent possible, et d'exécuter tests et build sur un serveur d'intégration afin de donner de la visibilité sur l'état du code source et la capacité à livrer asap.

Avec git, de nombreux worfklow sont possibles. Un des points critiques du workflow, c'est ce que j'appellerais la merging strategy : Comment on merge, quand et pourquoi.

Il existe grosse modo 2 merging strategies : la synchronization point strategy, et la continuous integration strategy.

La synchronization point strategy est celle défendue par Linus Torvalds dans un mail écrit en 2009 (pas trop récent mais pas si vieux que ça). L'idée générale est que la principale valeur ajoutée de git c'est sa gestion de l'historique et qu'il est donc primordial de le conserver propre et logique. On ne merge donc pas à tout va, on prend son temps, on ne merge que quand on a terminé proprement sa feature, on demande avant de merger. Ça permet également de préparer beaucoup plus facilement le scope d'une livraison.

La CI strategy c'est quasiment l'inverse. Elle est prônée par Martin Fowler dans la documentation de gitlab. On merge le plus souvent possible, plusieurs fois par jour si possible. Cette stratégie a pour défaut de produire un historique dégueulasse. Elle a également comme grave défaut d'obliger l'implémentation du feature flipping, chose qui peut être très complexe à mettre en oeuvre, en particulier dans les ihm.
Cette strategy a par contre pour avantage de simplifier les merge puisqu'on les fait très souvent. Elle se dirige aussi plus naturellement vers du continuous delivery et surtout vers le continuous deployment, c'est à dire les dernières pratiques en la matière.

Comment vous vous organisez de votre côté ?

Pour ma part je suis vraiment embêté. D'un côté je trouve la SPS plus secure et plus facile à gérer, mais elle se pose sur un cycle beaucoup plus long, et je vois mal comment faire du continuous deployment (cible ultime) avec ...

[Luckyluke34]

Excellente question.

And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be relevant to the development work _you_ do.

Je ne suis pas, mais alors pas du tout d'accord avec ça. Et on touche peut-être du doigt la différence majeure entre un programmeur relativement solitaire à la Torvalds et un développeur fondamentalement social comme Fowler.

Pourtant ce qui me chiffonne (je suis le seul à voir cette contradiction ?), c'est que si on regarde tout le reste du mail de Linus en mettant de côté cette petite phrase, les raisonnements de lui et Martin Fowler ne sont pas si mutuellement exclusives que ça. Torvalds ne dit rien explicitement sur la fréquence de push, juste que le code doit être "clean" et "ready". Et il ne définit pas "ready".

Personnellement, j'aurais tendance à dire que la coordination d'équipe prime sur tout. Si une partie de l'équipe se base sur le travail d'autres membres, par exemple si on produit une API qui va être consommée par les autres, on va évidemment pusher fréquemment et utiliser l'intégration continue à fond pour que les pièces du puzzle s'emboîtent le plus rapidement et le plus correctement possible.
Du coup ma propre limite entre "not ready" et "ready" a tendance à être assez basse :

• code qui compile (obvious mais bon)
• tests unitaires qui passent -- non seulement les tests qu'on a ajoutés dans le cadre de la feature mais aussi bien sûr toute la suite de tests créée collectivement au fil du temps.
• changeset cohérent avec un message de commit clair qui correspond au but du changeset.
• changeset qui a de la valeur et ready-to-use, sinon directement fonctionnellement dans l'application, au moins pour l'utilisation du code par le reste de l'équipe

La CI strategy c'est quasiment l'inverse. Elle est prônée par Martin Fowler dans la documentation de gitlab. On merge le plus souvent possible, plusieurs fois par jour si possible. Cette stratégie a pour défaut de produire un historique dégueulasse. Elle a également comme grave défaut d'obliger l'implémentation du feature flipping, chose qui peut être très complexe à mettre en oeuvre, en particulier dans les ihm.

Pas encore lu l'article de Fowler mais ça m'étonne grandement sur 2 points :

- Produire un historique dégueulasse => je n'ai pas l'impression que c'est ce que Fowler prône d'habitude. Si par dégueulasse tu entends avec beaucoup de ramifications dans l'arbre d'historique, c'est possible mais plein de gens vivent avec sans souci. Si ça veut dire pusher des bribes de features qui n'ont aucun sens, du code qui ne va pas compiler, des tests qui ne vont pas passer ou des messages de commit abscons, je ne crois pas que ça soit le propos.

- La CI strategy oblige l'implémentation du feature flipping => pas l'impression que Fowler ait jamais imposé d'utiliser de feature toggle, et surtout CI est une approche beaucoup trop vaste pour être automatiquement corelée à cette technique précise.


Sinon j'adore la phrase de fin

You're very much allowed to quote me on this
and use it as an explanation of "do this, because that is what Linus
expects from the end result".

On ne peut pas faire plus représentatif du personnage

Ca montre aussi tout le paradoxe de Git qui est considéré par tout le monde comme LE standard générique alors que son créateur a au contraire une approche hyper personnelle et très arrêtée du source control qu'il entend promouvoir et imposer à tous ceux qui utilisent son "bébé".

[Marco46]

Je ne suis pas, mais alors pas du tout d'accord avec ça. Et on touche peut-être du doigt la différence majeure entre un programmeur relativement solitaire à la Torvalds et un développeur fondamentalement social comme Fowler.

Pourtant ce qui me chiffonne (je suis le seul à voir cette contradiction ?), c'est que si on regarde tout le reste du mail de Linus en mettant de côté cette petite phrase, les raisonnements de lui et Martin Fowler ne sont pas si mutuellement exclusives que ça. Torvalds ne dit rien explicitement sur la fréquence de push, juste que le code doit être "clean" et "ready". Et il ne définit pas "ready".

Je suis pas trop d'accord avec toi, il a défini le statut "ready" :

Slightly more complex version: "Always have a _reason_ for merging downstream stuff". That reason might be: "This branch is the release branch, and is _not_ the 'random development' branch, and I want to merge that ready feature into my release branch because it's going to be part of my next release".

Pour moi c'est très clair, il s'agit d'une feature terminée. C'est à dire prête à partir dans la prochaine release. Il dit aussi qu'il peut y avoir des exceptions pour récupérer un code qui est développé par un dev A et qui est une dépendance pour un développeur B (dans ce cas le dev B va tirer la dépendance voulue directement depuis le tree de A) :

And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be relevant to the development work _you_ do. Sometimes you have to (in order to solve some particularly nasty dependency issue), but it should be a very rare and special thing, and you should think very hard about it.

Or Martin Fowler prone l'inverse, plutôt que de tirer de puis le tree de A, il propose que toute le monde merge plusieurs fois par jour dans la branche d'intégration des développements.

Tu as pointé néanmoins le problème général qui est : Quelle est la définition d'un code ready à être mergé avec le travail des autres ?

Martin Fowler indique dans son document qu'une implémentation du feature flipping est obligatoire parce qu'il est inenvisageable que les 3 ou 4 push que tu vas faire dans la même journée correspondent à 3 ou 4 features finalisées et autonomes. Donc il va bien falloir désactiver ces features pour l'utilisateur final dans un contexte de CD. Sinon on va présenter un fonctionnel incohérent à l'utilisateur.

Pour ce qui est de l'historique clean ou pas, je pense qu'il y a un problème de définition ou au moins de degré. Est ce qu'un historique clean c'est :
- un historique bien linéaire sur une seule branche avec des commits atomiques avec des messages ayant du sens (approche angularjs par exemple)
- un historique avec des merge request visibles clairement dans l'historique mais ayant un sens fonctionnel fort (approche Torvalds, et également gitflow à mon sens)

Avec la 1ère approche, on peut push régulièrement des tous petits morceaux de features, dont le code est propre, qui compile, dont les TU passent, mais qui ne couvrent pas toute l'implémentation du fonctionnel demandé dans la feature. Et tout ça est mélangé dans l'arbre.

Avec la 2ème approche, on ne peut pas avoir les mêmes critères de push, on veut une branche à part mergée back dans la branche d'intégration des devs avec un commit de merge (--no-ff) afin de distinguer clairement la fonctionnalité ainsi que les commits qui ont traits à cette fonctionnalité dans le tree pour une version livrable donnée.

Mon dilemne c'est : Autant je pense que la 2ème approche est meilleure en terme de valeur ajoutée apportée par l'historique (il sera plus cohérent), autant je ne vois pas comment faire du CD avec cette approche.

Merci pour ta contribution c'est un sujet qui me travaille depuis un moment et j'arrive pas à me décider.

[Luckyluke34]

Tu m'as un peu perdu sur la différence entre les deux conceptions d'un historique clean. Je ne savais pas qu'Angular JS préconisait des choses au niveau source control - à moins que tu parles de la base de code du projet Angular lui-même ?

Est-ce qu'on est pas aussi en train de tout mélanger : la topologie des repositories, la politique de branching (feautre branch ou pas...), la politique de déploiement continu, la politique d'approbation de code entre développeurs, la nature des développements réalisés qui va déterminer la granularité des changesets (deux développeurs solitaires qui travaillent sur des parties séparées intégrées de temps en temps, une équipe étroitement collaborative qui utilise les briques les uns des autres, etc.) ?

Ca me parait un peu réducteur de tirer de toutes les combinaisons de ces critères, seulement deux workflow Git.

Dans mon équipe on a un repo central qui sert pour la CI, et on pushe souvent des bouts de code qui ne sont pas des features au sens produit mais qui servent aux autres devs. On ne fait pas de CD. On fait du rebase pour éviter les arbres trop touffus, et du du no-ff lors des merge pour garder les commit intermédiaires. Nos code review sont faites hors du système de source control, on ne fait pas de pull request. Du coup, on se situe où dans le tableau ?

Le truc avec Git, c'est que tout le monde y compris son créateur réfléchit en ayant à l'esprit des contraintes implicites qui sont celles de son petit contexte métier dans son petit coin, mais personne n'a la lucidité de présenter ces contraintes avant de proclamer "ceci est la meilleure façon d'utiliser Git". Du coup, on se retrouve avec une flopée de médailles d'or toutes valides sur le papier mais qui affirment catégoriquement des règles qui paraissent super bizarres dans un autre contexte.

Martin Fowler indique dans son document qu'une implémentation du feature flipping est obligatoire parce qu'il est inenvisageable que les 3 ou 4 push que tu vas faire dans la même journée correspondent à 3 ou 4 features finalisées et autonomes. Donc il va bien falloir désactiver ces features pour l'utilisateur final dans un contexte de CD. Sinon on va présenter un fonctionnel incohérent à l'utilisateur.

Tu peux me donner le passage exact car je ne vois pas où il dit que c'est obligatoire ? Par ailleurs, CD n'est pas CI, ça va beuacoup plus loin et demande d'être plus rigoureux. A la rigueur je suis d'accord pour du CD mais tu évoquais une approche CI au début.

[Marco46]

Tu m'as un peu perdu sur la différence entre les deux conceptions d'un historique clean. Je ne savais pas qu'Angular JS préconisait des choses au niveau source control - à moins que tu parles de la base de code du projet Angular lui-même ?

Je parle bien de l'écriture du code d'angular. Ils ont un google doc sur ce sujet.

Est-ce qu'on est pas aussi en train de tout mélanger : la topologie des repositories, la politique de branching (feautre branch ou pas...), la politique de déploiement continu, la politique d'approbation de code entre développeurs, la nature des développements réalisés qui va déterminer la granularité des changesets (deux développeurs solitaires qui travaillent sur des parties séparées intégrées de temps en temps, une équipe étroitement collaborative qui utilise les briques les uns des autres, etc.) ?

Oui on mélange un peu tout mais on est bien obligé. C'est parce que c'est mélangé et compliqué que j'ai du mal à me forger un avis sur ce sujet. Tes réflexions m'ont déjà permis de clarifier certaines choses, ne serait-ce qu'en exprimant mes réponses à tes posts, j'espère que d'autres devs expérimentés viendront donner leur avis.

et du du no-ff lors des merge pour garder les commit intermédiaires

Là je comprends pas trop, un merge ff ne perd pas les commits intermédaires, simplement pour faire un ff il faut avoir rebasé au préalable. C'est précisément de cette manière que tu obtiens un historique linéaire.

Les merge no-ff au contraire créent un commit de merge permettant de garder la visibilité de la branche dans l'arbre. Pour imager plus clairement.

Ca me parait un peu réducteur de tirer de toutes les combinaisons de ces critères, seulement deux workflow Git.

Dans mon équipe on a un repo central qui sert pour la CI, et on pushe souvent des bouts de code qui ne sont pas des features au sens produit mais qui servent aux autres devs. On ne fait pas de CD. On fait du rebase pour éviter les arbres trop touffus, et du du no-ff lors des merge pour garder les commit intermédiaires. Nos code review sont faites hors du système de source control, on ne fait pas de pull request. Du coup, on se situe où dans le tableau ?

Je sais pas ! Moi j'ai 2 devs juniors et je suis leur techlead. Je fais à peu près pareil sauf qu'ils me poussent leur code sur leur branche de feature sur le repo puis ils font une merge request (gitlab), je tire la branche sur mon poste, je check, si ça va je merge sinon je demande d'autres commits.

Le truc avec Git, c'est que tout le monde y compris son créateur réfléchit en ayant à l'esprit des contraintes implicites qui sont celles de son petit contexte métier dans son petit coin, mais personne n'a la lucidité de présenter ces contraintes avant de proclamer "ceci est la meilleure façon d'utiliser Git". Du coup, on se retrouve avec une flopée de médailles d'or toutes valides sur le papier mais qui affirment catégoriquement des règles qui paraissent super bizarres dans un autre contexte.

Ben en fait tout dépend du workflow de livraison du service / entreprise dans lequel tu bosses. Mais dans l'optique de respecter les meilleurs pratiques, même si on te demande de ne livrer que tous les 15 jours, être capable de le faire tous les jours parce que tu gères bien ton source c'est quand même cool non ?

Tu peux me donner le passage exact car je ne vois pas où il dit que c'est obligatoire ? Par ailleurs, CD n'est pas CI, ça va beuacoup plus loin et demande d'être plus rigoureux. A la rigueur je suis d'accord pour du CD mais tu évoquais une approche CI au début.

C'est dans les deux paragraphes qui suivent la partie "Do not order commits with rebase". Il y a des citations d'un article de Martin Fowler sur le feature flipping.

[Luckyluke34]

Là je comprends pas trop, un merge ff ne perd pas les commits intermédaires, simplement pour faire un ff il faut avoir rebasé au préalable

Je me suis mal exprimé, je voulais dire préserver la branche d'où viennent les commit mergés dans l'arbre cf http://blog.jonathanoliver.com/my-ne...t-merge-no-ff/

Ben en fait tout dépend du workflow de livraison du service / entreprise dans lequel tu bosses. Mais dans l'optique de respecter les meilleurs pratiques, même si on te demande de ne livrer que tous les 15 jours, être capable de le faire tous les jours parce que tu gères bien ton source c'est quand même cool non ?

Oui, mais justement ce n'est pas un workflow Git en soi mais un exemple d'objectif bien exprimé derrière lequel on peut mettre X workflows différents. Je ne vois rien de fondamentalement opposé à la vision de Torvalds, à part la fameuse phrase qui me posait problème. Il ne parle nulle part de fréquence de livraison. Il parle beaucoup plus de "comment et quoi merger" que de "quand livrer".

C'est dans les deux paragraphes qui suivent la partie "Do not order commits with rebase".

J'ai bien lu mais pas d'obligation, juste une option dans certains cas particuliers, si on a une feature branch qui dure longtemps et si on ne peut pas faire de plus petits commits... et d'ailleurs ils ne font pas de lien direct avec la notion de CI strategy.