Общепринятой практикой является то, что люди, работающие над проектом django, обычно перенаправляют миграцию в систему управления версиями вместе с другим кодом.Почему необходимо перенаправить миграции django в систему управления версиями
Мой вопрос: почему эта практика так распространена? Почему бы просто не нажимать обновленные модели, и каждый из них генерирует миграцию локально. Такой подход может уменьшить усилия для разрешения конфликтов миграции.
Если вы не передали их в VCS, тогда произойдет то, что люди сделают потенциально конфликтующие изменения модели.
Когда вы, наконец, готовы к развертыванию, вам все равно понадобится django для создания новых миграций, которые затем объединили бы изменения everybodys. И это просто создает дополнительный ненужный шаг, который может привести к ошибкам.
Вы также считаете, что каждый всегда сможет работать с обновленной версией кода, что не всегда возможно, когда вы начинаете работать с ветвями, которые не готовы к объединению в магистраль.
Во-первых, миграция в управлении версиями позволяет запускать их на производстве.
Во-вторых, миграции не всегда автоматически генерируются. Например, если вы добавите новое поле в модель, вы можете написать миграцию для заполнения поля. Эта миграция не может быть воссоздана из моделей. Если эта миграция не находится в управлении версиями, то никто не сможет ее запустить.
Butt мы также можем создавать миграции в процессе производства, а затем применять эти миграции. Что-то не так с этим подходом.? – Ishtiaq
Да, в теории вы могли бы генерировать миграции в процессе производства (хотя не пользовательские миграции, как я уже отмечал выше). Однако создание миграции в процессе производства может вызвать проблемы, если вам нужно выполнить миграцию перед обновлением кода (например, при добавлении новой модели). – Alasdair
Что говорит @Alasdair, так это то, что вы должны отслеживать их, потому что вам могут потребоваться миграция данных (настраиваемые миграции). В некоторых случаях люди вручную записывают миграцию, чтобы достичь чего-то вроде заполнения начальных данных и т. Д. Если вы не сохраните их в управлении версиями, вы потеряли эти шаги. –
Миграции синхронизируют состояние вашей базы данных с состоянием вашего кода. Если вы не проверяете миграцию в контроле версий, вы теряете промежуточные шаги. Вы не сможете вернуться в историю управления версиями и просто запустить код, поскольку база данных не будет соответствовать моделям в этот момент времени.
Миграции, как и любой код, должны быть протестированы, по крайней мере, на базовом уровне. Даже если они автоматически генерируются, это не гарантия того, что они будут работать в 100% случаев. Таким образом, безопасный путь - это создать миграции в среде разработки, протестировать их, а затем вывести их в производственную среду, чтобы применить их там.
Не могли бы вы привести примеры того, какие тесты вы используете для этого? Вы проверяете наличие данных? – szeitlin
Примером может быть: person A создал ветку из 'master' и создал новую миграцию' 0010', человек B создал ветку из 'master' и создал новую миграцию' 0010'. Объединенный, чтобы развиться раньше, чем B, когда B вытащил последнее изменение и попытался объединить свой код с «мастером», он получил двойную миграцию. Если вы не отслеживаете миграцию, B будет очень смущен. –
OP предполагает, что подталкивание файлов моделей и генерация миграции из них должны позаботиться об этом. Я сам это задался. Устранение непоследовательных миграций, особенно для разделяемых отраслей и незавершенного производства, было огромной тратой времени. Я вижу пункт @ alasdair ниже о автоматическом населении (это единственное исключение, которое имеет смысл для меня, хотя оно не применяется, если вы используете фабрики вместо пользовательских миграций).Мне бы хотелось увидеть лучшие предложения по лучшим методам предотвращения конфликтов миграции и/или лучшим инструментам их решения. Например, – szeitlin
, я просто столкнулся с проблемой, которую я довольно часто встречаю, когда отсутствуют зависящие от слияния при попытке миграции. Проблема заключается в том, что файлы миграции в отдельных приложениях не всегда синхронизируются между ветвями. Ошибки django не дают вам полный путь к файлу миграции, вызвавшему проблему, только номер. #fail – szeitlin