6 ms·

Continuous deployment with Heroku

13 points by craigkerstiens 15y ago

ryanbrunner 15y ago
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.
- matlock 15y ago
  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.html 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
railsjedi 15y ago
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.
- tomfakes 15y ago
  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.
- neilmiddleton 15y ago
  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.
  - ryanbrunner 15y ago
    It really depends on your environment. If you're using Rails, it's almost certainly 100% dependent on how many gems you're using.
  - railsjedi 15y ago
    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 :)
- vineet 15y ago
  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.
  - ryanbrunner 15y ago

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.

matlock 15y ago
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.html 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

railsjedi 15y ago

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.

tomfakes 15y ago
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.
neilmiddleton 15y ago
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.
- ryanbrunner 15y ago
  It really depends on your environment. If you're using Rails, it's almost certainly 100% dependent on how many gems you're using.
- railsjedi 15y ago
  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 :)
vineet 15y ago
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.
- ryanbrunner 15y ago