Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
•Télécharger en tant que PPTX, PDF•
3 j'aime•1,630 vues
« La structure d’un système est à l’image de la structure de communication de l’organisation qui l’a conçu » . La Loi de Conway a été démontrée à maintes reprises, mais au delà de l’organisation formelle des équipes, la stratégie de branching que l’on adopte décrit et affecte les modes de communications entre collaborateurs. Nous parcourrons les différentes stratégies de branching (feature branch, git flow, etc). Nous observerons alors pour chacune d’elles les impacts et conséquences sur nos modes de communication. A la fin de cette session, vous ne brancherez plus par hasard ! Présentation par Benoit Lafontaine et Hervé Lourdin
Recommandé
Recommandé
Contenu connexe
Similaire à Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Similaire à Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe (20)
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
- 1. Ce que les stratégies de versioning nous disent des dynamiques d’équipe Benoit Lafontaine & Hervé Lourdin
- 2. Benoît Lafontaine - CTO @joel1di1 Hervé Lourdin - CTO @HerveLourdin
- 3. Agenda Pourquoi cette session ? Qu’est-ce qu’une branche ? Modèles & impact sur la communication Conclusion
- 5. "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" — M. Conway
- 8. Qu’est-ce qu’une branche ? “ En gestion de configuration logicielle, une branche est une dérivation dans l'histoire de l'évolution des éléments de configuration. Une branche est une évolution d'un élément ayant pour origine une version précise, produisant une «branche de version». Une branche de version correspond à un axe d'évolution de versions. Elle est rattachée à une branche source et peut découler sur plusieurs sous-branches. La gestion de l'ensemble des branches et des versions d'un produit constitue le versionnage (versioning en anglais) et est l'objet de la gestion de configuration.” Source: Wikipedia
- 9. TL;DR 1.1 1.2 1.3 1.4 1.5 2.0 2.1 2.2 1.6
- 10. “Une branche est une version alternative du code source d’un logiciel” Benoit & Hervé
- 11. Pourquoi on branche ? Pour paralleliser les dev sans se perturber ● Pour livrer les fonctionnalités au fur et à mesure de leur complétion (livrer A sans livrer B qui n’est pas fini, ni C qui ne correspond pas aux attentes)
- 12. Qui dit branches, dit...
- 13. Modèles de versioning / branching et impact sur la communication dans les équipes
- 15. 1.1 1.31.2 Trunk Base Développeur A Développeur B master
- 17. 1.1 1.31.2 Team Branch Equipe A Equipe B master
- 18. 1.1 1.3 Team Branch Equipe A Equipe B Merge de la mort1.2 Merge trop compliqué on passe master
- 19. 1.1 1.31.2 Feature Branch master Feature A Feature B
- 20. Git Flow
- 21. In Progress Done UAT Expedite Live
- 25. Code review Code review 1.1 1.31.2 Pull Request Flow Pull Request Pull Request
- 28. Feature Branching + Continuous Merge +
- 29. Feature Toggle
- 32. La branche qui dérive
- 33. Le moine codeur
- 35. Conclusion
- 36. Adapter sa stratégie à son contexte Les stratégies de versioning elles-aussi peuvent évoluer dans le temps Une organisation qui croît ou change nécessite de revoir la validité de sa stratégie Challengez vos choix initiaux pour voir si ils sont toujours valables ! Inspirez-vous des modèles et adaptez les à votre contexte
- 37. Merger c’est discuter ! la communication apparait au moment du merge L’enjeu est de provoquer la conversation au bon moment Le merge et surtout la gestion de conflits sont les évenements clés caractérisant les modes de communications les merges difficiles sont caractéristiques d’un processus où la communication n’est pas assez fréquente Plus vous mergez tard plus vous repoussez une conversation importante au lendemain … dont la résolution sera peut-être plus complexe
- 38. Questions ?
- 39. Benoît Lafontaine - CTO @joel1di1 Hervé Lourdin - CTO @HerveLourdin Psst… Nous recrutons ! MERCI !
Notes de l'éditeur
- Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1968; it was first dubbed Conway's law by participants at the 1968 National Symposium on Modular Programming.[1] It states that
- HLO -- Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1968; it was first dubbed Conway's law by participants at the 1968 National Symposium on Modular Programming.[1] It states that
- HLO
- branche implicite : Un dev qui travaille en local Branche par abstraction : feature flipping
- BLA ~ 8mins
- 1er pattern de branche : on fait tout pour éviter les branches Debut projet Petite équipe => Monde idéal du kanban avec un WIP de 1 sur tout notre board : on ne branche jamais
- MEP gros points = On se met d’accord (Appaloosa) Pas bcp, se font confiance. Ce que ça nous dit : vraisemblablement petit équipe avec une bonne communication
- Un moment, souvent envie de vivre tranquille On branche
- 1 branche par équipe / pers
- !! sentiment qu’on éloigne les problèmes => 1ère incarnation de l’anti-pattern branche qui dérive Pas bien ! mais il faut bien //
- !!! PAS de feature branches sur des team branch Ex 1 : (Moins de confiance dans l’équipe et son organisation) Octopod quand ils passent à 5. On intègre de nouveaux devs. Besoin de s’assurer de la relecture de code.
- BLA ~12 mins Process regroupant plein de “best practices” Releases branches Features branches Master est le reflet de la prod Branches pour les hotfixes en prod Adapté quand on a des cycles de release avec des features assez longues (on ne sait pas dans quelle release elles vont aller). Exemple : Meetic (partie mobile), Le Monde (mobile) Vu qu’on est a LKFR, on va vouloir fluidifier… Les hotfixes deviennent des features comme les autres. On livre les features a fil de l’eau. Et hop, on retombe sur github flow.
- S’APPUYER SUR LES MANQUES DU FEATURE BRANCHING POUR EPLIQUER POURQUOI GITFLOW C’EST BIEN DIRE QUAND LE MODELE N’EST PAS ADEQUATE
- Fork permis pour pouvoir dev dans leur coin une amélioration => comment on intègre nos modifs sur un repo dont on n’a pas les droits ? => pull request
- du pattern de fork est donné le github flow => intégration dans gitlab Github flow, gitlab flow Feature branches avec un emphase sur l’action de pull request Pull request : github/bitbucket car la première action de resp est le pull) Merge request : parce la dernière action du resp est le merge Ce que met en évidence ces patterns, ce sont les actions de discussions et de correction. (toute équipe faisant des feature branches avec une phase de relecture avant intégration fait du “github flow”) Exemple : Appaloosa, sauf exception devs sur branches, pull request dans avec phabricator et archanist => permet d’avoir une IHM plus simple et de bloquer (concrètement les PR qui ne sont pas correctes, mais comme on peut pousser directement sans faire la PR, cela reste de la confiance)
- BLA
- HLO
- Visible dans toutes les stratégies Branches explicites : on voit sur le graph Sur trunk base : qd un dev ne pousse pas Ex : Développeur isolé (exemple du stagiaire qui manque d’encadrement chez appaloosa) Equipes qui se parlent pas
- Equipe de préintégration Au final, on déporte les disfonctionnements à la fin du process lors de l’intégration. Souvent parti de la volonté d’isoler les features pour mieux paralleliser les taches. Poussé par certains éditeur (a l’époque Clear Case), en mettant en avant les atout techniques de merges et réduisant ce merge à une étape purement technique. Martin Fowler. En pratique, une fois que les branches ont considérablement divergé, c’est super compliqué de le faire. Du coup, comme c’est pas trivial, on met des gens dédiés, souvent les plus compétents, car c’est finalement une étape complexe (contradiction avec le postulat de base, mais personne ne le souligne). Même si les outils comme git ou mercurial ont vraiment facilité les merges, ca reste vrai. => équipe d’intégration dédié = merde dans notre process On peut mettre l’explication des sémantics conflicts (mais en fait trop tech) (ERDF) : équipe de pré-intégration ! lol : certains devs des différentes équipes font un bout d’intégration. Ensuite ça passe à l’équipe d’intégration.