

How Digg does continuous deployment - malyk
http://about.digg.com/blog/continuous-deployment-code-review-and-pre-tested-commits-digg4

======
snprbob86
As awesome as continuous deployment is, it is a large overhead to get going.
This is especially true if you don't have high test coverage already. For
smaller teams and projects, you can simply remove the _automatic_ step. Invest
some time in packaging and deploying your product in a repeatable, reliable
way. And don't re-invent the wheel, really investigate the standard tools for
your language and platforms.

~~~
pacemkr
If the point of continuous deployment is to get rid of deployment pain, it
fails miserably.

I've tried to do continuous deployment for a smaller, one man, project and it
was effectively impossible. It was too much infrastructure to maintain for one
person.

The real question is does it save time at the end of the day? The overhead to
set it up and keep it going is astronomical.

~~~
j_baker
For a larger, more complex project, it's a godsend though. Not just in terms
of saving time, but also in terms of preventing errors that happen when you do
things manually.

------
zavulon
What about the user acceptance testing stage? The way the process was
described in the article, looks like the process is code -> run unit tests ->
run automated tests -> code review -> deploy. I may be missing something, but
at which point are the features actually in front of the eyes of the business
users who requested them?

Unless programmers are business users themselves (which in Digg's case, I
think is highly unlikely), it's very risky for business users who requested
the features to first see them in production. Even with all the tools that
they have, the chance of simple misunderstanding and "No-no, that's not what I
meant!" is always there. That's why I think there should always be a user
acceptance stage, where users get to play around with the release (ideally,
with data as close to production one as possible), and 'ok' the release for
production from there.

Also they didn't mention QA at all. Unless QA are the ones that are writing
Selenium tests at the same time devs are coding the feature.

~~~
shykes
The whole point of continuous deployment is to separate code deployment from
feature release. A typical way to orchestrate actual feature releases is to
deploy the code ahead of time and later "flip a switch" to enable the feature.
If you need to run it by test users, selectively enable the feature for just
those users - there's your QA procedure.

~~~
zavulon
Hmm, I guess that would work, but it seems like an incredible amount of
overhead to me. So you'd need to code that "switch" for every bugfix/feature?
And even if there are libraries to do that, you'd still need to add custom
code for every one.

Also, in this scenario you'd need to test every single combination, because
what if you test A,B,C together, but then business wants to hold off on B, and
if you enable A and C, that would break things?

And then enabling them for specific users only.. oy. What if it's a db schema
change? Run db scripts to alter tables in production, every time we 'flip the
switch'?

~~~
shykes
If a user can't see the feature, it doesn't exist. Typically enabling a
feature means revealing it at the view layer, which is quite simple. Any DB
schema change can take place ahead of time.

As for the complexity of testing permutations of features - that sounds like a
problem with your Q&A process, no matter how you implement it.

------
mattyb
Weird. I submitted this last night, and it was auto-killed.

<http://news.ycombinator.com/item?id=1539899>

~~~
ojbyrne
You should have complained to pg. I had a similar thing happen on a digg blog
post, and he reinstated it.

------
diderot
Has a regular user of Digg and an alpha tester for Digg4, I have to say I am
quite impress with the rapidity and the quality of the changes. The real-time
digg count updates give quite a good feeling to the website in general since
you have a feeling to participate in something bigger. The update has been on
the right track and I hope the best for Digg.

~~~
phrotoma
The "my news" front page has made it vastly more useful for finding things I'm
interested in. Though until it's out of beta and friends can use it fully it
still feels a bit like the "like" button in google reader.

------
timcederman
Also impressed that Flickr uses continuous deployment.
<http://code.flickr.com/blog/2009/12/02/flipping-out/>

------
jamesshamenski
Could someone name other companies that do continuous deployment? I've only
heard that IMVU uses buildbot.

~~~
brainsik
Buildbot is used for continuous integration, which is a big step along the
path to continuous deployment. A lot of companies are doing this today. Fewer
are doing continuous deployment. kaChing has some posts about their setup:

[http://eng.kaching.com/2010/05/deployment-infrastructure-
for...](http://eng.kaching.com/2010/05/deployment-infrastructure-for.html)

[http://eng.kaching.com/2010/06/applied-lean-startup-ideas-
co...](http://eng.kaching.com/2010/06/applied-lean-startup-ideas-
continuous.html)

And I believe many of the companies featured in the Startup Lessons Learned
conference are doing continuous deployment:

<http://www.justin.tv/startuplessonslearned/videos>

There's a lot of momentum towards this. The company I'm at is working to get
there.

~~~
Lewisham
Yeah, it's important to make the distinction between continuous deployment and
continuous integration.

Continuous integration is a fairly simple thing: detect a new source commit,
run a battery of tests on it, report back. Hudson is a really good one (of
which the original author is a main contributor, and I did some plugin work
for a while), and I use it as a fairly fancy looking cron as well.

Continuous deployment, as described in the article, is much more difficult.
Not only do you have the slew of tests, but maybe you want more long-running
tests that you don't care to run all the time. Maybe you want code reviews.
You'll need to automate the actual deployment process and so on.

------
bosch
I wonder if any company will see an opening to create an easy process
utilizing all those programs which I assume have to be individually setup? I'm
sure if it was easier to configure more teams would utilize that method of
deployment.

