The idea with using migrations is that they are the king of your database. They are the only thing that changes your database schema, and the only way you should be changing your database schema is by simply running the migrations.
In answer to your questions:
1. Auto generate migration file by looking at model
Don't. Manually generate a migration. If you're changing the columns of a particular table, generate the migration first, then modify the corresponding model next. Migrations are king of the database. Models come second.
2. Auto generate migration file based new changes made to model
Don't. Same as above.
3. Generate the SQL script of migration so that we can run this on PROD
Don't. You should just be able to run the migrations themselves directly on production, connecting to the production database, just the same as you'd run them in dev, with sequelize db:migrate. Your deployment script should automatically run sequelize db:migrate on the production database every time you push new code to production.
4. Environment specific migrations(Dev,Stage,Prod)
Definitely don't. Every migration should run in every environment. Your database should have the same schema regardless of the environment.
Update: Here's an example migartion that works (both running up and down) to add a new boolean column:
'use strict';
module.exports = {
up: function (queryInterface, Sequelize) {
return queryInterface.addColumn(
'my_table',
'my_new_column',
{
type: Sequelize.BOOLEAN,
}
)
},
down: function (queryInterface, Sequelize) {
return queryInterface.removeColumn('my_table', 'my_new_column')
}
};
