Как управлять и записывать изменения базы данных для нескольких разработчиков?

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

Существуют ли хорошие методы для .NET-ориентированной разработки против MS SQL Server 2008 для управления этим? Я думаю, что-то похожее на Rails Migrations, и у каждого разработчика и тестировщика есть своя локальная база данных. Или это перебор? По крайней мере, было бы неплохо иметь отдельные тестовые и dev-базы данных, но в настоящее время ручное хранение двух баз данных в синхронизации, вероятно, хуже нашего текущего затруднительного положения.

LiquiBase кажется многообещающим, кто-нибудь успешно использовал его в подобной среде? Или есть лучшие подходы?

Мы используем SQL Server 2008, VS 2008 и .NET 3.5, если это вообще имеет значение.

Ответы

Ответ 1

У нас есть скрипты для создания БД с нуля, и это то, что сидит в исходном элементе управления. Каждый разработчик (20 из них) использует script для создания 2 баз данных на своих рабочих станциях. Один для "работы" - ручное тестирование с образцами данных в нем (для заполнения выборочных данных script). Другая БД пуста и используется в модульных тестах (открытая транзакция - do unit test - откат).

Unit test являются обязательными в среде нескольких разработчиков. Также мы всегда строим "старую" базу данных и применяем к ней изменения схемы. Каждый разработчик меняет схему, создавая процедуры обновления (это то, как мы одновременно восстанавливаем и обновляем готово).

Для тестирования производительности у нас есть "загрузчики" - код С#, который имитирует пользователей и заполняет миллионы записей за ночь на рабочих станциях разработчиков.

Ответ 2

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

О, и я забыл добавить, если вы вносите изменения в схему, вы также несете ответственность за запись миграции script, если это необходимо. Это, как правило, необходимо в любом случае, когда что-то приходит к производству.

Надеюсь, что это поможет.

Ответ 3

Visual Studio Team System Database Edition (aka "Data Dude" ) стоит посмотреть. Он может отслеживать различия в базе данных и генерировать сценарии изменений, чтобы вы могли подготовить среду тестирования /prod до развертывания и т.д. Я думаю, что его функции также доступны в версии разработки (см. Предыдущую ссылку), а в VS 2010 будет более заметным. Взгляните на это сообщение в блоге: Первый опыт работы с Visual Studio 2008 Database Edition, мне это нравится!!!

Это, наряду с TFS, дает вам возможность управлять версиями файлов SQL и запускать их с базой данных.

Ответ 5

Я попал в лагерь "одна база данных разработки".

В отличие от традиционного исходного кода OO, в базе данных часто будут таблицы, поддерживающие функции нескольких пользователей. Когда несколько разработчиков приступят к подобным изменениям, вы можете заставить их работать заранее или попытаться синхронизировать два сценария сборки. Проблема с скриптами сборки и миграциями заключается в том, что большинство ситуаций нетривиально. Хотите отключить NULL в БД? - вам нужно решить, на какие данные должны быть дефолты, и если данные должны быть заполнены из других источников. Нужно ли рефакторировать, чтобы нормализовать таблицу на два? - вам нужно решить, как назначить ключи. И затем с двумя пользователями, внесшими изменения в ту же таблицу...

Это не означает, что он не должен находиться под контролем источника, потому что он должен.

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

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

Через некоторое время в разработку изменения базы данных становятся довольно управляемыми, поскольку изменения в базовой схеме базовой таблицы меньше (хотя просмотры и сохраненные процессы могут оставаться нестабильными).

Ответ 7

Я лично считаю, что лучше иметь отдельные базы данных. Все, работающие с одной базой данных, могут причинить много боли и времени на отходы.

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

Плюс, если я нахожусь в середине чего-то, и изменения в БД меня не знают, зная причину ошибок/неожиданного поведения для меня, я мог бы потратить столько времени, сколько нужно, прежде чем узнать об этом из-за изменений, сделал.

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