Как обрабатывать миграции для сторонних приложений django в конвейерах развертывания?
Я использую стороннюю зависимость modeltranslation-lokalise, которая требует, чтобы я запустил python manage.py makemigration. Это создаст файл миграции, который будет находиться в каталоге пакета после создания, и поэтому не контролируется исходным кодом.
Для всех остальных файлов миграции я держу их под контролем исходного кода и хотел бы сделать то же самое для этих, поскольку это позволит нам отслеживать изменения в базе данных в используемых нами средах, гарантируя, что они могут быть легко воспроизведены и что операции не дублируются в одной и той же базе данных (например, если одна и та же операция существует в миграциях с разными именами).
Мой вопрос: Как эти сторонние миграции должны обрабатываться при сборке и развертывании на производстве (например, через Dockerfile в конвейере сборки?
).Мое предположение - найти способ надежно извлечь файлы миграции из пакета и добавить его в контроль исходного кода.
Альтернативой может быть: запуск makemigrations внутри Dockerfile, который создает развернутый образ, однако это может привести к тому, что одна и та же миграция будет запущена дважды на базе данных, если имя этой миграции изменится (например, если в имени есть временная метка). Поэтому я думаю, что лучше избежать этого.
Примечание: этот вопрос похож, но он считает использование третьей части необязательным и, похоже, не рассматривает вышеуказанные альтернативы.
Я решаю это, используя ответ на этот вопрос:
Джанго миграционный файл в другом приложении?
Используя настройки MIGRATIONS_MODULE, я смог указать django на создание миграций в моем каталоге исходников и, таким образом, зафиксировать их в системе управления исходниками.