new Chapter: one version to add, one to remove

content/books/things-i-learnt/_index.md

@@ -64,6 +64,7 @@ template = "section-contentless.html"
 		* [Not Just Function Composition, But Application Composition](application-composition)
 		* [Even for Application Composition, Start Stupid](app-composition-stupid)
 		* [Logs Are For Events, Not User Interface](log-events)
+		* [One Version To Add, One Version To Remove](add-then-remove)
 		* [Learn To Monitor](monitoring)
 * Community/Teams
 	* [A Language Is Much More Than A Language](languages-are-more)

content/books/things-i-learnt/add-then-remove/index.md

@@ -0,0 +1,33 @@
++++
+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.
+
+<!-- more -->
+
+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") }}

content/books/things-i-learnt/log-events/index.md

@@ -43,4 +43,4 @@ could have the values to try to figure out why it failed -- surely, logging
 why it failed also helps, but you know what I mean. This is an example of
 something that makes complete sense in logs, but not in user interfaces.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/app-composition-stupid", prev_chapter_title="Even for Application Composition, Start Stupid", next_chapter_link="/books/things-i-learnt/monitoring", next_chapter_title=Learn To Monitor"") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/app-composition-stupid", prev_chapter_title="Even for Application Composition, Start Stupid", next_chapter_link="/books/things-i-learnt/add-then-remove", next_chapter_title="One Version To Add, One Version To Remove") }}

content/books/things-i-learnt/monitoring/index.md

@@ -26,4 +26,4 @@ If you're not measuring, you'll have no idea.
 
 Also, "If you can not measure it, you can not improve it", as Lord Kevin said.
 
-{{ 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/languages-are-more", next_chapter_title="A Language Is Much More Than A Language") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/add-then-remove", prev_chapter_title="One Version To Add, One Version To Remove", next_chapter_link="/books/things-i-learnt/languages-are-more", next_chapter_title="A Language Is Much More Than A Language") }}