Chapter 9. Refactoring Live Features
In Chapter 8, you saw how we can leverage feature toggles to deploy features to production little by little, even across different components of distributed systems. When we change features that are already live, however, we can’t rely on the behavior being hidden under a toggle, yet to be seen by anyone. The stakes are much higher when the code we are working on is already being enjoyed by many users, who don’t want any disruptions to their routine. That is why, when rearchitecting under continuous deployment, it is fundamental to deploy small and backward-compatible changes at all times.
Most refactoring tasks are relatively simple, usually involving only one or two codebases. I am sure that you can manage those simple backward-compatible changes on your own, without further help from this book. Therefore, in this chapter we will explore more interesting scenarios.
At least once in the life cycle of most products we are faced with changes that are so complex that they pull the metaphorical rug out from under the feet of our domain and require changing a great portion of our codebase. In such situations, it can be tempting to be afraid of continuous deployment and take the “safer” route of making a big ball of changes, parking it in preproduction for manual testing, and then deploying it all at once.
That is why I will showcase a complex refactoring example (from our Groceroo application, of course). This will allow you to see for yourself ...
Get Continuous Deployment now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
