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

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 !

http://atmrs.esprit-agile.com/programme/

Wassel Alazhar

December 05, 2019
Tweet

More Decks by Wassel Alazhar

Other Decks in Technology

Transcript

  1. 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 ?
  2. 1 MEP par développeur par jour ≠ 1 nouvelle fonctionnalité

    mise en production par développeur par jour
  3. ๏ 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 ...
  4. 1 MEP par développeur par jour ≠ 1 nouvelle fonctionnalité

    mise en production par développeur par jour
  5. PREPROD 1 mois pour “sécuriser” la MEP La logique de

    Mr prod 1 mois pour “valider” l’architecture cible
  6. 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” !
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. La logique de Mr prod Moins de MEPs = MEPs

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

    moyen le plus risqué d’investir dans le software
  18. 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
  19. Quizz : Quelle est l’activité qui a coûté le plus

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

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

    on crée des files d’attente dans un processus long !
  22. 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
  23. 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
  24. La logique du koala Imaginez un système qui minimise le

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

    stock de “spéculations” ! Spéculations Spéculations Spéculations Spéculations
  26. 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
  27. 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 ?
  28. 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 ?
  29. Qu’est ce que cela implique ? Un retour d’experience Déploiements

    par développeur par jour Source : Forsgren PhD, Accelerate. IT Revolution, 2018
  30. Manifeste agile : Principe #1 Dans le texte Source :

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

    du “Continuous Delivery” Vous ne pouvez pas être “Agile” ! Traduction
  32. Continuous Delivery Ce n’est pas un outil ! Tant que

    ce n’est pas en prod, ce n’est pas “Done” !
  33. 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
  34. Continuous Delivery Trunk based development : un moyen de limiter

    le gaspillage Source : https://trunkbaseddevelopment.com
  35. 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
  36. 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
  37. ~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
  38. ~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
  39. 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
  40. 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
  41. 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
  42. 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
  43. Il est possible à tout moment de créer un nouvel

    environnement opérationnel “from scratch” de manière automatique Continuous Delivery Répétabilité
  44. 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
  45. Architecture Un peu Up Front mais surtout émergente et continue

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

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

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

    - z features + y nouvelles features utilisateur
  49. 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
  50. 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)
  51. Qu’est ce que cela implique ? Déploiements par développeur par

    jour Source : Forsgren PhD, Accelerate. IT Revolution, 2018
  52. 112 Ce qu’on cherche à faire dans le développement logiciel

    DO THE RIGHT THING DO THE THING RIGHT DO IT FAST
  53. 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
  54. Manifeste agile : Principe #1 Si vous ne faites pas

    du “Continuous Delivery” Vous ne pouvez pas être “Agile” ! Traduction