You can read about collectstatic here:
https://docs.djangoproject.com/en/dev/howto/static-files/deployment/
I think you should run it every time there is a change in the static files.
If you want to make sure, run it every time you deploy a new version.
אורי
u...@speedy.net
On Wed, Apr 3, 2019
Thank you. I'd surely be able to use this when we deploy. But is it really
necessary to run collectstatic everytime there is a deployment to perform?
I just use this to make the admin page have the correct styling when
accessed in production.
On Wednesday, April 3, 2019 at 12:55:31 PM UTC+8,
I think *makemigrations* should never be used in production. You run it
locally and then commit the migrations.
If it's a new production server you are deploying, I think you can delete
all your migrations and then run *makemigrations* (locally) to create only
initial migrations. But only if you
Ah I see. Thank you Jani for clearing that up.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group,
Hi.
You should deliver migrations as part of your product and run them on
production. Just like you do with collectstatic command you run migrate
command.
Eventually you will have data migrations and those you can't recreate on
production. Also if you recreate migrations on production again
There is a workflow section in the migration page from the django project
documentation. But there are somethings I am confused about,
It says that the migrations need to be created in the non production
environment and then checked in to the repository along with the changes in
models.py.
My
6 matches
Mail list logo
