Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

devops REX 2018 - Comment la qualité reflète-t-elle nos organisations ?

142 views

Published on

Talk donné lors de devops REX 2018, la conférence devops 100% retours d'expériences - http://www.devopsrex.fr

Speaker : Joris CALABRESE
Entreprise : Meetic

Dans un environnement de transformation digitale, d’Agilité at Scale, il est primordial de mesurer notre capacité à apporter de la valeur à nos utilisateurs. Cela revient également à mesurer la performance de nos organisations, dixit Melvin Conway, « Les organisations qui conçoivent les systèmes sont contraintes de produire des modèles qui sont des copies de leur propre structure de communication ».

Dans ce contexte, comment la qualité peut-elle être un indicateur clé pour mesurer notre performance ? Comment, nos pratiques de tests, reflètent-elles nos organisations ? Au travers mon expérience chez Meetic durant ces 5 dernières années, je vous propose un retour d’expérience sur les grands changements stratégiques techniques et produits qui m’ont amené à vous proposer cette réflexion autour de l’impact de nos organisations sur la qualité.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

devops REX 2018 - Comment la qualité reflète-t-elle nos organisations ?

  1. 1. REX Meetic, QUALITÉ ET ORGANISATION
  2. 2. a JORIS CALABRESE Director Of Engineering User Product Tribe @jorisCalabrese
  3. 3. JORIS CALABRESE Backend Software Engineering Manager
  4. 4. TRANSFORMATION DIGITALE
  5. 5. TRANSFORMATION DIGITALE
  6. 6. Nous devons nous focaliser sur l’EXPÉRIENCE UTILISATEUR
  7. 7. COMMENT MESURER ?
  8. 8. LOI DE CONWAY
  9. 9. Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations Melvin Conway – 1968
  10. 10. ORGANISATION LOI DE CONWAY
  11. 11. DEVOPS?
  12. 12. COMMENT MESURER ?
  13. 13. ET SI LA QUALITÉ…
  14. 14. QUALITÉ = GESTION DE RISQUES
  15. 15. QUALITÉ TEMPS DE CYCLE BUGS FLOWAUTOMATISATION TimetoUser TestsUnitaires TestsFonctionnels TestsExploratoires Bugscreation Vs Bugsresolved
  16. 16. AUTOMATISATION : POURQUOI ? DESIGN PO REVIEW R7 TESTING PRODUCTION COÛT DE CORRECTION D’UN BUG
  17. 17. AUTOMATISATION CI
  18. 18. TEMPS DE CYCLE : POURQUOI ? DÉPLOYER NE DOIT PAS ÊTRE UN ÉVÉNEMENT
  19. 19. TEMPS DE CYCLE CHANGEMENTS IMPORTANTS RAREMENT PEU DE CHANGEMENTS SOUVENT
  20. 20. BUGS FLOW: POURQUOI?
  21. 21. BUGS FLOW CREATED BUGS VS RESOLVED BUGS
  22. 22. MATURE NOVICE COMMENT MESURER ? AUTOMATISATION TEMPS DE CYCLE BUGS FLOW
  23. 23. HISTOIRE DE MEETIC
  24. 24. MEETIC CROÎT… COMME TOUTES LES STARTUPS À SUCCÈS INVEST IN STARTUP NEW FEATURE S ATTRACT MORE USERS IMPROVE REVENUE
  25. 25. MEETIC LEADER EUROPEEN DU DATING EN LIGNE
  26. 26. CYCLE DE DEVELOPPEMENT SOFTWARE ENGINEERS SOFTWARE ENGINEERS SOFTWARE ENGINEERS Implémentation basée sur des spécifications Tests manuels sur l’environnement de développement QA Définition des cas de tests Tests manuels sur la R7 Release Management: RELEASE 1 RELEASE 2 15 JOURS 15 JOURS
  27. 27. TMA Identification des Root Causes Répartition des bugs Correction des problèmes transverses QA OPS CYCLE DE MAINTENANCE SOFTWARE ENGINEERS SOFTWARE ENGINEERS Identification des bugs Qualification des bugs
  28. 28. QA SOFTWARE ENGINEER S R7 SERVER RELEASE MANAGER PROD SERVER DEV SERVER PROD SERVER PROD SERVER PUBLIO
  29. 29. NOTRE MÉTRIQUE AUTOMATISATION TEMPS DE CYCLE BUGS FLOW Pas d’initiative d’automatisation Seulement des tests manuels Pas d’Intégration Continue Collaboration entre TMA et QA est efficace Bonne gestion des bugs Release principale tous les 15 jours Release de bugs deux fois par semaine
  30. 30. OVERVIEW
  31. 31. NOTRE MÉTRIQUE AUTOMATISATION TEMPS DE CYCLE BUGS FLOW
  32. 32. NOTRE MÉTRIQUE AUTOMATISATION TEMPS DE CYCLE BUGS FLOW SOFTWARE ENGINEERS VS QA & TMA MEMBERS DETTE TECHNIQUE COMPLÉXITÉ DU PRODUIT
  33. 33. COMMENT RESTER LEADER ?
  34. 34. V L’usage du mobile augmente rapidement Vecteur de croissance MOBILE FIRST
  35. 35. BACKEND REFACTORING API-fication pour supporter la stratégie Mobile Maintenabilité Scalabilité
  36. 36. VISION PLATEFORME
  37. 37. VISION TECHNIQUE
  38. 38. API EXPOSURE LAYER
  39. 39. VISION ORGANISATION
  40. 40. QUELS TYPES D’ÉQUIPE PLATFORM TEAMS REFACTORING TEAMS INDUS TEAM
  41. 41. PLATFORM TEAM REFACTORING TEAM API EXPOSURE LAYER
  42. 42. PLATFORM TEAM PLATFORM TEAM REFACT. TEAM QA QA QA Tests sur la R7 Validation branche par branche OPS Déploiement Monitoring technique CYCLE DE DÉVELOPPEMENT Nouvelle fonctionnalité 1 branche par changement Tests Unitaires Code Review Tests sur la R7
  43. 43. CYCLE DE QUALITÉ PLATFORM TEAM PLATFORM TEAM REFACT. TEAM OPS QA Identification des bugs Qualification des bugs
  44. 44. PROD SERVER PROD SERVER PROD SERVER OPS R7 SERVER$_ QA DEV SERVER SOFTWARE ENGINEER S $_ PHP JS JAVA BAMBOO GITLAB
  45. 45. Bonne couverture de tests unitaires Bonne expérience de développement (CI, Code review) Initiative sur les tests fonctionnels ~350 scenarios comportementaux Plus d’équipe TMA Les équipes sont responsables de leurs backlogs de bugs Ajouter le plus rapidement possible de petits changements Environ 10 changements par jour TNR à chaque fin de journée AUTOMATISATION TEMPS DE CYCLE BUGS FLOW NOTRE MÉTRIQUE
  46. 46. LES IMPACTS DE CONWAY API EXPOSURE LAYER Règles business implémentées Les microservices ne correspondaient pas aux nouveaux besoins Ownershi p
  47. 47. API EXPOSURE LAYER
  48. 48. API EXPOSURE LAYER
  49. 49. EXEMPLE: BUG MANAGEMENT BUG PLATFORM TEAM REVAMP TEAM MICROSERVICES ? YESNO
  50. 50. EXEMPLE: BUG MANAGEMENT BUG MICROSERVICES ? MAYBEMAYBE PLATFORM TEAM REVAMP TEAM
  51. 51. AUTOMATISATION TEMPS DE CYCLE BUGS FLOW NOTRE MÉTRIQUE
  52. 52. AUTOMATISATION TEMPS DE CYCLE BUGS FLOW NOTRE MÉTRIQUE PROBLÈMES DE SYNCHRONISATION DIFFICULTÉ D’IDENTIFIER LES « ROOT CAUSES » PAS D’AMÉLIORATION
  53. 53. NOTRE ORGANISATION NOTRE ARCHITECTURE
  54. 54. API EXPOSURE LAYER 147 Routes 67 Components ALGOPAYMENTINTERACTPROFILE
  55. 55. SCOPE Tout les composants backend OBJECTIF Améliorer l’Ownership, leur vélocité, la maintenance COMBIEN? 4 équipes = 4 domaines fonctionnels ÉQUIPE PAR DOMAINE FONCTIONNEL
  56. 56. ALGOPAYMENTINTERACTPROFILE ORGANISATION
  57. 57. INDUS STAND UP OBJECTIF Comprendre les contraintes de chaque équipe afin d’améliorer les relations et développer un climat de confiance RELEASE Board commun
  58. 58. CYCLE DE DÉVELOPPEMENT Nouvelle fonctionnalité 1 branche par changement Tests Unitaires Tests Fonctionnels Code Review Tests sur la R7 Déploiement Monitoring ALGO INTERACT. PROFIL E CAIPI OPS QA
  59. 59. SOFTWARE ENGINEER S $_ SOFTWARE ENGINEER S PROD SERVER PROD SERVER PROD SERVER BAMBOOGITLAB KUBERNETES ARTIFACTORY
  60. 60. NOTRE MÉTRIQUE Les équipes sont responsables de leurs backlogs de bugs Amélioration de leurs capacités à prendre à compte les BUGS Toujours une bonne couverture de tests unitaires Intégration de Docker Bonne couverture de tests fonctionnels ~1400 scenarios comportementaux Flux de release optimisé Les équipe de développement sont autonomes AUTOMATISATION TEMPS DE CYCLE BUGS FLOW
  61. 61. Chart Title Created Resolved NOUVELLE ORGANISATION BUGS CRÉÉS VS BUGS RÉSOLUS
  62. 62. TAKE AWAY
  63. 63. DEV OPS OPS DEV DEV DEV DEV OPS DEV DEV DEV DEV OPS ÉVOLUTION DES ORGANISATIONS DEVOPS 2012 2014 2017
  64. 64. 2012 2014 2017 ÉVOLUTION DE LA QUALITÉ
  65. 65. IL N’Y A PAS DE RECETTE MAGIQUE POUR LE DEVOPS 1 A PART LA CONFIANCE
  66. 66. DEVOPS = UTILISATEURS 2
  67. 67. DEMING 3 STANDARDISATION Pratique des tests unitaires Petit changement > Petite correction Backlog de bugs géré par les équipes
  68. 68. POUR AMÉLIORER VOTRE QUALITÉ, AMÉLIOREZ VOTRE ORGANISATION 4
  69. 69. QUESTIONS?

×