To prevent migration conflicts between different developers, we decided to avoid deploying any migrations files; and rather run makemigrations
after deployment.
But every time we deploy, the existing migration files are deleted and a new 001_initial.py
file is created, leading to a programmingerror
Why is Digital Ocean deleting the existing migration files rather than running a new makemigration and appending the model changes to the existing files? We run python manage.py makemigrations && python manage.py migrate
before the run commands.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Heya,
DigitalOcean’s App Platform doesn’t inherently delete your migration files. However, the behavior you’re observing is indicative of how stateless platforms work, particularly when you’re not persisting changes between deployments. Here’s a breakdown of the issue:
Statelessness: Cloud platforms like DigitalOcean’s App Platform aim to be stateless for increased scalability and resilience. Every time you deploy, it essentially starts from a “clean slate,” building and deploying your app from the source code. So if
makemigrations
is executed during deployment, it won’t “remember” previous migrations and will try to create the initial migrations every time.Version Control: To maintain consistent state, migrations should be version-controlled (e.g., in Git) alongside your application code. This ensures that every time you deploy, the previously generated migration files are present. It’s common practice in the Django community to generate migrations locally or in a development environment and then commit those to your repository. This ensures all developers and environments are in sync.
Migration Conflicts: Running
makemigrations
on the server, especially in a stateless environment, can lead to issues. If two developers make different changes and both push, one will succeed, and the other will conflict. It’s better to generate migrations locally, handle any conflicts or issues, commit them, and then deploy.Recommendations:
Commit Migrations: Always commit your migration files to your version control system (like Git). When you deploy, those files should be present as part of your codebase.
Migrations in CI/CD: If you have a CI/CD pipeline, consider running
migrate
as part of the deployment process, but notmakemigrations
. Let the migrations be generated in your local or development environments, and simply apply them in production.Backup: Always backup your database before making significant changes, especially if you’re unsure about the migrations. This gives you a fallback in case anything goes wrong.
Consider Manual Migrations for Complex Changes: For complex database changes, consider applying migrations manually. This gives you more control and allows you to address any issues that might arise.
In essence, migrations are a form of version control for your database. They should be treated with the same care as your application code: generated thoughtfully, reviewed, committed to version control, and then applied in a controlled manner.
Hi there,
You should not make the changes directly on the App Platform as the storage there is Ephemeral meaning that after every deployment any changes that you made directly to the local storage will be lost.
You should make your changes to your GitHub project and those changes will be deployed to your App Platform.
https://docs.digitalocean.com/products/app-platform/how-to/store-data/
Let me know if you have any questions.
Best,
Bobby