Ce que les stratégies de versioning nous disent
des dynamiques d’équipe
Benoit Lafontaine & Hervé Lourdin
Benoît Lafontaine - CTO
@joel1di1
Hervé Lourdin - CTO
@HerveLourdin
Agenda
Pourquoi cette session ?
Qu’est-ce qu’une branche ?
Modèles & impact sur la communication
Conclusion
"organizations which design systems ... are
constrained to produce designs which are
copies of the communication structure...
Qu’est-ce qu’une branche ?
Qu’est-ce qu’une branche ?
“ En gestion de configuration logicielle, une branche est une dérivation dans
l'histoire de l'é...
TL;DR
1.1 1.2 1.3 1.4 1.5
2.0 2.1 2.2
1.6
“Une branche est une
version alternative du
code source d’un logiciel”
Benoit & Hervé
Pourquoi on branche ?
Pour paralleliser les dev sans se perturber
● Pour livrer les fonctionnalités au fur et à mesure de ...
Qui dit branches, dit...
Modèles de versioning / branching et
impact sur la communication dans les
équipes
1.1 1.31.2
Trunk Base
Développeur A
Développeur B
master
1.1 1.31.2
Team Branch
Equipe A
Equipe B
master
1.1 1.3
Team Branch
Equipe A
Equipe B
Merge
de la mort1.2
Merge trop
compliqué
on passe
master
1.1 1.31.2
Feature Branch
master
Feature A
Feature B
Git Flow
In Progress Done UAT Expedite Live
Code review
Code review
1.1 1.31.2
Pull Request Flow
Pull
Request
Pull
Request
Feature Branching + Continuous Merge
+
Feature Toggle
Anti-patterns communs
La branche qui dérive
Le moine codeur
L’équipe d’intégration
Conclusion
Adapter sa stratégie à son contexte
Les stratégies de versioning elles-aussi peuvent évoluer dans le temps
Une organisatio...
Merger c’est discuter !
la communication apparait au moment du merge
L’enjeu est de provoquer la conversation au bon momen...
Questions ?
Benoît Lafontaine - CTO
@joel1di1
Hervé Lourdin - CTO
@HerveLourdin
Psst… Nous recrutons !
MERCI !
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe
Prochain SlideShare
Chargement dans…5
×

Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe

1 222 vues

Publié le

« 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

Publié dans : Logiciels
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 222
Sur SlideShare
0
Issues des intégrations
0
Intégrations
102
Actions
Partages
0
Téléchargements
20
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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.

  • Lean Kanban France 2015 : Ce que les strategies de versioning nous disent des dynamiques d equipe

    1. 1. Ce que les stratégies de versioning nous disent des dynamiques d’équipe Benoit Lafontaine & Hervé Lourdin
    2. 2. Benoît Lafontaine - CTO @joel1di1 Hervé Lourdin - CTO @HerveLourdin
    3. 3. Agenda Pourquoi cette session ? Qu’est-ce qu’une branche ? Modèles & impact sur la communication Conclusion
    4. 4. "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" — M. Conway
    5. 5. Qu’est-ce qu’une branche ?
    6. 6. 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
    7. 7. TL;DR 1.1 1.2 1.3 1.4 1.5 2.0 2.1 2.2 1.6
    8. 8. “Une branche est une version alternative du code source d’un logiciel” Benoit & Hervé
    9. 9. 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)
    10. 10. Qui dit branches, dit...
    11. 11. Modèles de versioning / branching et impact sur la communication dans les équipes
    12. 12. 1.1 1.31.2 Trunk Base Développeur A Développeur B master
    13. 13. 1.1 1.31.2 Team Branch Equipe A Equipe B master
    14. 14. 1.1 1.3 Team Branch Equipe A Equipe B Merge de la mort1.2 Merge trop compliqué on passe master
    15. 15. 1.1 1.31.2 Feature Branch master Feature A Feature B
    16. 16. Git Flow
    17. 17. In Progress Done UAT Expedite Live
    18. 18. Code review Code review 1.1 1.31.2 Pull Request Flow Pull Request Pull Request
    19. 19. Feature Branching + Continuous Merge +
    20. 20. Feature Toggle
    21. 21. Anti-patterns communs
    22. 22. La branche qui dérive
    23. 23. Le moine codeur
    24. 24. L’équipe d’intégration
    25. 25. Conclusion
    26. 26. 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
    27. 27. 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
    28. 28. Questions ?
    29. 29. Benoît Lafontaine - CTO @joel1di1 Hervé Lourdin - CTO @HerveLourdin Psst… Nous recrutons ! MERCI !

    ×