4 ms·
For some hairy stuff that require live data you can also reverse the practice: call both yet return the old one, and gather data in production before switching.
by lloeki 9y ago
For some hairy stuff that require live data you can also reverse the practice: call both yet return the old one, and gather data in production before switching.
Obviously this does not work for side-effectful methods (beware of caches!).
- dotancohen 9y agoI'm interested in what fields you would use this methodology. Machine learning? In most fields we have a sample of known input vectors, including edge cases, that map to known outputs. A unit test is enough to test these methods with different implementations.
- karlding 9y agoAn example of when you might use this is when you're cutting over to a new service, and you want to validate that the new service behaves the same way as the old one before transitioning all the traffic to the new service. In order to build confidence in the new service, you can assert that the expected output is the same, and raise alerts when there is an inconsistency. This incremental rewrite approach allows you to slowly replace pieces of an application with a new service and helps prevent regressions in behaviour. Or consider when you're performing a database migration (on large databases) with 0 downtime. Typically this involves something like: 1. Dual Writing: Create 2 tables and write to both and keep them in sync (by duplicating new data, and back-filling old data) 2. Update read paths: Change all code to read from the new table, and validate that the data being read is consistent with the old table. You can use a library like Scientist [0] to validate that the reads are the same. 3. Update write paths: Change all code to write to the new table (and raise alerts if the old path is exercised) 4. Deleting old data: Remove code and data that relies on the old data model [0] https://github.com/github/scientist https://github.com/github/scientist
- dotancohen 9y agoI see, thank you.