5

I am developing web systems using Django and they are deployed on Heroku. After the system goes production, all database data and the migration files (i.e., the 00*_* files) have to be retained. The followings are my procedure to perform database migration and deployment:

  1. For the first deployment, perform manage.py makemigrations locally and push to Heroku.

  2. Perform manage.py migrate on Heroku.

If models are changed later:

  1. Perform makemigrations locally and push to Heroku.

  2. Perform migrate on Heroku.

Steps 3 and 4 are repeated if models are changed.

As the system evolves, there are more and more migration files. I am wondering: after a successful migration and deployment, can I just delete all migration files and start like a fresh one? That is:

  1. For the first deployment, perform makemigration locally and push to Heroku.

  2. Perform migrate on Heroku.

  3. Delete all local migration files.

  4. Perform makemigrations locally to create seemingly start-up migration files.

Change models:

  1. Perform makemigration locally and push to Heroku.

  2. Perform migrate on Heroku.

Steps 3 to 6 are repeated if models are changed.

Is the above procedure correct?

Randy Tang
  • 4,283
  • 12
  • 54
  • 112

1 Answers1

8

For each of your app:

1) Pretend to rollback all existing migrations:

./manage.py migrate app zero --fake

The zero argument indicates that we rollback to the first migration. You can confirm all migrations have been rollbacked by running ./manage.py migrate app --list. The --fake option signals we should not actually run the migrations, but nonetheless mark the migrations as having been run: https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake

2). Delete migration files

git rm app/migrations/*

3) Create a new migration file

./manage.py makemigrations app

4) Pretend to run the new migration

./manage.py migrate app --fake

As in 1), step 4) does not actually run the migrations.

EDIT: added some explanations and fixed the zero argument.

Régis B.
  • 10,092
  • 6
  • 54
  • 90
  • Thanks a lot. Would you please elaborate more on steps 1 and 4? What do they mean? – Randy Tang Oct 01 '15 at 04:51
  • Got it. One last question: what would be the sequence if I need to change the model? 1 (remote) --> 2 (local) --> Change the app's model --> 3 (local) --> push to remote --> 4 (remote). Is this correct? Do I need to remove the "--fake" at step 4 to actually run the migration? – Randy Tang Oct 02 '15 at 00:01
  • 2
    I suggest you make all required modifications to the model prior to 1), as you usually do. Just run makemigration locally and migrate on heroku. – Régis B. Oct 02 '15 at 05:46
  • Its probably worth noting that command 1 and 4 need to be run on the server. I got everything working on my dev machine, but after deployment the django_migrations table didn't reflect the changes. – wobbily_col Jun 12 '17 at 11:08