[Bug] Wrong usage of Django migration feature

[navrasic]

🐛 Describe the bug

Django has a quite sophisticate mechanism to upgrade the database from release to release, please find documentation here: https://docs.djangoproject.com/en/6.0/topics/migrations/. Please study this reading the ticket further.

SceneScape also uses Django in web component, but the Django migrations feature is used wrongly in SceneScape.
Makemigrations is not intended to be called at runtime like here: https://github.com/open-edge-platform/scenescape/blob/main/manager/config/scenescape-init#L259 , but making migration files should be part of the release process. Line 259 should be removed, only line 260 should be kept, and the generated migration file should be checked in to the repository and built into the image containing Django. This enables Django upgrade from release-n to release-n+1. The way how you currently use it requires SceneScape to be undeployed before installing the new version, which is a no-go in a business application.

📋 To Reproduce

Steps to reproduce the behavior:

1. Deploy SceneScape.

💻 Expected behavior

Django migrations files are tracked in version control image, they are build into the web image, newer SceneScape release can be upgraded on the top of the previous one without losing data.

• 0001_initial
• 0002_release_2
• 0003_release_3
• 0004_etc...

🖥️ Screenshots or logs

N/A

📦 Release version

• Current main branch

🧩 Environment

• Irrelevant

📄 Additional context

N/A

[saratpoluri]

@navrasic : if you have already fixed the issue on your end, we would love to receive our first external Pull Request.

I will take care of running makemigrations as part of the release build in CICD and checking in the patches to the repo.