Как управлять и получить изменения базы данных через несколько разработчиков?
У нас есть три разработчика и один тестер вся работа против той же базы данных. Мы изменяем схему базы данных довольно часто, и каждый раз, когда мы делаем она имеет тенденцию иметь волновой эффект головных болей для всех остальных.
Есть ли хорошие методы на месте для ориентированной разработки.NET против SQL Server MS 2008 для управления этим? Я думаю, что-то подобное Миграциям направляющих и каждому dev и тестеру имеет их собственную локальную базу данных. Или то излишество? По крайней мере, было бы хорошо иметь отдельный тест и dev базы данных, но в настоящее время вручную хранение двух баз данных в синхронизации, вероятно, хуже, чем наше текущее затруднительное положение.
LiquiBase кажется обещанием, кто-либо успешно использовал его в аналогичной среде? Или есть ли лучшие подходы?
Мы используем SQL Server 2008, VS 2008 и.NET 3.5, если это имеет значение вообще.
7 ответов
У нас есть сценарии для создания БД с нуля, и это то, что находится в системе контроля версий. Каждый разработчик (20 из них) - это используя скрипт для создания 2 баз данных на своих рабочих станциях. Один для «работы» - ручное тестирование с примерами данных в нем (есть скрипт для заполнения эталонных данных). Другая БД пуста и используется в модульных тестах (открытая транзакция - выполнение модульного теста - откат).
Модульные тесты являются обязательными в среде с несколькими разработчиками. Также мы всегда создаем «старую» базу данных и применяем к ней изменения схемы. Каждый разработчик меняет схему, создавая процедуры обновления (это то, как мы одновременно перестраиваем и обновляем готовые).
Для тестирования производительности у нас есть «загрузчики» - код C # для моделирования пользователей и заполнения миллионов записей за ночь на рабочих станциях разработчиков.
Visual Studio Team System Database Edition (он же Data Dude) заслуживает внимания. Он может отслеживать различия в базе данных и генерировать сценарии изменений, чтобы вы могли подготовить среду test / prod перед развертыванием и т. Д. Я думаю, что его функции также доступны в версии для разработчиков (см. Предыдущую ссылку), а в VS 2010 будут более заметными. Взгляните на это сообщение в блоге: Первый опыт работы с Visual Studio 2008 Database Edition, мне это нравится !!!
Это, наряду с TFS, дает вам возможность управлять версиями файлов SQL и запускать их в базе данных.
Хорошая ссылка на несколько хороших ссылок: http://www.codinghorror.com/blog /2008/02/get-your-database-under-version-control.html
Я нахожусь в лагере "одна база данных для разработчиков".
В отличие от традиционного объектно-ориентированного исходного кода, база данных часто содержит таблицы, поддерживающие функции нескольких пользователей. Когда несколько разработчиков собираются внести аналогичные изменения, вы можете попросить их проработать это заранее или попытаться синхронизировать два сценария сборки. Проблема со сценариями сборки и миграциями заключается в том, что большинство ситуаций нетривиальны. Хотите запретить NULL в БД? - вам нужно решить, какие данные следует использовать по умолчанию и должны ли данные быть заполнены из другого места. Требуется рефакторинг, чтобы разделить таблицу на две части? - вам нужно решить, как назначить ключи. А затем, когда два пользователя вносят изменения в одну и ту же таблицу ...
Это не значит, что она не должна находиться в системе контроля версий, потому что должна.
В конечном итоге, поскольку у вас будет больше разработчиков и больше каналов связи, вы захотите, чтобы изменения в вашей базе данных проходили через администратора баз данных - это позволяет координировать изменения и позволяет избежать многих проблем с каналами связи в команде - это превращает каналы связи в звезду.
Кроме того, если вы ограничиваете свое программирование явным уровнем служб базы данных, таким как представления и хранимые процедуры, разработчики ваших приложений будут хорошо защищены от изменений базы данных и рефакторинга.
По прошествии определенного времени в разработке, изменения в базе данных становятся довольно управляемыми, поскольку изменений в базовой схеме таблицы меньше (хотя представления и сохраненные процессы могут оставаться непостоянными).
Я лично считаю, что лучше иметь отдельные базы данных. Работа с одной базой данных может причинить много боли и привести к потере времени.
Например, я изучаю проблему производительности и запускаю несколько эталонных тестов, чтобы проверить некоторые оптимизации базы данных - единственный способ сделать это надежно, если вы будете последовательны в своих тестах. Если кто-то другой внесет изменения в БД на полпути, это может исказить ваши результаты.
К тому же, если я нахожусь в середине работы, а БД меняется без моего ведома, вызывая ошибки/неожиданное поведение для меня, я могу потратить х количество времени на работу, прежде чем выяснится, что это связано с изменением, которое сделал кто-то другой.
Вместо этого, я думаю, гораздо лучше иметь свои собственные базы данных dev/test, за обновление которых вы можете отвечать каждый. Затем иметь сервер непрерывной интеграции, который автоматически извлекает последний код из контроля исходного кода и собирает его каждые x часов.
Мы не используем инструмент как таковой, но мы держим всю нашу схему в системе контроля версий, а затем у нас есть сценарий, который обновит или перестроит база данных из источника. Таким образом, после внесения изменений мы все сможем обновляться и оставаться в синхронизации. Это просто становится частью повседневной утренней рутины, занимает около 5 минут, как и синхронизация вашего кода. Это не идеально, но для нас это работает.
Да, и я забыл добавить, что если вы вносите изменения в схему, вы также несете ответственность за написание сценария миграции, если он необходим. Это, как правило, необходимо в любом случае, когда что-то попадает в производство.
Надеюсь, что это поможет.
Похоже, вам нужен инструмент сравнения базы данных для создания и сохранения изменений в базе данных ...