Как синхронизировать несколько машин с South и Git

Question

Итак, хотя мне нравится Юг, у меня постоянно возникали проблемы с этим конкретным рабочим процессом:

• несколько раз мигрировали на машине A
• , периодически выдвигая изменения в Git
• после длительного периода возврата к машине B
• извлечение из Git и миграции выдают различные ошибки для машины B

Эти ошибки обычно являются ошибками "таблица уже существует".

Теперь я прочитал множество постов в блоге и вопросы о стеке, и, честно говоря, нет четкого ответа о том, как правильно проверять файлы миграции (и нужно ли вообще это делать) икак по-настоящему интегрировать South с Git.

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

В настоящее время, что мне нужно сделать, это через некоторое время полностью очистить папки миграции и начать с нуля.Это не очень хороший способ справиться с ситуацией.

Answer 1

Проблема

с югом и командным рабочим процессом возникает, когда два человека создают миграцию без синхронизации друг с другом.

Представьте, что у нас есть репо.Люди A и B клонируют его, затем изменяют какую-то модель, создают миграцию и затем отодвигают все это назад.У нас будет 2 миграции с одинаковым номером в репо.

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

Inconsistent migration history
The following options are available:
   --merge: will just attempt the migration ignoring any potential dependency conflicts.

Как указано в южных документах http://south.readthedocs.org/en/latest/tutorial/part5.html вы можете попытаться использовать опцию --merge, а south попытается объединить миграции.Он потерпит неудачу, если конфликтующие миграции изменили одну и ту же модель (ы).

./manage.py schemamigration --auto --merge appname 

Таким образом, основное правило для команды: одно время только один разработчик может изменить одну модель.Если кто-то начал менять модель, то никто не должен ее трогать, пока у него не появятся обновленные файлы миграции.

Правила для командного рабочего процесса с южными и несколькими ветками git:

1. Перед внесением изменений вДвойная проверка модели, если кто-то уже вносит изменения там
2. Уведомляйте других участников о ваших изменениях как можно скорее
3. Синхронизируйте ваши каталоги миграции как можно скорее

Также из южных документов: когда вы тянетев чьих-либо изменениях модели, выполненных вместе с их собственной миграцией, вам нужно будет сделать новую пустую миграцию, в которой зафиксированы изменения из обеих ветвей разработки (если вы использовали Mercurial, это эквивалентно коммиту слияния).Для этого просто запустите:

 ./manage.py schemamigration --empty appname merge_models

merge_models есть только новое имя миграции

Правила для командного рабочего процесса с южной и одиночной веткой git:

Если вся ваша командачлены переходят на одну ветвь, тогда лучшая стратегия будет состоять в том, чтобы сначала внести изменения в модель, выполнить миграцию и протолкнуть ее как можно скорее.Тогда поработайте над другим кодом.

Эта статья также может быть вам интересна:

http://andrewingram.net/2012/dec/common-pitfalls-django-south/ http://anthony -tresontani.github.io / Django / 2013 /03/15 / юго-технологический процесс /

Answer 2

Мне бы очень хотелось узнать, откуда возникли сомнения по поводу передачи файлов миграции на юг. Я, конечно, не знал ни о каком предположении, что ты не будешь.

В своем рабочем процессе вы не указываете, используют ли машины A и B одну и ту же или разные базы данных. Если ваш код будет существенно отличаться между двумя компьютерами, то они должны использовать разные базы данных. Если схема базы данных опережает код, вы получите ошибки. Очевидно, что схема не может отстать от кода, потому что вы всегда должны запускать migrate после обновления кода.

Мой рабочий процесс выглядит следующим образом:

A: create schema migrations and apply as they are created.
A: add schema migration files to subversion and commit
B: svn up
B: python manage.py migrate
B: continue coding!

Поскольку файлы миграции могут содержать код, который переводит данные в базу данных, не следует удалять миграции, потому что вы потеряете этот код. У меня есть команда разработчиков из трех человек, которая создала более 80 миграций и не столкнулась с какими-либо проблемами в форме, которую вы описываете.