Управление изменениями БД в проекте C # - PullRequest
4 голосов
/ 08 марта 2011

У меня есть приложение C # (в VisualStudio 2010), которое использовало SqlServer 2005, доступ к которому осуществляется через TableAdapters в C #.

Я не нашел хорошего способа управлять изменениями БД.Например, в моем следующем выпуске у меня есть куча изменений схемы БД.Я внес все изменения в БД в Sql Server Management Studio.Но теперь я должен вручную внести эти изменения на производственных серверах по очереди после развертывания нового кода приложения (медленно и с ошибками).

Кроме того, если я решу откатить свой выпуск до предыдущей версии, яМне нужно вручную пройти и отменить все мои изменения в БД, прежде чем я смогу развернуть старый код (и теперь у меня есть ограничения по времени, потому что приложение не работает).Опять же, это также очень подвержено ошибкам.

О, и давайте надеяться, что одна из моих ошибок не приведет к серьезному уничтожению производственной БД, в противном случае мне теперь нужно извлечь самую последнюю резервную копию из хранилища и повторить попытку (очень много времени).

Я слышал о таких вещах, как Migrations from Rails (и ORM, таких как SubSonic).Я думаю, что новый стиль ORM (определите вашу схему в коде c #) помогает облегчить многое из этого, но, к сожалению, так как я использую TableAdapters, я не вижу, как я мог бы реализовать что-то вроде миграции.

Как люди справляются с этим?

Ответы [ 3 ]

5 голосов
/ 08 марта 2011

Управление релизами для БД обычно включает миграцию статических данных и запуск сценариев для обновления / создания элементов программируемости (sprocs, UDF, триггеры и т. Д.) И изменения существующих определений схемы. Похоже, мне не хватает сценариев. Если вы вносите изменения в свою базу данных разработки вручную, а не создаете сценарии, которые отражают эти изменения, вам нужно будет повторить те же шаги вручную для ваших тестовых / производственных сред, которые, как вы говорите, подвержены ошибкам и опасны.

SQL Server Management Studio упрощает сохранение сценариев, отражающих изменения в любых объектах базы данных. На панели инструментов должен быть значок «Создать скрипт изменения», который дает вам возможность сохранить файл SQL на диск. Затем вы можете использовать это для того же изменения на другом сервере. Вы также можете вручную написать сценарий для любого или всех сохраненных процедур, пользовательских функций, триггеров и т. Д., А также запустить их на сервере (просто щелкните по ним правой кнопкой мыши).

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

Весь этот процесс, как правило, отличается для каждой компании, но обычно это так.

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

2 голосов
/ 08 марта 2011

Самый простой способ справиться с этой проблемой - это купить программное обеспечение, которое может определять схему БД, сравнивая изменения в двух базах данных и генерируя скрипт изменений, который может обновить целевую базу данных. Я использую Visual Studio Ultimate 2010 для этого, но есть и более дешевое программное обеспечение, которое может сделать то же самое. Это работает для меня в 99% случаев (единственный случай, когда это не сработало для меня, это когда я переименовал столбец таблицы).

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

Затем, когда вы будете готовы к развертыванию программного обеспечения, выполните следующие действия:

  1. Перевести сайт в автономный режим
  2. Сделайте резервную копию вашей текущей производственной базы данных.
  3. Сделайте резервную копию вашего текущего рабочего сайта.
  4. Загрузить новый код на сервер
  5. Запустить ранее созданный сценарий изменения БД (вручную или с помощью программного обеспечения, упомянутого выше)
  6. Верните сайт в онлайн и посмотрите, работает ли он. Если это не так, и вы не можете легко решить проблему, вернитесь к предыдущему веб-сайту и версии БД, пока не исправите ошибку.

Все эти шаги можно легко автоматизировать с помощью пакетных файлов и агента сервера SQL или SQLCMD.

Как правило, сначала необходимо выполнить развертывание на промежуточном сервере, затем тщательно протестировать свой веб-сайт и только затем переходить на рабочий сервер. Таким образом вы избежите более длительных простоев на вашем производственном сервере и минимизируете риск потери любых важных данных.

0 голосов
/ 12 марта 2011

Здесь, в Red Gate Software, мы сейчас решаем эту проблему.Ознакомьтесь с нашей надстройкой SSMS Контроль исходного кода SQL в сочетании с SQL Compare Pro .Мы также работаем над функцией «Миграции», которая должна появиться позже в этом году, чтобы можно было задавать пользовательские сценарии миграции для конкретных переходов версий.Поскольку мы все еще находимся на начальных этапах проекта, у нас еще есть время, чтобы предоставили нам обратную связь и помогли нам разработать отличное решение.Мы хотели бы поговорить с вами о ваших требованиях!

...