Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Digg does continuous deployment

about.digg.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: How Digg does continuous deployment

#11

Post by Lewisham »

brainsik wrote: post #7
jamesshamenski wrote: post #4

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

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/06/applied-lean-startup-ideas-co... And I believe many of the companies featured in the Startup Less…

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.

Re: How Digg does continuous deployment

#12

Post by 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.

Re: How Digg does continuous deployment

#14

Post by pietrofmaggi »

mattyb wrote: post #2

Weird. I submitted this last night, and it was auto-killed. http://news.ycombinator.com/item?id=1539899

idem... killed even mine: http://news.ycombinator.com/item?id=1541119

But which are the rules that autokill a submission? I can understand simple duplicate removal, but then?

Re: How Digg does continuous deployment

#15

Post by phrotoma »

diderot wrote: post #3

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.

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.

Re: How Digg does continuous deployment

#16

Post by eries »

snprbob86 wrote: post #12

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.

Actually, continuous deployment does not necessarily need to be automated. In my experience, it's possible to get going with it in a totally incremental way. One easy way to get started is with this post: http://radar.oreilly.com/2009/03/continuous-deployment-5-eas...

Re: How Digg does continuous deployment

#17

Post by 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.

Re: How Digg does continuous deployment

#19

Post by eries »

jamesshamenski wrote: post #4

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

IMVU has done continuous deployment for many years (way before it was cool). For details, I think this presentation is probably the best: http://www.slideshare.net/bgdurrett/sds-2010-continuous-depl...

I've also contributed a chapter on it to the new O'Reilly Web Operations book: http://bit.ly/WebOperations

Re: How Digg does continuous deployment

#20

Post by shykes »

zavulon wrote: post #17

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…

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.
Post reply on HN