4 ms·

How Digg does continuous deployment

143 points by malyk 16y ago

mattyb 16y ago
Weird. I submitted this last night, and it was auto-killed. http://news.ycombinator.com/item?id=1539899 http://news.ycombinator.com/item?id=1539899
- ojbyrne 16y ago
  You should have complained to pg. I had a similar thing happen on a digg blog post, and he reinstated it.
- jeff18 16y ago
  Interesting... mine was killed as well. http://news.ycombinator.com/item?id=1539911 http://news.ycombinator.com/item?id=1539911
- pietrofmaggi 16y ago
  idem... killed even mine: http://news.ycombinator.com/item?id=1541119 http://news.ycombinator.com/item?id=1541119 But which are the rules that autokill a submission? I can understand simple duplicate removal, but then?
diderot 16y ago
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 16y ago
  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.
jamesshamenski 16y ago
Could someone name other companies that do continuous deployment? I've only heard that IMVU uses buildbot.
- brainsik 16y ago
  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.html http://eng.kaching.com/2010/05/deployment-infrastructure-for... http://eng.kaching.com/2010/06/applied-lean-startup-ideas-continuous.html http://eng.kaching.com/2010/06/applied-lean-startup-ideas-co... And I believe many of the companies featured in the Startup Lessons Learned conference are doing continuous deployment: http://www.justin.tv/startuplessonslearned/videos 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 16y ago
    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.
- sv123 16y ago
  I believe facebook does it as well, trying to find a video I saw from a while back to post.
- cwinters 16y ago
  Etsy (not surprising since John Allspaw from flickr is head of ops): http://www.southsearepublic.org/article/2340/read/etsys_continuous_deployment_process/deploying_code_to_production_safely_and_quickly/ http://www.southsearepublic.org/article/2340/read/etsys_cont...
timcederman 16y ago
Also impressed that Flickr uses continuous deployment. http://code.flickr.com/blog/2009/12/02/flipping-out/ http://code.flickr.com/blog/2009/12/02/flipping-out/
snprbob86 16y ago
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.
- eries 16y ago
  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.html http://radar.oreilly.com/2009/03/continuous-deployment-5-eas...
- pacemkr 16y ago
  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 16y ago
    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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
rudeboy 16y ago
auto killer
bosch 16y ago
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.

143 points by malyk 16y ago

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

ojbyrne 16y ago
You should have complained to pg. I had a similar thing happen on a digg blog post, and he reinstated it.
jeff18 16y ago
Interesting... mine was killed as well. http://news.ycombinator.com/item?id=1539911 http://news.ycombinator.com/item?id=1539911
pietrofmaggi 16y ago
idem... killed even mine: http://news.ycombinator.com/item?id=1541119 http://news.ycombinator.com/item?id=1541119 But which are the rules that autokill a submission? I can understand simple duplicate removal, but then?

diderot 16y ago

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 16y ago
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.

jamesshamenski 16y ago

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

brainsik 16y ago
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.html http://eng.kaching.com/2010/05/deployment-infrastructure-for... http://eng.kaching.com/2010/06/applied-lean-startup-ideas-continuous.html http://eng.kaching.com/2010/06/applied-lean-startup-ideas-co... And I believe many of the companies featured in the Startup Lessons Learned conference are doing continuous deployment: http://www.justin.tv/startuplessonslearned/videos 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 16y ago
  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.
sv123 16y ago
I believe facebook does it as well, trying to find a video I saw from a while back to post.
cwinters 16y ago
Etsy (not surprising since John Allspaw from flickr is head of ops): http://www.southsearepublic.org/article/2340/read/etsys_continuous_deployment_process/deploying_code_to_production_safely_and_quickly/ http://www.southsearepublic.org/article/2340/read/etsys_cont...

timcederman 16y ago

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

snprbob86 16y ago

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.

eries 16y ago
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.html http://radar.oreilly.com/2009/03/continuous-deployment-5-eas...
pacemkr 16y ago
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 16y ago
  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 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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.

rudeboy 16y ago

auto killer

bosch 16y ago

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.