

Continuous deployment makes releases non-events - ashmaurya
http://www.startuplessonslearned.com/2010/01/case-study-continuous-deployment-makes.html

======
mpstx
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...](http://blog.flexvite.com/2009/11/11/pow-10-new-flexvite-beta-
improvements/) 3\. [http://blog.flexvite.com/2009/10/12/14-new-flexvite-beta-
imp...](http://blog.flexvite.com/2009/10/12/14-new-flexvite-beta-
improvements/)

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.

------
btilly
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!

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

~~~
btilly
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.

~~~
thwarted
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.

~~~
btilly
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.

------
ashmaurya
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.

~~~
DTrejo
Great article Ash, I really enjoyed it :)

