We've used this extensively at my work and it has been great. As someone else pointed out it's a bit tricky if the code isn't idempotent. We used this as part of a data migration project and for writing we ran the experiment 100% of the time and read back the result to check it was correct - a bit of a performance impact but nothing that was noticeable. One super useful extension we've made to the gem is to have it update Prometheus metrics so you can easily see how often your experiment is showing that the candidate is different from the control.
I’ve used this gem to remove a Rails Model that was heavily tangled and used in production. It had a bit of a learning curve, such as seeing how errors get handled in try {} blocks, but really nice otherwise when doing the equivalent of open heart surgery.
This is pretty cool, but in my experience critical path code generally has side effects and most code is not idempotent. That is to say it may not be safe or feasible to run the old and new code in parallel, without some special considerations. Think bidding on a auction item or transferring a bank balance.
Sure but IMO most code can and should be structured to decouple the side effect from the logic that is being replaced.
Example in the transferring a bank balance, you have some storage DB you interact with, but that is an abstraction and when you run the dry run of the new code you can have an implementation that just does verification on the data from the real implementation.
Anyways, it does take discipline and effort, but you can still safely make changes in this manner.
I wrote one (https://github.com/boxed/scientist) as I found the existing ones very complicated and that just gives me a bad feeling. Since I'm the author of mutmut (https://github.com/boxed/mutmut), I also made sure my implementation was 100% mutation tested before I used it in production.
