Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Une MEP par développeur par jour

Une MEP par développeur par jour

Wassel ALAZHAR

Comment livrer de la valeur, rapidement et constamment, à nos utilisateurs ?
Comment garantir une qualité de service tout en faisant des mises en production en permanence ?
À quoi sert-il de faire des mises en production chaque jour, voire plusieurs fois par jour ?
Et comment peut-on réussir à faire cela ?

Ce talk est un retour d'expérience. C'est l'histoire d'une équipe qui a réussi à contourner les processus historiques d'un grand groupe industriel, pour déployer un service qui sera rapidement adopté dans ses usines.

Je détaillerai :
- Les pratiques de continuous delivery qui ont été mises en place
- L'architecture pour soutenir notre rythme de livraison et les principes qui nous ont guidés
- Comment il a été possible de maintenir ce rythme de livraison en intégrant de nouveaux développeurs
- Les pièges dans lesquels on est tombés. Oops !

5dd8b91d96af5a1e33962df41c1a4d20?s=128

Esprit Agile

December 05, 2019
Tweet

Transcript

  1. Une MEP par développeur par jour

  2. Améliorer sa performance de Delivery ? Une démarche scientifique à

    la recherche de la performance Quelles sont les caractéristiques d’une organisation technologique performante ?
  3. Déploiements par développeur par jour Source : Forsgren PhD, Accelerate.

    IT Revolution, 2018
  4. C’est l’histoire d’un nouveau produit

  5. None
  6. None
  7. None
  8. Qui suis-je ? Wassel Alazhar https://www.meetup.com/crafting-datascience @wasselovski https://github.com/jcraftsman Consultant, Développeur,

    Explorateur de problèmes
  9. Une MEP par développeur par jour Késako, pourquoi et comment

    ?
  10. Une MEP par développeur par jour KÉSAKO ?

  11. 1 MEP par développeur par jour ≠ 1 nouvelle fonctionnalité

    mise en production par développeur par jour
  12. Source : Forsgren PhD, Accelerate. IT Revolution, 2018 Déploiements par

    développeur par jour
  13. DEV OPS PROD Pipeline sécurisée Base de code

  14. DEV OPS PROD Operation manuelle

  15. ๏ Des changements automatiques : > Fix des vulnérabilités >

    Mise à jour des dépendances ๏ Des changements de configuration ๏ Aucune opération manuelle en production => Toute opération est versionnée et donne potentiellement lieu à un déploiement automatique ...
  16. 1 MEP par développeur par jour ≠ 1 nouvelle fonctionnalité

    mise en production par développeur par jour
  17. Capacité à mettre en prod quand on veut

  18. Maintenir la Capacité à mettre en prod quand on veut

    À l’échelle
  19. Capacité à changer en permanence

  20. Maintenir la Capacité à changer en permanence À l’échelle

  21. Une MEP par développeur par jour POURQUOI ?

  22. La logique de Mr Prod MEP = Risques

  23. La logique de Mr Prod Moins de MEPs = Moins

    de Risques
  24. La logique de Mr prod

  25. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod
  26. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible
  27. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” !
  28. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” ! 4 - 6 mois
  29. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” ! Spéculations
  30. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” ! Spéculations
  31. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” ! Spéculations Certaines hypothèses fonctionnelles ne marchent pas
  32. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” ! Spéculations Certaines hypothèses fonctionnelles ne marchent pas Spéculations
  33. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” ! Spéculations Spéculations Spéculations
  34. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible D E V Q A D E V Q A D E V Q A Là, vous pouvez faire de “l’agile” ! Spéculations Spéculations Spéculations Spéculations
  35. PREPROD La logique de Mr prod Spéculations vProd vProd+1 “Sécuriser”

    la MEP
  36. La logique de Mr prod Moins de MEPs = Gros

    périmètre de MEP
  37. La logique de Mr prod - Sources potentielles d’échec -

    Plus grande probabilité d’échec En cas de problèmes, c’est plus difficile d’identifier la source Moins de MEPs = Gros périmètre de MEP
  38. La logique de Mr prod - Sources potentielles d’échec -

    Plus grande probabilité d’échec En cas de problèmes, c’est plus difficile d’identifier la source Risque d’écart entre environnements Risque de changements manuels Debug long Confs de crises Moins de MEPs = Gros périmètre de MEP
  39. La logique de Mr prod Moins de MEPs = MEPs

    plus risquée = Delivery moins prédictible
  40. La logique de Mr prod Moins de MEPs = Le

    moyen le plus risqué d’investir dans le software
  41. Parlons productivité !

  42. Quizz : Quelle est l’activité qui a coûté le plus

    cher pour la réalisation d’un changement ? A - Dev B - QA C - Préprod D - La réponse D shorturl.at/fgodu
  43. PollEv.com/WASSELALAZHA232

  44. Quizz : Quelle est l’activité qui a coûté le plus

    cher pour la réalisation d’un changement ? L’attente !
  45. L’attente Exemples En attente de : - confirmation de règle

    - dispo d’environnement - déploiement - résolution ...
  46. L’attente est l’activité invisible qui coûte le plus cher quand

    on crée des files d’attente dans un processus long !
  47. L’attente est le résultat d’un système qui limite l’autonomie des

    équipes
  48. Un système optimisé pour : • Stocker des spéculations •

    Produire du temps d’attente entre équipes • Faire des conf de “crise” • Créer des super-héros La logique de Mr prod
  49. Stabilité : Équilibre dans un état contrôlé Immobilité : Équilibre

    dans un état terminal VS
  50. Les différents niveaux de performance High performers Medium performers Low

    performers INDICATEURS DE VITESSE Deployment frequency > 1 / jour 1 / semaine - 1 / mois 1 / semaine - 1 / mois Product delivery lead time < 1 heure 1 semaine - 1 mois 1 semaine - 1 mois INDICATEURS DE STABILITÉ Mean time to repair < 1 heure < 1 jour 1 - 7 jours Change failure rate 0 -15% 0 -15% 31- 45% Source : Forsgren PhD, Accelerate. IT Revolution, 2018
  51. Il n’y a pas de choix à faire entre vitesse

    et stabilité !
  52. La logique du koala : Plus de MEP = Moins

    Risques
  53. La logique du koala Imaginez un système qui minimise le

    stock de “spéculations” ! Spéculations
  54. La logique du koala Imaginez un système qui minimise le

    stock de “spéculations” ! Spéculations Spéculations Spéculations Spéculations
  55. La logique du koala Imaginez un système qui minimise le

    stock de “spéculations” ! 1/2 - 5 jours Spéculations Spéculations Spéculations Spéculations
  56. La logique du koala Imaginez un système qui minimise le

    stock de “spéculations” ! 1/2 - 5 jours Spéculations Spéculations Spéculations Spéculations Ça fait combien de MEP en 4 mois ?
  57. La logique du koala Imaginez un système qui minimise le

    stock de “spéculations” ! 1/2 - 5 jours Spéculations Spéculations Spéculations Spéculations Ça fait combien Valeur ajoutée en 4 mois ?
  58. Une MEP par développeur par jour COMMENT ?

  59. Qu’est ce que cela implique ? Un retour d’experience Déploiements

    par développeur par jour Source : Forsgren PhD, Accelerate. IT Revolution, 2018
  60. Capacité à mettre en prod quand on veut

  61. Manifeste agile : Principe #1 Dans le texte Source :

    https://agilemanifesto.org/principles.html
  62. Manifeste agile : Principe #1 Si vous ne faites pas

    du “Continuous Delivery” Vous ne pouvez pas être “Agile” ! Traduction
  63. Retour d’expérience

  64. Continuous Delivery Ce n’est pas un outil ! Tant que

    ce n’est pas en prod, ce n’est pas “Done” !
  65. Versionnez tout ! - Code applicatif - Code d'infrastructure -

    Configuration applicative - Configuration système - Scripts d’automatisation - Scripts utilitaires - Expérimentations Continuous Delivery L’obsession du versionning Source : https://trunkbaseddevelopment.com
  66. Continuous Delivery Trunk based development : un moyen de limiter

    le gaspillage Source : https://trunkbaseddevelopment.com
  67. Continuous Delivery La pipeline mise en place Intégration continue (CI)

    Déploiement continue sur un environnement Déploiement planifié en pré-prod 2 fois par jour Déploiement à la demande en prod One click deployment Déclenchement automatique à chaque changement de code
  68. Intégration continue (CI) Continuous Delivery La pipeline mise en place

    ~1300 tests automatisés BUILD Compilation et packaging Tests unitaires Tests d’integration Tests fonctionnels Versionning d’artefact + création de tag
  69. ~1300 tests automatisés Intégration continue (CI) BUILD Compilation et packaging

    Tests unitaires Tests d’integration Tests fonctionnels Versionning d’artefact + création de tag Continuous Delivery La pipeline mise en place Le code est livrable et conforme à la compréhension des dév Déclenchement automatique à chaque changement de code
  70. ~1300 tests automatisés Intégration continue (CI) BUILD Compilation et packaging

    Tests unitaires Tests d’integration Tests fonctionnels Versionning d’artefact + création de tag Continuous Delivery La pipeline mise en place La pipeline est sécurisée : On ne peut livrer que la dernière version qui passe l’ensemble des vérification de la chaîne Déclenchement automatique à chaque changement de code
  71. Déploiement continue sur un environnement Déploiement Vérification des l’état des

    service après déploiement Mise à jour du reporting Continuous Delivery La pipeline mise en place
  72. Déploiement continue sur un environnement Déploiement Vérification des l’état des

    service après déploiement Mise à jour du reporting Continuous Delivery La pipeline mise en place La nouvelle version est mise à disposition des métiers et de toute l’ équipe Déclenchement automatique à chaque changement de code
  73. Continuous Delivery Reproductibilité La Pré-prod et la prod sont identiques

    en : - Services déployées - Sizing - Même flux d’événements (Merci Kafka) - Même données - Même volumétrie
  74. Continuous Delivery Reproductibilité La Pré-prod et la prod sont identiques

    en : - Services déployées - Sizing - Même flux d’événements (Merci Kafka) - Même données - Même volumétrie
  75. Il est possible à tout moment de créer un nouvel

    environnement opérationnel “from scratch” de manière automatique Continuous Delivery Répétabilité
  76. Il est possible à tout moment de créer un nouvel

    environnement opérationnel “from scratch” de manière automatique Continuous Delivery Répétabilité Les développeurs le font en permanence
  77. Dès que : - C’est pénible - Ça fiabilise votre

    délivery Automatisez !
  78. Les machines exécutent les tâches récurrentes Les humains résolvent les

    problèmes ! Automatisez !
  79. Capacité à changer en permanence

  80. Architecture Un peu Up Front mais surtout émergente et continue

  81. Architecture Un peu Up Front mais surtout émergente et continue

    + 1 nouvelle feature utilisateur
  82. Architecture Un peu Up Front mais surtout émergente et continue

    + 2 nouvelles features utilisateur
  83. Architecture Un peu Up Front mais surtout émergente et continue

    - 2 features utilisateur
  84. Architecture Un peu Up Front mais surtout émergente et continue

    + 1 nouvelle feature utilisateur
  85. Architecture Un peu Up Front mais surtout émergente et continue

    + 1 nouvelle feature utilisateur
  86. Architecture Un peu Up Front mais surtout émergente et continue

    + 3 nouvelles features utilisateur
  87. Architecture Un peu Up Front mais surtout émergente et continue

    + x nouvelles features utilisateur
  88. Architecture Un peu Up Front mais surtout émergente et continue

    - z features + y nouvelles features utilisateur
  89. Architecture Un peu Up Front mais surtout émergente et continue

    - z features + y nouvelles features utilisateur
  90. Architecture Un peu Up Front mais surtout émergente et continue

    - z features + y nouvelles features utilisateur
  91. Architecture Un peu Up Front mais surtout émergente et continue

    - z features + y nouvelles features utilisateur
  92. L’équipe fait des choix techniques (Implémentation, Conception, Architecture, Outils…). L’équipe

    est autonome pour tester et déployer.
  93. L’équipe fait des choix techniques (Implémentation, Conception, Architecture, Outils…). L’équipe

    est autonome pour tester et déployer. X
  94. Démos et Feedbacks utilisateurs TDD BDD “Donne moi un exemple”

    Code review systématique Pair programming Refactoring Infra as code Pratiques pour maintenir un modèle mental aligné Event storming DDD Inversion de dépendance Principes de clean archi (CQRS par endroit) Mob programming Rétro tech
  95. Un modèle mental aligné Pour un delivery prédictible

  96. Maintenir un modèle mental aligné Pour un delivery prédictible

  97. Maintenir un modèle mental aligné Pour un delivery prédictible

  98. Maintenir un modèle mental aligné Pour un delivery prédictible

  99. Maintenir un modèle mental aligné Pour un delivery prédictible

  100. Maintenir un modèle mental aligné Pour un delivery prédictible

  101. 63 MEPs • ~ 1 MEP tous les 2 jours

    • 1 seule MEP en échec (Régression sur une fonctionnalité majeure) • Fix livré en 20 min 800 déploiements réussis tous environnements confondus • ~ 1,11 déploiements par dev par jour Temps moyen du dév à la MEP d’une User Story* : 2,7 j Les métriques de l’équipe En 6 mois avec 6 développeurs (*) temps moyen calculé entre le début du développement et la MEP de tout type de changement (Inclut evol, fix et changement d’infrastructure)
  102. Qu’est ce que cela implique ? Déploiements par développeur par

    jour Source : Forsgren PhD, Accelerate. IT Revolution, 2018
  103. Source : Forsgren PhD, Accelerate. IT Revolution, 2018

  104. CONCLUSION

  105. 111 Choisissez la vitesse ET la stabilité VITESSE STABILITÉ

  106. 112 Ce qu’on cherche à faire dans le développement logiciel

    DO THE RIGHT THING DO THE THING RIGHT DO IT FAST
  107. 113 Renversez les priorités DO THE RIGHT THING DO THE

    THING RIGHT DO IT FAST DO THE RIGHT THING DO THE THING RIGHT DO IT FAST Se donner les moyens d’aller vite pour livrer ce qui compte
  108. Capacité à mettre en prod quand on veut

  109. Manifeste agile : Principe #1 Si vous ne faites pas

    du “Continuous Delivery” Vous ne pouvez pas être “Agile” ! Traduction
  110. Une architecture continue pour maintenir l’évolutivité

  111. Questions ?

  112. MERCI