[LRUG] Deployment approach to rolling out huge changes

[Ed James (Alt)]

This has been really useful, so thanks to all. Based on the recent replies, it's reassuring to know that we are already doing some of the things people have suggested:

- feature flagging: we already do this with the ability to flag users as both alpha/beta testers, allowing early access to incomplete features. This works very well for us, but is generally for smaller features and enhancements, or brand new features.

- continuous deployment: as mentioned in a previous reply, we deploy to production every day Mon-Thurs, sometimes several times in a single day. For this particular feature, our database schema is already well ahead of the code, with no destructive changes having been made (e.g. column deletion). So our database is basically prepped and ready for the new feature. The schema changes are thankfully the easy part. Data and code changes less-so.

Unfortunately the feature in question involves a fundamental change to our system, one which affects almost every part of the codebase in that it changes a key relationship between our models. Because it also changes the way we charge users it's not something that can be easily "phased in" to our production environment (we are not changing our prices, but rather how we allocate the charges).

Anyway, I think there is a wealth of information in this post already, so I will be sure to reply with details of the approach we decide to take once we've rolled out.

Thanks again all! 

-- 
Ed James (Spam)
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Sunday, 9 September 2012 at 23:54, Glenn Gillen wrote:

> 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.
> 
> Adam Wiggins, CTO and co-founder, gave a high level run through of some of our approaches at Waza earlier this year: http://www.slideshare.net/adamwiggins/waza-keynote-idea-to-delivery
> 
> The techniques start at slide 47. To try and give you the digest version here, the first 3 are the most relevant:
> 
> 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
> Continuous Deployment: Keep pushing those small bites out, stop stacking up bunches of commits over weeks
> 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
> 
> So definitely a +1 for feature flags. They've become a really useful part of my workflow,
> 
> G
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120910/bf1bb27a/attachment-0003.html>