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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Похоже, вам нужен инструмент сравнения базы данных для создания и сохранения изменений в базе данных ...

Red Gate SQL Compare

Visual Studio Team Database Edition

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

Хорошая ссылка некоторые хорошие ссылки: http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-control.html

Answer 7

Я нахожусь в лагере «один базы данных развития».

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

Это не говорит о том, что это не должно быть под контролем источника, потому что это должно быть.

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

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

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