Continuous deployment with Heroku | Hacker News Reader

Continuous deployment with Heroku

neilmiddleton.com

Tried this, it's not really possible because Heroku deploys restart the server and make the site inaccessible for a few minutes (and often errors out requests).

Hoping Heroku will fix what I consider a major bug. Until then, I've resigned to having to redeploy to heroku in the middle of the night to avoid customers getting pissed.

Shameless plug: dotCloud (http://www.dotcloud.com) doesn't have downtime at deployment. It leaves your current version untouched until the new version is fully built, run, scaled and responsive. Only then is trafic switched over. If anything goes wrong on even a single node, the deployment is safely aborted. This is the case even for deployments which span dozens or hundreds of processes on several datacenters. It's a lot of work to get right.

(disclaimer: I work at dotCloud)

Awesome, thanks for the heads up. I'll definitely be trying DotCloud very soon. Glad you guys were able to really focus on the small details as its easy to glance over when trying to launch a product.

We (Railsonfire, a continuous deployment service actually) deploy regularly to Heroku (up to several times a day) and the timeout is a few seconds max. We are on cedar stack though, which might make a difference there.

Working on startup time definitely helps getting that number down, but they did a pretty good job in starting up on Heroku fast I think.

You can take a look at how we deploy your code to heroku here: http://help.railsonfire.com/deployment/Heroku-Deployment.htm...

You can deploy to staging on every build and deploy to production only when you push to a specific branch for example. So you still deploy continuously to staging, but trigger deployment to production manually.

Basically to set it up all you need to to is install our gem and run railsonfire create in your application folder.

We are going public with our Heroku Addon as soon as possible, but you can login with your GitHub account or email/password as well (and even connect all 3 of those logins into one account).

If you have any more questions send me an email to flo@railsonfire.com

Personally, I don't see this. If you spend the time making sure that your application spins up nice and fast then the only downtime is from when Heroku decommissions the old version of your application and the new one starts up.

I'm generally only seeing a lag of a few seconds at most, and no lost requests. I would look at your code and see what improvements you may be able to make.

Most deployment allows for the site spin up independently before switching the load balance to it to provide a seamless experience.

Even a very simple Rails sample app will often take over a minute to spin up on heroku. I don't think it's smart to completely focus on server startup time when the real fix is available on most other deployment environments.

That said, I still like Heroku and can deal with this for a while until they fix it :)

It really depends on your environment. If you're using Rails, it's almost certainly 100% dependent on how many gems you're using.

I checked with Heroku regarding this before considering using it. It seems that you should not be seeing the above (atleast on their latest cedar stack).

When you make a new push to Heroku, they seem to make sure to setup the code on a different machine, get it up, and then finally redirect the incoming requests from the load balancer.

This is true only for a very trivial definition of "get it up". The second that Heroku starts your server all requests will be pushed over to the new dynos. For a Rails app, depending on how many gems you are loading and how fast your environment can load, this might be as much as 15 seconds of request queueing.

This one point has me sitting on the fence with taking my app to production on Heroku, or using Amazon EC2 directly and eating the time to build Chef scripts to provision servers.

Honestly, I find this article a little irresponsible. Continuous integration is really one small part of deployment, and if you think you're ready to deploy at any time just because your tests pass, you're setting yourself up for some very painful lessons.

First off, there's currently no way to do a truly seamless deployment of code on Heroku. The second your server starts, the dynos will switch over to your new code, meaning that requests will queue while your environment loads. If you have a lighting-fast booting Sinatra app, you might be OK, but for a Rails app of any complexity there may be issues.

Secondly, without paying a LOT of attention to how backwards compatible your code is, database migrations rarely fit well with a truly seamless deployment.

Hi Ryan,

you could deploy to your staging environment upon every build and only deploy to production when triggered manually.

Railsonfire (full disclosure: I am one of the founders) makes this very easy. Just give it a look here: http://help.railsonfire.com/deployment/Heroku-Deployment.htm...

You just have to set your branch for the production/staging environment and only when you push to this specific branch the deployment will run.

If you need any help setting it up or have questions please send me an email to flo@railsonfire.com

Reply on news.ycombinator.com