Chapter 10. Data and Data Loss
In Chapter 9, you saw how to refactor live functionality under continuous deployment. Through the use of the expand and contract pattern, we can plan out our deployments across different codebases in such a way that all changes remain backward compatible. Backward compatibility ensures that all the features relying on the refactoring will keep running flawlessly for users, even though the code itself is still a work in progress. However, this only holds true until our refactoring crosses the contract boundary with a database or any state store. The expand and contract pattern is not enough on its own to safely refactor live databases without loss of service or data.
Let’s revisit the example from Chapter 9, where our objective was to switch the product ID referenced in the basket table. In that scenario, we wanted to transition from using one product ID to another. To accomplish this, we implemented a temporary two-column system that allowed both IDs to coexist until all clients fully adopted the new one.
On the surface, this approach may seem foolproof. However, when it comes to databases and continuous deployment, we need to consider that any temporary change we make will impact the flow of data into our databases. This affects what ends up persisted (or more importantly, not persisted) between deployments. That is why we had to introduce an extra data synchronization step (which I will explain in much more detail in this chapter).
This issue isn’t ...
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.
