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

1. REX Meetic,
QUALITÉ ET ORGANISATION

2. a
JORIS CALABRESE
Director Of Engineering
User Product Tribe
@jorisCalabrese

3. JORIS CALABRESE
Backend Software
Engineering Manager

4. TRANSFORMATION DIGITALE

5. TRANSFORMATION DIGITALE

7. Nous devons nous focaliser sur
l’EXPÉRIENCE UTILISATEUR

8. COMMENT MESURER ?

9. LOI DE CONWAY

10. Organizations which design systems are
constrained to produce designs which are
copies of the communication structures of
these organizations
Melvin Conway – 1968

11. ORGANISATION
LOI DE CONWAY

12. DEVOPS?

13. COMMENT MESURER ?

14. ET SI LA QUALITÉ…

15. QUALITÉ
=
GESTION DE RISQUES

16. QUALITÉ
TEMPS DE CYCLE
BUGS FLOWAUTOMATISATION
TimetoUser
TestsUnitaires
TestsFonctionnels
TestsExploratoires
Bugscreation
Vs
Bugsresolved

17. AUTOMATISATION : POURQUOI ?
DESIGN
PO REVIEW
R7 TESTING
PRODUCTION
COÛT DE CORRECTION D’UN BUG

18. AUTOMATISATION
CI

19. TEMPS DE CYCLE : POURQUOI ?
DÉPLOYER
NE DOIT PAS ÊTRE
UN ÉVÉNEMENT

20. TEMPS DE CYCLE
CHANGEMENTS IMPORTANTS
RAREMENT
PEU DE CHANGEMENTS
SOUVENT

21. BUGS FLOW: POURQUOI?

22. BUGS FLOW
CREATED BUGS VS
RESOLVED BUGS

23. MATURE
NOVICE
COMMENT MESURER ?
AUTOMATISATION
TEMPS DE CYCLE BUGS FLOW

24. HISTOIRE DE MEETIC

25. MEETIC CROÎT…
COMME TOUTES LES
STARTUPS À SUCCÈS
INVEST IN
STARTUP
NEW
FEATURE
S
ATTRACT
MORE
USERS
IMPROVE
REVENUE

26. MEETIC
LEADER EUROPEEN DU DATING EN LIGNE

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

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

29. QA
SOFTWARE
ENGINEER
S
R7
SERVER
RELEASE
MANAGER
PROD
SERVER
DEV
SERVER
PROD
SERVER
PROD
SERVER
PUBLIO

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

31. OVERVIEW

32. NOTRE MÉTRIQUE
AUTOMATISATION
TEMPS DE CYCLE BUGS FLOW

33. NOTRE MÉTRIQUE
AUTOMATISATION
TEMPS DE CYCLE BUGS FLOW
SOFTWARE ENGINEERS
VS
QA & TMA MEMBERS
DETTE TECHNIQUE
COMPLÉXITÉ DU PRODUIT

34. COMMENT RESTER LEADER ?

35. V
L’usage du mobile
augmente rapidement
Vecteur de croissance
MOBILE FIRST

36. BACKEND
REFACTORING
API-fication pour
supporter la stratégie
Mobile
Maintenabilité
Scalabilité

37. VISION PLATEFORME

39. VISION TECHNIQUE

40. API EXPOSURE LAYER

41. VISION ORGANISATION

42. QUELS TYPES D’ÉQUIPE
PLATFORM
TEAMS
REFACTORING
TEAMS
INDUS
TEAM

43. PLATFORM TEAM
REFACTORING
TEAM
API EXPOSURE LAYER

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

45. CYCLE DE QUALITÉ
PLATFORM
TEAM
PLATFORM
TEAM
REFACT.
TEAM
OPS
QA
Identification des bugs
Qualification des bugs

46. PROD
SERVER
PROD
SERVER
PROD
SERVER
OPS
R7
SERVER$_
QA
DEV
SERVER
SOFTWARE
ENGINEER
S
$_
PHP
JS
JAVA
BAMBOO
GITLAB

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

48. LES IMPACTS DE CONWAY
API EXPOSURE LAYER
Règles business
implémentées
Les microservices ne
correspondaient pas
aux nouveaux
besoins
Ownershi
p

50. API EXPOSURE LAYER

51. API EXPOSURE LAYER

52. EXEMPLE: BUG MANAGEMENT
BUG
PLATFORM TEAM REVAMP TEAM
MICROSERVICES ?
YESNO

53. EXEMPLE: BUG MANAGEMENT
BUG
MICROSERVICES ?
MAYBEMAYBE
PLATFORM TEAM REVAMP TEAM

54. AUTOMATISATION
TEMPS DE CYCLE BUGS FLOW
NOTRE MÉTRIQUE

55. AUTOMATISATION
TEMPS DE CYCLE BUGS FLOW
NOTRE MÉTRIQUE
PROBLÈMES DE SYNCHRONISATION
DIFFICULTÉ D’IDENTIFIER
LES « ROOT CAUSES »
PAS D’AMÉLIORATION

56. NOTRE ORGANISATION
NOTRE ARCHITECTURE

57. API EXPOSURE LAYER
147 Routes
67
Components
ALGOPAYMENTINTERACTPROFILE

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

59. ALGOPAYMENTINTERACTPROFILE
ORGANISATION

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

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

63. SOFTWARE
ENGINEER
S
$_
SOFTWARE
ENGINEER
S
PROD
SERVER
PROD
SERVER
PROD
SERVER
BAMBOOGITLAB KUBERNETES
ARTIFACTORY

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

65. Chart Title
Created Resolved
NOUVELLE
ORGANISATION
BUGS CRÉÉS VS BUGS RÉSOLUS

66. TAKE AWAY

67. DEV
OPS OPS
DEV DEV
DEV DEV
OPS
DEV
DEV DEV DEV
OPS
ÉVOLUTION DES ORGANISATIONS DEVOPS
2012 2014 2017

68. 2012 2014 2017
ÉVOLUTION DE LA QUALITÉ

69. IL N’Y A PAS DE
RECETTE MAGIQUE
POUR LE DEVOPS
1
A PART LA CONFIANCE

70. DEVOPS =
UTILISATEURS
2

71. DEMING
3
STANDARDISATION
Pratique des tests unitaires
Petit changement > Petite correction
Backlog de bugs géré par les équipes

72. POUR AMÉLIORER VOTRE QUALITÉ,
AMÉLIOREZ VOTRE ORGANISATION
4

73. QUESTIONS?