Quality issues in a SOA migration context

Depuis plusieurs années, la tech BlaBlaCar travaille sur une refonte technique en service, laissant derrière elle un monolithe d'un million de lignes de code.

On parle souvent des problématiques techniques, des challenges d'architecture logicielle, j'ai decidé de me concentrer sur un sujet moins commun : gérer le legacy. Je vais aborder les process agiles qui nous ont permis de conserver une parfaite maitrise d'une stack technique en cours disparition.

Transcript

1. Edouard Durieux Software Engineer @BlaBlaCar
2. 20€ 20€ 80€ 20€ 20€
3. Quality issues in a SOA migration context
4. Our quality tools Decent test suites State of the art monitoring and logging stack Dogfooding for employees Great QA team
5. We are in 22 countries
6. Over 70 million members and growing
7. monolith services Our Tech story
9. Our tech today 1 1 million LoC PHP monolith Front, Web, Backoffice, API ... everything ! PHP/Java/Go services Trip, Payment, Emailing, Gateways Smaller workloads Workers, crons, commands 30 300 + +
10. 80 - 100 Engineers Our tech today backend/service teams 5 frontend/mobile teams ops team data/BI team 3 1 1
11. 50% Business 50% SOA migration
12. How do we maintain the monolith ?
13. We don’t !
14. A new bug introduced at every change Existing issues with the Core components Scaling issues Poor reliability A good amount of legacy code
15. Bad UX for our members
16. Let’s build a task force
17. Let’s build a task force Define the mission Gather the team Build the backlog Setup a space Choose an agile methodology
18. The mission Backend and frontend bugs out of scope of other teams Product/Business rules simplification Tech evolutions
19. Gather the team
20. Backend engineer Full time Backend engineer Full time Backend engineer Ad-hoc Backend engineer Ad-hoc Manager Frontend engineer Ad-hoc
21. Backend engineer Full time Backend engineer Full time Backend engineer Ad-hoc Backend engineer Ad-hoc Manager Frontend engineer Ad-hoc 2-weeks rotation
22. Build the backlog Is it really important ? Does is belong to the team ? Does the criticity makes sense ? Is it reproducible ?
23. Setup a space
24. Choose an agile methodology
25. Learnings
26. Operational teams are awesome
27. Full time engineers is a great choice
28. Full time engineers is a great choice but take care of their focus
29. More bugfixs = more bugs reported
30. Everything cannot be fixed
31. The rotation system is great
32. The rotation system is great but hard to manage
33. It’s not perfect for developers
34. It still doesn’t make you proactive