Django migration files overwritten after every deployment

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:

1. 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.

2. 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.

3. 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:

1. 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.

2. Migrations in CI/CD: If you have a CI/CD pipeline, consider running migrate as part of the deployment process, but not makemigrations. Let the migrations be generated in your local or development environments, and simply apply them in production.

3. 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.

4. 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