
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Somehow missed this thread, apologies for being a bit late to the party. At Heroku we do what we can to avoid rolling out "huge changes", because they create huge problems.<div><br></div><div>Adam Wiggins, CTO and co-founder, gave a high level run through of some of our approaches at Waza earlier this year: <a href="http://www.slideshare.net/adamwiggins/waza-keynote-idea-to-delivery">http://www.slideshare.net/adamwiggins/waza-keynote-idea-to-delivery</a></div><div><br></div><div>The techniques start at slide 47. To try and give you the digest version here, the first 3 are the most relevant:</div><div><br></div><div>Deploy from day 1: No matter how big the changes are, there are smaller bites you can take. Even if there is nothing immediately user facing, you can start getting schema changes out now without breaking your existing functionality</div><div>Continuous Deployment: Keep pushing those small bites out, stop stacking up bunches of commits over weeks</div><div>Feature Flags: Being able to opt users in and out of features is incredibly powerful. If you notice a bug, performance characteristics that need to be improved, or any other problem you can have users revert to the known good code in an instant without a deployment. Alternatively you can gradually ramp up usage on a schedule that suits you</div><div><br></div><div>So definitely a +1 for feature flags. They've become a really useful part of my workflow,</div><div><br></div><div>G</div></body></html>