'How to prevent django migrations from running?
My team frequently uses the production DB for testing new changes and on more than one occasion migrations have been created and applied before being code reviewed, creating issues in production.
There are so many things wrong with this situation, but I'm hoping to at least protect our prod DB by blocking migrations based on the state of an environment variable. Is this possible?
Solution 1:[1]
This looks like it might work, but curious if others have less hacky answers:
# Prevent migrations from running in dev env (where the prod DB is used).
if ENVIRONMENT == 'staging' and 'migrate' in sys.argv:
INSTALLED_APPS.remove('app_name')
Solution 2:[2]
So we tackled it like this. Instead of one settings.py file we have multiple different ones settings/dev.py, settings/prod.py, settings/local.py etc.
Then when you do any manage.py command, you need to explicitly add which settings file you want to use.
DJANGO_SETTINGS_MODULE=myapp.settings.dev ./manage.py migrate
we speed this up with a manage.sh file next to manage.py that kinda looks like this:
EXPECTED_ENVS=(local development staging production)
if [[ ${EXPECTED_ENVS[*]} =~ "$1" ]]
then
# Pop the first argument parameters after 1
SETTINGS_ENV=$1
shift 1
else
SETTINGS_ENV="local"
fi
export DJANGO_SETTINGS_MODULE="myapp.settings.${SETTINGS_ENV}"
echo "Using settings module ${DJANGO_SETTINGS_MODULE}"
./manage.py $@
Then you can simply do things like this
./manage.sh development migrate
./manage.sh production shell
./manage.sh local runserver
with the above code, omitting the environment name will use the "local" settings file.
./manage.sh runserver # uses local as default
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | |
| Solution 2 | rymanso |
