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 !

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
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