Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Parallel run with reconciliation

Published : Oct 28, 2020
NOT ON THE CURRENT EDITION
This blip is not on the current edition of the Radar. If it was on one of the last few editions, it is likely that it is still relevant. If the blip is older, it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the Radar. Understand more
Oct 2020
Trial ?

Replacing legacy code at scale is always a difficult endeavor and one that often benefits from executing a parallel run with reconciliation. In practice, the technique relies on executing the same production flow through both the old and new code, returning the response from the legacy code but comparing the results to gain confidence in the new code. Despite being an old technique, we've seen more robust implementations in recent years building on continuous delivery practices such as canary releases and feature toggles and extending them by adding an extra layer of experimentation and data analysis to compare live results. We've even used the approach to compare cross-functional results such as response time. Although we've used the technique multiple times with bespoke tooling, we certainly owe a nod to GitHub's Scientist tool, which they used to modernize a critical piece of their application and which has now been ported to multiple languages.

Download the PDF

 

 

 

English | Español | Português | 中文

Sign up for the Technology Radar newsletter

 

Subscribe now

Visit our archive to read previous volumes