A Fork in the Road
How to Improve a Running System
Live Migrations
Practical Case: Influencity
Conclusions
You are the new CTO of ACME, Inc.
You have to deliver results
Our old system is too slow, limited, crappy
We need the new system for last week
Start working now!
Work within the confines of the system
Build more stages on an unstable architecture
Work slows down on a crawl
"Rowing in chewing gum"
Throw everything away
The mythical rewrite
Stop new requirements for two years
Why will the second time be better?
Two million euros
25 people working for two years
New requirements were being implemented
in the old system
Catch-up was impossible
Database with ~100 tables
Renormalized to third normal form
Result: 400+ tables
Never saw production (thankfully!)
Debt allowed you to build things faster
Debts must be payed at some point
Use part of the team to repay debt
The only business where you can renovate a house...
While living in it!
And not be uncomfortable
Or three
Unit tests are great but expendable
Test backend code
Test APIs
Test frontend code
Make small, incremental changes
Intersperse with business improvements
Improve as you go along
Always leave the code better than it was
This code was here before I joined
This code must be here for some reason
This code must be awful because reasons
Graph your current architecture
Reduce the number of moving parts
Remove gears that do not run smoothly
Business needs its pound of flesh
Involve the whole team
Don't be afraid of manual work
Graph your current architecture
Reduce the number of moving parts
Remove gears that do not run smoothly
No need to understand old code perfectly!
But so easy to misuse
Don't be afraid to build if necessary
The most experienced devs should do infra
... But all the team should be involved
Allows you to make changes
Make incremental changes
Allow you to move seamlessly to the next state
Article (in Spanish)
Always add services
Never modify services
Never delete (while in use)
Atomic changes
Forward compatible
Must be reversible if necessary
Better without a fixed schema
Even better if avoided
Make everything backward compatible
Migration strategies (in Spanish)
Deployments every three months
"Stop the world" deployments
Painful data migrations
Backend: test controllers
Frontend: test to end tests
Manual tests
Deployments every other week
Rebuilt about half the platform
Improved every aspect
Continuous Deployment
5 ~ 10 deployments per day
Full frontend tests
Your team is your strength
Preserve backward compatibility
Migrate reversibly