2 questions about deployment about guides HOT 2 CLOSED

@bemurphy Sure thing.

You specify an app restart post migration. We have issues sometimes I call "stuck dynos" where sometimes not every process seems to be aware of new columns. Is this to alleviate that, or is there another reason?

Yes, it is to alleviate that.

When a Rails app boots, the ActiveRecord classes reflect on the database to determine which attributes and associations to add to the models:

http://guides.rubyonrails.org/configuring.html#rails-general-configuration

The config.cache_classes setting is true in production mode and false in development mode. During development, we can write and run a migration and see the change take effect without restarting the web server but in production we need to restart the server for the ActiveRecord classes to learn about the new information from the database. Otherwise, the database will have the column but the ActiveRecord classes will have been cached based on the old information.

When you introspect to make sure "everything is ok" what do you look for?

Here's a real example:

production ps
=== web: `bundle exec rails server thin start -p $PORT -e $RACK_ENV`
web.1: up 2013/01/25 16:33:07 (~ 18h ago)
web.2: up 2013/01/25 16:47:15 (~ 18h ago)

=== worker: `bundle exec rake jobs:work`
worker.1: up 2013/01/25 17:30:58 (~ 17h ago)

The "up"s tell me the processes are running. They will say "crashed" if there's a problem.

If I were to run production tail (aliases from here), I might just be watching the stream looking for anything unusual, like 500s and errors. Sometimes error reporting services are delayed so there's no faster way to know about a post-deploy issue than tailing the logs while running through some critical workflows in the app. If something looks unusual, I might then move over to the logging service we have set up (typically Splunk or Papertrail) to run some searches to see how often the problem is coming up or if it looks new post-deploy. New Relic or Airbrake will likely have more backtrace information by this time and we can make a decision about whether to roll back the deploy, or work on a hotfix as the next action, or record the bug and place it lower in the backlog.

from guides.

@croaky wow, thanks so much for this answer. It just highlighted a problem in our deploy task I can't believe I didn't think of before! You should see the look on my face.

from guides.