Error converting content: marked is not a function
#+TITLE: Tech / Branch By Abstraction * #+title: Tech/Branch By Abstraction * Idea for Auth Project at JOKR ** Use branch by abstraction + create a BFF to abstract for ever? ** Codifying the obvious. As some steps can be missed -- like removing the abstraction -- most experts err here. Not having an abstraction -- non-experts err here. Replacing tech debt with tech debt. *** Add pointer to #badabstractions here -- from that tweet thread * Benifits ** Go live with making devs miserable ** Cheaply pause and resume ‘migrations’ ** Cancellation of a project is still cheap * Sources ** https://trunkbaseddevelopment.com/branch-by-abstraction/ *** Branch by Abstraction is a set-piece technique to effect a ‘longer to complete’ change in the trunk. Say a developer (or a pair of developers), has a change that is going to take five days to complete. There could easily be pressure to create a branch for this - somewhere that can be unstable for a period of time before it completes (and gets merged back somewhere). *** Rules: 1. There are also a lot of developers already depending on the code that is subject of the ‘longer to complete’ change, and we do not want them to be slowed down in any way. 2. No commit pushed to the shared repository should jeopardize the ability to go live *** Ideal steps **** Introduce an abstraction around the code that is to be replaced, and commit that for all to see. If needed, this can take multiple commits. None of those are allowed to break the build, and all of them could be pushed to the shared repository in order, and as done. **** Write a second implementation of the abstraction for the to-be-introduced code, and commit that, but maybe as ‘turned off’ within the trunk so that other developers are not depending on it yet. If needed, this can take multiple commits as above. The abstraction from #1 may also be occasionally tweaked, but must follow the same rule - do not break the build. **** Flip the software ‘off’ switch to ‘on’ for the rest of the team, and commit/push that. **** Remove the to-be-replaced implementation **** Remove the abstraction *** Car Wheel example - could use this *** Documented case is ThoughtWorks' Go CI-daemon. They changed an Object-Relational mapping library (for persistence), while not slowing down teammates development activities (rule 1), and not jeopardizing the ability to go live (rule 2). Going from “iBatis” to “Hibernate” for a bunch of reasons, was their plan. They: **** Introduced an abstraction around the classes/components using iBatis directly, and ensured that all classes/components indirectly referring to iBatis were changed to refer to the abstraction instead. **** Wrote a second implementation of the abstraction, introducing Hibernate to the codebase, perhaps tweaking the abstraction where needed. **** Did a tiny commit that turned on Hibernate for all teammates. **** Removed iBatis, then the abstraction and the on/off old/new switch. ** https://www.branchbyabstraction.com/index.html *** It is 1931 in our software alternate universe, and the Empire State Building is pretty much complete, but news has come in that "30 Rock" (a building being planned nearby in New York City) is going to have wheels. Given that, the owners have asked the architects to redesign the Empire State Building to have caterpillar tracks. Not only that, but the switching from a fixed foundation to the tracked design will happen concurrently with the floor-by-floor finishing and tenants moving into the lower floors that are already finished. *** Lead craftspeople (still-coding architect equivalents) introduce an abstraction at a critical layer in the building that will be where the static foundation is swapped out, and the caterpillar tracks swapped in. That abstraction is put in place in what feels like the blink of an eye, but in reality took a day or so to prepare in a parallel universe. Before, during and after the placement of the abstraction all workers carried on at full speed and were barely aware that the abstraction was placed in the building (in the ceiling of floor 5), if that was not implicit from 'blink of an eye' as mentioned. *** A caterpillar track for the building is assembled in parallel. Methodically so, and tested as it is being made. Testing includes ensuring it fits the abstraction and only involved two workers (developer equivalents). *** Everyone working on/in the existing building carry on as normal with the on-traditioanl-foundations design, and are unaware that that caterpillar tracks are bing made and indeed tested ahead of deployment. *** In what appears to be the blink of an eye (again) the caterpillar tracks are put in place and the old floors 1-5 are taken out. As before this was prepped in a parallel universe, and flipped over via a toggle with all workers carrying on at full speed. Woe betide any workers still working on floors 1-5 while that happened, but all workers on the the 97 floors were all safe. *** Finally, when everyone is sure that the building isn't going to go back to the on-foundations variant (which would be easy), the abstraction and former floors 1 to 5 are destroyed, and to all intents and purposes it was as if they never existed. To those in the building at the time, as before, this was instantaneous with no bumps/tremors or flickering of lights. *** https://www.branchbyabstraction.com/empire_crawler_a.jpg *** *** The choice of old or new ShoppingCart technology would only be determined at boot time. Some development teams might make that a compile-time fixed choice instead of boot time. *** You will go properly live with a toggle flip, after testing and a signoff in UAT. You'll have practiced flipping that toggle back to "old" in UAT after an initial deployment to "new". *** Maybe immediately after that, but it could also be after another couple of weeks, you'll remove the abstraction itself too(commit/push/go-live) *** As previously mentioned, this last is the characterizing difference to any other use of abstractions in the codebase. Well, versus the terrible decision to do the lengthy non-functional change on a branch and merge back to trunk/master when complete. Those are often late, and risk being canceled part complete. Or they are super stressful at the time of merge. **