Et d'ailleurs ça amène la discussion (on rejoint aussi ce que dit ckylplus haut en parlant d'historique très plat) sur le terrain du Trunk based development.
Pour certains projets c'est réellement ce que je tenterais. Par exemple pour des projets web aujourd'hui je ferais plutôt du TBD (qui peut se faire aussi avec des branches à très courte durée de vie + merge squash) avec du Feature flipping (ou Branch by Abstraction). Au final je trouve que ça offre une réponse intéressante à des questions complexes comme "comment effectuer des changements profond sans diverger trop longtemps" (ex changement du moteur de stockage d'une appli). Mais pour que ce soit intéressant il faut CI avec déploiement continu. C'est un workflow vraiment agréable.
Dans l'idéal j'appliquerais ça à notre projet. Mais c'est juste pas possible. Pour avoir un déploiement continu il faut une procédure automatique qui permet de valider un code. Et donc un ensemble de tests avec une couverture et une fiabilité suffisante pour garantir le bon fonctionnement. Déjà là on tombe dans un cas tordu, si je développe une appli web ou un drone la fiabilité suffisante n'a pas le même sens. Et là je suis dans le deuxième. Ensuite la couverture aujourd'hui n'est pas suffisante car on s'interface avec du matériel. Et aujourd'hui nous n'avons pas d'autres solutions que de valider manuellement le comportement en réel (nous avons déjà eu des cas où tout fonctionnait bien en simulation mais pas en croisé sur des problématiques de temps réel par exemple).
Donc on introduit de la latence et on ne peut valider automatiquement.
Il pourrait à la rigueur y avoir des variations.
Par exemple un fonctionnement style pull request avec validation de toutes les branches indépendamment. Dans ce cas une fois de retour de tests, il suffit d'accepter ce qui passe. Mais (il y a toujours un mais) on ne teste jamais l'intégration de multiples développements (l'intérêt de notre branche d'intégration) et les tests deviennent encore plus fastidieux.
[^] # Re: Quelques retours ...
Posté par CrEv (site web personnel) . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 4.
Merci pour tous ces détails ;-)
Pour en rajouter sur le Branch by abstraction il y a aussi toute une série d'articles de qualité chez Paul Hammant : http://paulhammant.com/categories.html#branch_by_abstraction,_etc
Et d'ailleurs ça amène la discussion (on rejoint aussi ce que dit ckyl plus haut en parlant d'historique très plat) sur le terrain du Trunk based development.
Pour certains projets c'est réellement ce que je tenterais. Par exemple pour des projets web aujourd'hui je ferais plutôt du TBD (qui peut se faire aussi avec des branches à très courte durée de vie + merge squash) avec du Feature flipping (ou Branch by Abstraction). Au final je trouve que ça offre une réponse intéressante à des questions complexes comme "comment effectuer des changements profond sans diverger trop longtemps" (ex changement du moteur de stockage d'une appli). Mais pour que ce soit intéressant il faut CI avec déploiement continu. C'est un workflow vraiment agréable.
Dans l'idéal j'appliquerais ça à notre projet. Mais c'est juste pas possible. Pour avoir un déploiement continu il faut une procédure automatique qui permet de valider un code. Et donc un ensemble de tests avec une couverture et une fiabilité suffisante pour garantir le bon fonctionnement. Déjà là on tombe dans un cas tordu, si je développe une appli web ou un drone la fiabilité suffisante n'a pas le même sens. Et là je suis dans le deuxième. Ensuite la couverture aujourd'hui n'est pas suffisante car on s'interface avec du matériel. Et aujourd'hui nous n'avons pas d'autres solutions que de valider manuellement le comportement en réel (nous avons déjà eu des cas où tout fonctionnait bien en simulation mais pas en croisé sur des problématiques de temps réel par exemple).
Donc on introduit de la latence et on ne peut valider automatiquement.
Il pourrait à la rigueur y avoir des variations.
Par exemple un fonctionnement style pull request avec validation de toutes les branches indépendamment. Dans ce cas une fois de retour de tests, il suffit d'accepter ce qui passe. Mais (il y a toujours un mais) on ne teste jamais l'intégration de multiples développements (l'intérêt de notre branche d'intégration) et les tests deviennent encore plus fastidieux.