Qui a déjà travaillé sur une migration technique ?
Qui aime faire des migrations technique ?
Un code complexe, ancien, plein de hacks
Plus aucuns dev de l'époque
Antérieur à la mise en place de CI
+20% de client par an
80 devs qui ajoutent des fonctionnalités en continue
Login/ bourse/ ...
Un impact sur les fonctionnalités bourse -> donc dépendant de l'actualité
Plusieurs refontes majeurs à mon actif:
- Ré-écriture de l'espace client
- Création d'un outil de feature flag en 2016 orienté performance (500 en prod/ 32ms/ 10k <> 150k hit/ secondes)
- Refonte du virement, conférence AFUP
Gamer FPS
Passioné de domotique
Login
Bourse
3DS
- Bus factor
- Rien de typé car codé initialiement en PHP 4
- Globalement illisible
- L'analyse statique n'est pas possible
Impacts:
- Perte d'accès au site
- Impossibilité de consulter les comptes bourses
- Impossibilité de passer des ordres en bourse
- Corruption de données
- Ordres erronées
Solutions:
- Des tests
- Génération d'audit
- Mise en cache
- Gestion des sessions
- Injection de dépendence de Symfony
- Pattern façade pour simplifier la migration
- Une ou plusieurs grosses PR sans changements de logiques
- Cette étape permettra de limiter les diffs dans les PRs
- Client HTTP de SF
- SF ou JMS ?
Le choix de la techno est engageante pour plusieurs années
-> Tenter d'isoler les dépendances dans le code pour pouvoir les changer
- La documentation, les dockblocs,... sont faux
- Un gros morceau/ complexe
- +/- 10 jours
- Uniformisation du code généré
- Force la complétude des tests
Trump/ noel/ congés/ guerres ...
Boucles de rétroaction
Livraison sans intéruption de service
Pas de feature flag car un trop grand nombre, complexe à gérer
- Il n'y a plus d'ordres qui passent
- Le passage d'ordre a une erreur à la première étape
- On a mal configuré le serializer qui décode le JSON du partenaire sur un attribut
Calmement, Se remémorant chaque instant
Leçons:
- Le contexte est important
- Le rollback est ton amis