How exactly does the Heroku deployment process work?

Question

When I deploy a new version of my service to Heroku, what exactly happens?

Suppose I have online online online, M of which currently serves requests.

• Do they all close before the new version starts arriving on the Internet? What happens to any requested requests that are currently being served?
• Is there any downtime? (for example, I just have a stateless service without any migrations).
• Is there a hook for performing user migrations (e.g. moving database tables)?
• Can I connect N servers to the new version, make them start service requests and display the previous N servers only after they will not service any requests?
• Does the answer depend on the stack / language? (Aspen / Bamboo / Cedar, Ruby / Node.js / Java / ...)

I did not have any official documentation about this, just the opposite (some say that hot migration is not possible , while others say that there is no downtime ). Are there any official data on the deployment process and the above questions?

Answer 1

Here's what happens during the deployment of Heroku (current as of 10/20/2011 *) [1]:

• Heroku gets your git push
• The new release is compiled from the latest version of your application and saved
• [This happens about the same time]
  • A dino grid signals the completion [2] of all running processes for your application.
  • A dynamic grid signals the start of new processes for your application.
  • A dino grid is signaled to streamline all processes in the standby mode of your application.
  • HTTP Router Signals to Start Routing HTTP Traffic to Web Servers Launching New Version

The general conclusion is that to minimize any possible downtime, you should minimize the load time of your application.

Following a thorough migration method, you can click the new code and then perform the migration while the application is running. Rails example: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

To minimize remote connections during a reboot, use a web server that responds appropriately to SIGTERM by starting a graceful shutdown (terminate existing connections, don't take new ones). Newer versions of thin will correctly handle SIGTERM.

• This issue is the subject of much discussion within the country and may change in the future.
• SIGTERM follows 10 years later SIGKILL if still working

Answer 2

I can answer "Is there a hook for performing user migrations (for example, moving database tables)?" part of this question. I handled the current migrations by writing a shell script that does "heroku rake db: migrate" right after I issue "git push heroku". I don’t know if there is more of a “hook” - a way to do this.