1.6 KiB
+++ title = "Things I Learnt The Hard Way - One Version To Add, One Version To Remove" date = 2019-07-30
[taxonomies] tags = ["en-au", "books", "things i learnt", "versions", "upgrades"] +++
A lot of things change during development. One day you need a field, another day that field may be completely different. For those cases, use one version to add the new field and another to remove.
You have a database with a lot of customers and their ID is numerical. But for some reason, they now need to be strings. Instead of changing the field type and doing a whole migration, make a deploy with a new field, in which you'll keep the old and the new format going on and, in the next release, remove the old field. No downtime. You can even run the migration while the system is up, since the new field won't be used.
(I'm simplifying the problem a lot here, 'cause the customer would have references all around your system, but you get the point, right?)
I had a problem in which we store the link for an object directly in the backend (we shouldn't, that's a frontend problem, but that's a discussion for another time); our interface is changing and so should the link. If we did a change in the link directly, that would mean the backend would have to be deployed at the same time as the new interface; by adding the new link format in another field, we can deploy the backend easily without breaking the current system.
{{ chapters(prev_chapter_link="/books/things-i-learnt/log-events", prev_chapter_title="Logs Are For Events, Not User Interface", next_chapter_link="/books/things-i-learnt/monitoring", next_chapter_title="Learn To Monitor") }}