Всем привет!
Изучаю вопрос накатывания миграций, с учетом того, что приложение крутится в контейнере. Есть несколько вариантов:
1. Засовывать python manage.py migrate в docker-entrypoint.sh (используется сейчас). Но тогда возникает проблема со скейлингом контейнеров. Получается, что при увеличении числа контейнеров - каждый раз включается миграция. А если при запуске второго контейнера процесс выполнения миграций в первом контейнере всё еще выполняется - хз что произойдет. lock? error?
2. Отдельный job в CI - перед деплоем запускать в билд-агенте миграции. Но что тогда произойдет с уже работающими контейнерами, при условии изменении таблицы?
3. Отдельный контейнер для выполнения миграций. Грубо говоря, в процессе деплоя рестартить контейнер (из CI), для запуска задачи.
Стек: docker-compose (пока так), gitlab, django.
Есть ли еще какие-то варианты? Какой из будет наиболее безболезненный?

код должен уметь работать с текущей версией структуры базы и с прошлой версией, миграции после обновления отдельно

Народ привет. Очень срочно нужна помощь в Джанго. Я новичок поэтому для меня сложно, речь идёт о замене хтмл шаблонана 2х страницах на новый. Взялся за заказ, но понял что зелёный, неосилил половину, а именно - эту часть. То есть нужно просто правильно посадить новый шаблон на уже имеющуюся страницу. Если кому интересно, или кто-то согласится помочь, прошу напишите в личку. Естественно не бесплатно. Возможно пишу не в соответствии с правилами, прошу прощения, просто малость отчаяние.

попробуй спросить тут @django_jobs

в общем-то тесты на CI тоже можно запускать на двух версиях структуры базы

Всем привет!
Изучаю вопрос накатывания миграций, с учетом того, что приложение крутится в контейнере. Есть несколько вариантов:
1. Засовывать python manage.py migrate в docker-entrypoint.sh (используется сейчас). Но тогда возникает проблема со скейлингом контейнеров. Получается, что при увеличении числа контейнеров - каждый раз включается миграция. А если при запуске второго контейнера процесс выполнения миграций в первом контейнере всё еще выполняется - хз что произойдет. lock? error?
2. Отдельный job в CI - перед деплоем запускать в билд-агенте миграции. Но что тогда произойдет с уже работающими контейнерами, при условии изменении таблицы?
3. Отдельный контейнер для выполнения миграций. Грубо говоря, в процессе деплоя рестартить контейнер (из CI), для запуска задачи.
Стек: docker-compose (пока так), gitlab, django.
Есть ли еще какие-то варианты? Какой из будет наиболее безболезненный?

migrate это операция с бд, зачем мильен раз то запускать? вообще имеет смысл посмотреть в сторону имаджей. выкатил обновление, сбилдил имадж в свой репозитарий и резко поднял инстансы

её только при обновлении моделей делать надо?

migrate это операция с бд, зачем мильен раз то запускать? вообще имеет смысл посмотреть в сторону имаджей. выкатил обновление, сбилдил имадж в свой репозитарий и резко поднял инстансы

Так я и хочу один раз всего запускать. Вопрос только когда?

И каким способом

написали выше CI - например см bitbucket или gitlab pipelines