Since version 1.7, Django creates migrations for more than just changes to
your model fields. It’s easy to forget to create a migration after changing,
say, the verbose_name_plural
of a model class - I’ve done this many times.
This can lead to a mess down the line when multiple developers all end up
creating the same migration in separate branches.
You can avoid this situation by checking for missing migrations in your test suite:
Here we call the makemigrations
command in “dry-run” mode and test the
exit code to determine if there are any missing migrations. If there are missing
migrations, the test will fail and print the captured output from the
makemigrations
command.
Note that if you are using a custom MIGRATION_MODULES
setting to avoid
applying migrations during
tests, you need to restore its default value for
the above command to work:
Credit for this implementation belongs to Mozilla’s Ed Morley, who committed a similar fix for their treeherder project. The above snippets are slightly extended versions of his original.
Related reading:
- Here’s another approach by YunoJuno that achieves the same effect.
- Estimating cost per dbt model in Databricks
- Automating secrets management with 1Password Connect
- Understanding how mypy follows imports
- Optimizing AWS Stream Consumer Performance
- Sharing Power Updates using Amazon EventBridge Pipes
- Using formatters and linters to manage a large codebase
- Our pull request conventions
- Patterns of flakey Python tests
- Integrating Asana and GitHub
- Durable database transactions in Django
- Python interfaces a la Golang
- Beware changing the "related name" of a Django model field
- Our in-house coding conventions
- Recommended Django project structure
- Using a custom Sentry client
- Improving accessibility at Octopus Energy
- Django, ELB health checks and continuous delivery
- Organising styles for a React/Django hybrid
- Hello world, would you like to join us?