Continuous deployment makes releases non-events | Hacker News Reader

Continuous deployment makes releases non-events

startuplessonslearned.com

28 pointsashmaurya8 comments

I've adopted a strategy (on flexvite.com) where I test and push each change immediately, but periodically roll-up and announce a list of changes since the last roll-up.

I'm still calling these roll-up summaries 'releases' on the web site since people are familiar with that concept. I've received some positive feedback about using this approach. People like the immediacy of how quickly their feedback is addressed, but they also like being able to thumb through a summary of "What's new" since they last looked.

Here are some examples of those summary pages (they look just like release changelogs): 1. http://blog.flexvite.com/2009/12/17/flexvite-splat-release/ 2. http://blog.flexvite.com/2009/11/11/pow-10-new-flexvite-beta... 3. http://blog.flexvite.com/2009/10/12/14-new-flexvite-beta-imp...

The hardest thing for me is deciding where to draw the line and do an announcement of changes that have been released recently. I've considered announcing individual changes one-by-one as they happen on appropriate mediums (i.e.-twitter), but it seems like it would be a little spammy.

I have seen this work and work well on a large website that was simultaneously releasing in something like 20 different languages.

However that company was not in the USA. And I see no way to square that development philosophy with Sarbanes-Oxley, so publicly traded companies in the USA cannot do it.

But for an interesting example of a large well-known open source project with something like that development philosophy, check out http://clang.llvm.org/. The strategy scales better than you'd expect!

Can you explain the challenge Sarbanes-Oxley gives those publicly traded companies who want to do continuous deployment?

Publicly traded companies need to have carefully set up internal controls and audit trails on anything that can materially impact the company's financial position. If you are a web-based company, this would include the process of releasing to the website.

I do not see how to reconcile these controls and audits with the ability for developers to release main to production whenever they please. There may be a way to do it, but I don't see how.

You can have continual deployment without it being a developer free for all. Features get released as they are ready, there are enough developers that there's something that can go out on a regular basis. Which features those are and how they are implemented and the schedule is still determined by those driving the direction of the company.

The concrete example I was thinking of was, in your terms, "a developer free for all".

As in there were checks and balances, but fundamentally any developer could decide to release to production at any time for any reason. And typically this happened several times per day.

Incidentally my opinion is that rapid iterations in production and branching your code base are opposed decisions. Why? Because the whole point of rapid iterations to production is to make sure that your code and production are very, very close together. But the whole point of branching is to make it OK for your code and code in other places (including production) to be different.

This shows up in practice in the complexity and potential problems that you encounter while integrating branches. This pushes you towards a more lengthy verification/QA cycle, which pushes you away from rapid iterations to production.

I think a blog is the perfect medium for a periodic roll-up announcing new and noteworthy items. This allows you to highlight specific themes that can appeal to both current and border-line users.

I agree real-time tweets would be too spammy (unless you have a twitter account just for releases) but a community forum might be better for immediate announcements.

Great article Ash, I really enjoyed it :)

Reply on news.ycombinator.com