how devise db:migrate works on production

Question

I'm doing my first project on RoR I decided to use Devise gem for the authentication everything is working fine in Localhost, right now i'm able to sing_up, log_in, reset pass and some other default features that comes with devise.

What I don't understand is how everything gets setup once i push the project into production environment. Let me explain better.

-I see that devise generates db/schema.rb file based on the user.rb model that devise auto generate, these schema i assume needs to be created in the production db.

I have to push the project into git repo but..

1) How the code gets executed once is published 2) How the user table gets created 3) where do I need to specify the db connection (db, user, pass)

In general how is the process to migrate into production env?

I appreciate your help.

Answer 1

Well depending on where you're hosting your code you should still do a rake db:migrate to make the changes to the production DB.

If deployed on Heroku, run the following in the console: heroku run rake db:migrate

Hope that answers your question?

Answer 2

In rails db schema is controlled using migrations. Migrations are usually very small files living in db/migrations folder. Each of them defines a single subclass of ActiveRecord::Migration class.

Each migration is supposed to go both-ways, so it has to implement both up and down method (for rollback). In majority of the changes those are obvious (like when up action creates a table, down action should destroy it). For migrations like this you can use change function - rails will create down function automatically (assuming that all actions are reversible - some of the methods even accept extra arguments to make it possible like remove_column :table, :field, :integer. :integer bit might seem redundant here, however the action is irreversible without that information).

You run your migrations using db:migrate rake task. Effectively it will run all the migration which has not been run against current database. When it is done, it will dump your current database into db/schema.rb file. This file is used only as a snapshot of your current database schema, which is of great help if you need to get back to previous version of your application (which is why schema.rb should always be checked into your source control). It is also possible to recreate your database directly from that file rake db:schema:load, however it will cost you all your data.

If you check your database (any environment), you will notice there is one extra table called schema_migrations which does not appear in your schema file. This table contains all the migrations that has been executed against this database. This way rails will not retry migrations that already has been run.

There are many advantages of using migration system:

1. It is easy for every developer to bring their local database up to the latest schema.
2. It is easy to rollback your latest changes if deployment failed. (Not always the case)

So how to use it in production? You simply has to point the rake task to the right database:

RAILS_ENV=production rake db:migrate

You can find your database configuration in config/database.yml file. Note that this is the best practice not to store that file in source control and in case of production it is not advisable to store your database password there. Normally you will need to set it through environment variable.

It is important to remember couple of things about migrations:

1. Never, ever change the existing migration if there is a chance that someone has already run it. Especially, do not modify migrations that has run in production unless you are 100% sure what you are doing (for example fixing rollback). Since database remembers which migrations has run, it might lead to getting your local db out of sync with production db and hence lead to bugs.

2. Never ever change database schema manually - every change has to be made through migrations.