Ответ 1
Правильный способ обработки db-версий - это версия script, которая является только аддитивной. Из-за этого, он будет конфликтовать все время, так как каждая ветка будет добавляться к одному файлу. Ты хочешь это. Это заставляет разработчиков понимать, как изменения друг друга влияют на сохранение их данных. Rerere гарантирует, что вы разрешите конфликт только однажды. (см. мое сообщение в блоге, которое затрагивает разделение rerere: http://dymitruk.com/blog/2012/02/05/branch-per-feature/)
Удерживайте каждое изменение в условии if then, которое проверяет номер версии, изменяет схему или изменяет данные поиска или что-то еще, а затем увеличивает номер версии. Вы просто продолжаете делать это для каждого изменения.
в коде psuedo, вот пример.
if version table doesn't exist
create version table with 1 column called "version"
insert the a row with the value 0 for version
end if
-- now someone adds a feature that adds a members table
if version in version table is 0
create table members with columns id, userid, passwordhash, salt
with non-clustered index on the userid and pk on id
update version to 1
end if
-- now some one adds a customers table
if version in version table is 1
create table customers with columns id, fullname, address, phone
with non-clustered index on fullname and phone and pk on id
update version to 2
end if
-- and so on
Преимущество этого в том, что вы можете автоматически запускать этот script после успешной сборки вашего тестового проекта, если вы используете статический язык - он всегда будет загружать вас до последней. Все приемочные тесты должны пройти, если вы только что обновились до последней версии.
Вопрос в том, как вы работаете в двух разных отраслях одновременно? То, что я делал в прошлом, только что развернуло новый экземпляр, который ограничен именем db именем ветки. Ваш файл конфигурации очищается (см. git smudge/clean), чтобы установить строку подключения для указания на новый или существующий экземпляр для этой ветки.
Если вы используете ORM, вы можете автоматизировать это поколение script, так как, например, nhibernate позволит вам экспортировать изменения графика, которые еще не отражены в схеме db, как sql script. Поэтому, если вы добавили сопоставление для класса клиента, NHibernate позволит вам сгенерировать создание таблицы script. Вы просто script добавили обертку if-then и автоматизировали в ветки функции.
Филиал интеграции и ветвь кандидата релиза имеют некоторые особые требования, которые потребуют очистки и повторного создания db, если вы сбросите эти ветки. Это легко сделать с помощью крючка, гарантируя, что новая ревизия git branch --contains старая ревизия. Если нет, протрите и восстановите.
Я надеюсь, что это ясно. В прошлом это хорошо работало и требует, чтобы каждый разработчик создавал и уничтожал свои собственные экземпляры dbs на своих машинах, хотя мог работать на центральном с дополнительным соглашением об именах экземпляров.