Retour d'expérience sur la migration de la fonctionnalité de virement sur la partie web de Boursorama Banque.

1. 1

2. 2
Comment faire une
migration sur une
fonctionnalité critique ?

3. Mathieu DESNOUVEAUX
Développeur
@mdesnouveaux
3

4. Arnaud LAHAXE
Architecte applicatif
@arnaud_lahaxe
4

5. 5
Boursorama Banque

6. Boursorama
▪ Leader de la banque en ligne en France
▪ 1er Portail d’information boursière en France
▪ La banque la moins chère depuis 11 ans
▪ 99% des démarches en ligne
▪ 2 millions de clients
▪ 20% de nouveaux clients par an
▪ Guichet unique pour toute l’activité client
6

7. Environnement technique (partie WEB)
▪ 1 brique du SI boursorama
▪ 3 sites web principaux
▪ 4 applications mobiles
▪ 8 barbus / 50 développeurs
▪ > 200 000 lignes de code modifiées par mois
▪ > 1400 pull request / mois
▪ > 100 livraisons / mois
7
À Nancy depuis 21 ans

8. Le virement chez Boursorama (partie WEB)
▪ Intermédiaire
▪ Entre le client et le partenaire qui transfert les fonds
▪ Orchestrateur entre plusieurs partenaires
▪ Fonctionnalité large
▪ > 10 types de virement
▪ Au coeur d’autres fonctionnalités
8

9. Volumétrie virement
▪ De 50 000 à 100 000 virements par jour
▪ > 1 virement par seconde
▪ Pics par période (week end, fin de mois)
9

10. Pourquoi migrer le virement ?
▪ Ajout du virement instantané
▪ Obligation réglementaire
▪ Évolution de l’offre clientèle
▪ Rembourser la dette technique
▪ Simplification des évolutions futures
10

11. 11
Avant

12. Beaucoup d’historique
12
▪ Fonctionnalité ancienne
▪ Classe créée le 24 octobre 2006
▪ Partenaires disparus
▪ Code ancien, travers anciens
▪ Classes monstres (environ 4000 lignes)
▪ Code métier et contrôleur mélangés

13. Beaucoup de règles
13
▪ Règles métiers
▪ Compatibilités de comptes
▪ Offres commerciales
▪ Réglementations juridiques
▪ Fraude et sécurité

14. 14
Méthodologies de migration

15. Les différentes méthodes pour faire une migration
15
1- Migration type “big bang"

16. Les différentes méthodes pour faire une migration
16
2- Migration progressive
Réécriture de code vieux de 17 ans - Anna Filina

17. Les différentes méthodes pour faire une migration
17
3- Migration type Friends & Family

18. Les migrations chez Boursorama
18
▪ Une méthodologie adaptée au projet
▪ Des cycles de dev courts
▪ Quelques règles :
▪ Pas de refacto dans une branche de projet
▪ 5 petites PRs c’est mieux que 1 grosse PR
▪ La rétro-compatibilité est obligatoire
▪ …

19. Les migrations chez Boursorama
19
▪ Pour les gros projets on mixe :
▪ Migration progressive
▪ Migration type Friends & Family

20. Duplication des jeux de tests
20
▪ Enrichissement des tests sur l’ancien code
▪ Création des tests sur le nouveau code
▪ Les cas normaux
▪ Les cas spécifiques
▪ La rétro-compatibilité
▪ 1 bug détecté = 1 nouveau test

21. 21
La suite de tests

22. 22
Migration du code

23. Analyse du legacy
23

24. Analyse du legacy
24

25. Refactorisation
25
▪ Indentation hell
▪ 6 niveaux et parfois plus
▪ Des répétitions dans les else
▪ Code illisible
▪ 1 ligne métier
▪ 18 lignes “inutiles”
▪ Détection et correction de bugs complexes

26. Refactorisation
26
▪ Refactorisation dans la méthode
▪ Exit early
▪ Détection et correction de bugs plus facile
▪ Apparition de blocs logiques

27. Refactorisation
27
▪ Extraction des blocs logiques
▪ Petites méthodes
▪ Facilement testables
▪ Responsabilité unique
▪ Pas de changement de signature

28. Évolution de l’architecture legacy
28
Action
Match
Action
Match
Action
Match
Action
Match
Action
Match
PRE-TRANSFER
Action
Match
Action
Match
Action
Match
Action
Match
Action
Match
TRANSFER
Action
Match
Action
Match
Action
Match
Action
Match
Action
Match
POST-TRANSFER

29. Architecture modulaire
29
Matching
Type A
Match Pre Post
Transfer
Type A
Process
Type B
Match Pre Post
Transfer
Type B
Type C
Match Pre Post
Transfer
Type C
Type D
Match Pre Post
Transfer
Type D
Type E
Match Pre Post
Transfer
Type E

30. Architecture modulaire
30

31. 31
Livraison du code

32. Livraison continue
32
▪ Partage avec les autres projets en cours
▪ Livraison “au plus tôt”
▪ Code livré mais pas forcément encore utilisé en production
▪ Petites Pull request compréhensibles
▪ Impacts “limités” en cas de régression

33. Feature flags
33
Le pattern « feature flag » permet d’activer et désactiver des fonctionnalités
directement en production, avec ou sans re-livraison de code.
“ “

34. 34

35. Client
Login: 96064416
Ville: Paris
IP: 109.190.253.15
...
Version A – Pour les
logins finissant en 6
Version B – Pour les
logins ne finissant pas
en 6
Feature flags
Client
Login: 46763419
Ville: Nancy
IP: 96.145.135.36
...

36. Version A – Pour les
logins finissant en 6
Version B – Pour les
logins ne finissant pas
en 6
36
Feature flags
Client
Login: 96064416
Ville: Paris
IP: 109.190.253.15
...
Client
Login: 46763419
Ville: Nancy
IP: 96.145.135.36
...

37. 37

38. Prod-cachée et rétrocompatibilité
38
APIs du virement
Site client
App Android v6.3
Contrôleur
Ancienne
version
Nouvelle
version
App Android v6.2
App Android vX.x
App iOS v6.3
App iOS v6.2
App iOS vX.x
...
Pas de BC dans les inputs / outputs des API
FF
++
++

39. Ouverture par vagues
39
0,000025%
5 personnes du projet
J 0

40. Ouverture par vagues
40
1%
20k clients
J +3

41. Ouverture par vagues
41
10%
200k clients
J +4

42. Ouverture par vagues
42
100%
2m clients
pendant 5 minutes
J +7

43. Ouverture par vagues
43
20%
400k clients
J +7

44. Ouverture par vagues
44
50%
1m clients
J +8

45. Ouverture par vagues
45
70%
1.4m clients
J +9

46. Ouverture par vagues
46
100%
2m clients
définitivement
J +10

47. Ouverture par vagues

48. Monitoring avancé
48
▪ Volume global de virement
▪ Ancien et nouveau
▪ Volume par type de virement
▪ Pourcentage d’erreur par type
▪ Pourcentage d’erreurs des partenaires
▪ Comparaison à J-7
▪ Temps moyen nécessaire pour faire un virement

49. Monitoring avancé
49
▪ Affichage des dashboards dans l’open space
▪ Monitoring système (ping, ssl check, heartbeat…)
▪ Vérification systématique les matins par un humain

50. 50
Travail post livraison

51. rm -fr *
51
▪ Suppression de code mort
▪ Livrer le plus vite possible du code remplacé
▪ Suivre les breaking change
▪ Suppression indépendante

52. Après migration
52
▪ Run
▪ Visualisation et suivi des différents virements
▪ Configuration plutôt que programmation
▪ Traitement facilité
▪ Évolution
▪ Ajout d’un nouveau type de virement en peu de temps
▪ Ajout de nouvelles règles et contraintes centralisées
▪ Plus simple à expliquer à un nouveau dev

53. Post-mortem
53
▪ Quelques anomalies facilement corrigées
▪ Rétrocompatibilité lourde à assurer
▪ Maintenance durant le temps de migration
▪ Code modulaire donc moins linéaire
▪ documentation / présentation / formation
▪ création d’outils

54. 54
Questions ?

55. 55