Successfully reported this slideshow.

Kanban as Code - Agile France 2017

557 vues

Publié le

Retour d'expérience du travail en Kanban d'une équipe de 20 développeurs et l'impact sur les besoins d'organisation du code.

Quelques spoilers :
1/ De façon aussi logique chaque fonctionnalité est développée de façon totalement indépendante du reste (carte kanban)
2/ Vous avez dit tout sur des branches ? Mais vous êtes fous !! Cette organisation contre intuitive permet en fait de livrer à tout moment ce qui est prêt (Continuous Delivery)
3/ Mais comment vous évitez les conflits et risque de bloquage entre deux fonctionnalités ? Notre secret est un d'avoir un outillage pensé et adapté pour détecter les incompatibilités et nous aider à garder chaque travaux indépendants

Depuis bientôt 3 ans nous avons un rythme de mise en production d'environ 1000 branches par an en 250 releases (par an !), si notre aventure vous intéresse, venez nous poser des questions.
http://lanyrd.com/2017/agilefrance/sfrhrk/

Publié dans : Internet
  • Soyez le premier à commenter

Kanban as Code - Agile France 2017

  1. 1. Kanban as Code Organisation du code @dbaeli@beastiefurets @LeanKanbanFr @geofberard
  2. 2. LesFurets.com
  3. 3. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Comparateur d’assurance 5 domaines 3M de devis par an Au contrat signé LesFurets.com
  4. 4. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli La plateforme • Des formulaires riches • 40-200 questions (Expedia c’est 10 !) • Orchestration de demande de tarifs • 50+ webservices appelé par tarification • 2 Milliards de questions échangées avec les assureurs • Module de paiement en ligne LesFurets WebSite Panel Partners Data Partners
  5. 5. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Avantages compétitifs Catalogue produit: Nombre de partenaires Vitesse d’intégration Offres à prix précis Mutualisation d’acquisition de traffic: Coût d’acquisition moindre qu’en direct sur Google Clients de qualité pour les partenaires UX - Ergonomie: Vitesse d’obtention de 10 à 20 propositions fermes Saisie unique d’information
  6. 6. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli L’équipe IT • 70 Employés • 7 Experts métier, 23 développeurs, 2 Ops, 2 Data Scientists • 3 Feature Teams (Aquisition, Conversion, Infrastructure) • 1 code base de 500.000 lines • 40.000 tests (unitaires & intégration) • 200 tests selenium + tests de regression graphique •1 à 3 release par jour (1 à 10 changements) • 1 branche par fonctionnalité :“Kanban as code” • 20-30 branches en parallèle @beatiefurets github.com/lesfurets
  7. 7. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli 7 dictionnaires de 500 pages (140 lignes / page) 2 fois les 7 tomes d’Harry Poter (3400 pages) Une nouvelle version par jour 5-10 changement par 25 rédacteurs Intermezzo : 500.000 lignes de code ? x 7 x 2
  8. 8. Releases quotidiennes ? Nos lectures & avis
  9. 9. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Manifeste agile Principe #1 « Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. » http://agilemanifesto.org/principles.html
  10. 10. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli A lire sans attendre : l’entreprise agile
  11. 11. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Kanban : Evolutionary Change 1. Visualiser le travail 2. Limiter l’encours de travail (Limit WIP) 3. Mesurer et gérer le flux 4. Rendre les règles explicites 5. S’engager dans une Amélioration Continue 6. Encourager le Leadership
  12. 12. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Ce que vous ne pouvez ignorer 1. Travailler en flux 2. Réduire le coût de livraison 3. Temps qui passe plutôt que l’effort 4. Le coût du délai 5. Observer les stocks (non fini)
  13. 13. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Livrer tôt, livrer souvent : implications http://paulhammant.com/2013/03/13/facebook-tbd-take-2/
  14. 14. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Leçon #1 : Livrer tôt, livrer souvent • L’intention de réduire le Time to Market : • Pouvoir livrer quand c’est prêt • Faire des petits lots • Impacte l’organisation • Gestion du code source • Organisation de la qualité (autonomie des développeurs) • Outillage au service du Time to market • Fail fast : Un feedback c’est un cadeau
  15. 15. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Continuous Delivery : 5 Règles d’or 1. Assemblage rapide (local) 2. Assemblage incassable (staging) 3. Déploiement automatisés rapides 4. Monitoring et alerting partout 5. Root cause analysis des incidents
  16. 16. Gestion du code en 2017 Le minimum à savoir !
  17. 17. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Git / Git Flow / Github Flow Outillage indispensable pour gérer le flux non linéaire http://nvie.com/posts/a-successful-git-branching-model/ Master Branch Pull Request Github
  18. 18. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Le vocabulaire minimum GIT (1/2) •Commit: • Une modification dans la base de code • Résumé: différence de l’original (diff ou patch) • Historique / Commit Log : • Séquence de commits • Branche: • Une copie complète du code • Géré comme un historique alternatif • Merge: • Fusion de 2 historiques / 2 histoires branch 1 branch commit 1 commit 2 commit 4 commit merge commit 3
  19. 19. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Le vocabulaire minimum GIT (2/2) • Conflit: • Lorsque deux commits sont incompatibles • Lors du merge de 2 branches • Conflict Résolution : • Commit solution à un conflit • Rebase : • mettre 2 branches en séquence • modifier le point de départ de l’histoire d’une branche • flash back, voyage dans le temps branch 1 branch 2 commit 2 commit a conflict commit 3 commit 2 commit a commit 3 rebase
  20. 20. Kanban as Code
  21. 21. @beastiefurets@dbaeli ticket1 ticket2 ticket3 ticket4 ticket5 features releaseslocal ticket3 master ticket3 ticket1 master octopus-features octopus-releases few minutes 1 jour à 1 mois 1 - 2 jours Validation 0 - 2 jours release
  22. 22. Livrer plus souvent - Step 1 Livraison chaque mois (2012)
  23. 23. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Plan / estimate / code / test / release Sprints mensuels - 12 releases par an 2012 : Monthly release
  24. 24. @beastiefurets@dbaeli branch (prod) trunk trunk Release Code Freeze branch Model 1: Branche de Release
  25. 25. @beastiefurets@dbaeli Storie 1 branch (prod) trunk trunk Release Code Freeze branch Model 1: Branche de Release
  26. 26. @beastiefurets@dbaeli Storie 1 branch (prod) trunk trunk Storie 2 Release Code Freeze branch Model 1: Branche de Release — En Théorie
  27. 27. @beastiefurets@dbaeli Storie 1 branch (prod) trunk trunk Release Code Freeze branch Model 1: Branche de Release
  28. 28. @beastiefurets@dbaeli Storie 1 branch (prod) trunk trunk Storie 2 Release Code Freeze branch Conflits potentiels Model 1: Branche de Release — En pratique
  29. 29. Livrer plus souvent - Step 2 Releases weekly (2013)
  30. 30. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli 2013 : Weekly release Planifier / estimer / coder / tester Release weekly 50 releases par an
  31. 31. @beastiefurets@dbaeli branch (prod) trunk trunk 3 - 4 semaines 1 - 4 jours5 jours Release Code Freeze branch Model 2: Patches releases
  32. 32. @beastiefurets@dbaeli branch (prod) trunk trunk Release Code Freeze branch 3 - 4 semaines 1 - 4 jours5 jours Storie 1 Model 2: Patches releases
  33. 33. @beastiefurets@dbaeli branch (prod) trunk trunk Release Code Freeze branch 3 - 4 semaines 1 - 4 jours5 jours Storie 1 Model 2: Patches releases
  34. 34. @beastiefurets@dbaeli Storie 1 branch (prod) trunk trunk Storie 2 Release Code Freeze branch 3 - 4 semaines 1 - 4 jours5 jours Model 2: Patches releases
  35. 35. @beastiefurets@dbaeli Storie 1 branch (prod) trunk trunk Storie 2 Release Code Freeze branch 3 - 4 weeks 1 - 4 days5 days 1 week Model 2: Patches releases
  36. 36. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli • Conservation du planning mensuel, mais release hebdo •Evolution: • Utilisation du processus de patch (cherry pick) • Nouveau code plus vite en production •Blocages: • Toujours une branche de release à maintenir • Livraison toujours coûteuse avec duplication de code 2013 : Livrer chaque semaine
  37. 37. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Leçon #2 : Release via le processus de patch • En cas d’incident de prod •Avez-vous un processus robuste de livraison des patches ? • NON, c’est dangereux, fabriquez-en un ! • OUI, Pourquoi ne pas l’utiliser ? •Avoir un processus robuste de livraison de patches n’est pas une option !
  38. 38. Livrer plus souvent - Step 3 Release quotidiennes (depuis 2014)
  39. 39. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli 2014: Daily Releases Livrer ce qui est prêt … chaque jour ! En mode Marathon 250+ releases par an (déjà 100 in 2017 !)
  40. 40. @beastiefurets@dbaeli master trunk 1 day 1 day Model 3: Kanban as code Storie 1 Storie 2 Storie 3
  41. 41. @beastiefurets@dbaeli master trunk 1 day 1 day Storie 1 Model 3: Kanban as code
  42. 42. @beastiefurets@dbaeli master trunk 1 day 1 day Storie 1 Model 3: Kanban as code Travail terminé ?
  43. 43. @beastiefurets@dbaeli master trunk 1 day 1 day Storie 1 Model 3: Kanban as code merge, test & drop (octopus) Merge, Test & Drop
  44. 44. @beastiefurets@dbaeli master trunk 1 day 1 day Storie 1 Model 3: Kanban as code Merge, Test & Drop merge, test & drop (octopus)
  45. 45. @beastiefurets@dbaeli master trunk 1 day 1 day Storie 1 Storie 2 Model 3: Kanban as code Merge, Test & Drop merge, test & drop (octopus)
  46. 46. @beastiefurets@dbaeli master trunk 1 day 1 day Storie 1 Storie 2 Storie 3 Model 3: Kanban as code Release de ce qui est prêt merge, test & drop (octopus)
  47. 47. @beastiefurets@dbaeli master trunk 1 day 1 day Storie 1 Storie 2 Storie 3 Model 3: Kanban as code : Livrer quand c’est prêt
  48. 48. @beastiefurets@dbaeli Garder les branches indépendantes Détecter les conflits Merge, Test & Drop git-octopus by lesfurets (on GitHub)
  49. 49. @beastiefurets@dbaeli Garder les branches indépendantes Détecter les conflits Continuous Merge git-octopus by lesfurets (on GitHub)
  50. 50. @beastiefurets@dbaeli En cas de conflit ? Détecter, éviter, livrer.
  51. 51. @beastiefurets@dbaeli Code d’origine: master
  52. 52. @beastiefurets@dbaeli master Commit 1 : Beastie Furets commit 1
  53. 53. @beastiefurets@dbaeli master Commit 2 : Hello Agile France commit 2
  54. 54. @beastiefurets@dbaeli Change 3 : Original (conflict with Change 2) master commit 3
  55. 55. @beastiefurets@dbaeli ??????? Change 3 : Hello Beastie master conflict commit 3 commit 2
  56. 56. @beastiefurets@dbaeli Eviter les conflits plutôt que les résoudre ! Pour garder l’indépendance des taches
  57. 57. @beastiefurets@dbaeli Change 3bis : New version (avoid conflict) master commit 3 commit 2
  58. 58. @beastiefurets@dbaeli Commit 1, 2: Easy merge master commit 3 commit 2 resolved commit 1
  59. 59. @beastiefurets@dbaeli Change 1, 2 & 3bis : Merge automatique master merged commit 3 commit 2 commit 1
  60. 60. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Leçon #4 : Ne pas bloquer les autres • Garder les fonctionnalités séparées jusqu’au dernier moment • Alors que tout le monde les fusionne par défaut !!! • Merge Continu (comme outil de test): • Détecter les conflits (sans être bloqués — build incassable) • Laisse le temps de gérer le conflit • Autorise à jeter facilement, ou mettre de côté sans frais •Bonus: • Le code non terminé n’est pas accessible aux autres !
  61. 61. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Nos Stratégies d’évitement de conflit 1. Eviter d’avoir des zones de conflit (dette technique) 2. Modifier une des branches 3. Supprimer une des branches (mise en attente) 4. Fusionner les branches (date de sortie commune) 5. “Rebase” d’une branche sur l’autre (sortie en séquence) 6. Publier une résolution de conflit (git-octopus)
  62. 62. @beastiefurets@dbaeli ticket1 ticket2 ticket3 ticket4 ticket5 features releaseslocal ticket3 master ticket3 ticket1 master octopus-features octopus-releases few minutes 1 jour à 1 mois 1 - 2 jours Validation 0 - 2 jours release
  63. 63. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Les Leçons de Kanban as Code #1 : Livrez tôt, livrez souvent #2 : Patch de production comme processus #3 : Evitez les conflicts #4 : Ne pas bloquer les autres Détecter, éviter, livrer.
  64. 64. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Take away : Kanban as Code Objectifs : • # Les branches sont vos cartes Kanban (vers un flux tiré) • # Flux de fonctionnel (Feature Branches ou Trunk based) • # Livrez ce qui est prêt (Commencez par finir) Pourquoi ça marche ? • # Assure l’indépendance des taches (non adhérence) • # Risques très faibles de conflits sur 500.000 lignes de code • # Détection non bloquante des conflits
  65. 65. @YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli Beastie Furets (LesFurets IT Team) @beastiefurets beastie.lesfurets.com lesfurets
  66. 66. 66 LesFurets.com LeanKanban.fr29, 30 Novembre 2017 www.leankanban.fr
  67. 67. @dbaeli @beastiefurets MERCI ! @geofberard @LeanKanbanFr

×