http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx
Приведенный выше блог привел нас к нашей текущей системе контроля версий баз данных. Проще говоря, без скрипта обновления не производится никаких изменений в БД, и все скрипты обновления находятся в нашем репозитории контроля версий.
Мы управляем только изменениями схемы, но вы также можете / захотите рассмотреть возможность сохранения дампов ваших данных также в системе контроля версий; Создание таких файлов - довольно тривиальное упражнение с использованием mysqldump.
Наше решение отличается от решения, представленного в блоге, одним ключевым способом: оно не автоматизировано. Мы должны применить обновления базы данных и т. Д. Хотя это может занять немного времени, это откладывает некоторые усилия, которые потребуются полностью автоматизированной системе. Однако мы автоматизировали одну вещь - отслеживание версии БД в программном обеспечении: это было довольно просто, и оно гарантирует, что наше программное обеспечение знает о базе данных, с которой оно работает, и будет работать ТОЛЬКО, если оно знает схему, с которой работает.
Самым сложным в нашем решении было то, как объединить обновления из наших веток в нашу магистраль. Мы потратили некоторое время на разработку рабочего процесса, чтобы учесть возможность двух разработчиков одновременно объединять ветки с обновлениями БД и способы их обработки. В конечном итоге мы остановились на блокировке файла в системе управления версиями (для нас рассматриваемый файл на самом деле представляет собой версию программного обеспечения для преобразования таблиц в версию БД, которая помогает в нашей стратегии ручного управления), так же, как и в критической секции потока, и в разработчике, который блокировка идет об их обновлении багажника. По завершении другой разработчик сможет заблокировать его, и он несет ответственность за внесение любых изменений, необходимых для их сценариев, чтобы избежать ожидаемых коллизий версий и других неприятных ошибок.