Стратегии развертывания базы данных (SQL Server)

Question

Я ищу способ ежедневного развертывания и поддержания сценариев базы данных в соответствии с выпусками.

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

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

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

Вторая проблема заключается в том, что у нас есть 4 тестовые базы данных, и они ВСЕГДА находятся вне очереди, и единственный способ действительно их восстановить - выполнить восстановление из действующей базы данных.

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

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

Любые истории, варианты использования или даже ссылки будут полезны.

Answer 1

Я написал инструмент на основе .NET для автоматического управления версиями базы данных. Мы использовали этот инструмент в производстве для обработки обновлений баз данных (включая исправления) для нескольких сред, ведения журнала в каждой базе данных, какие сценарии были запущены, и делали все это в автоматическом режиме. Он имеет консоль командной строки, поэтому вы можете создавать пакетные сценарии, которые используют этот инструмент. Проверьте это: https://github.com/bmontgomery/DatabaseVersioning

Answer 2

В Red Gate есть документ, описывающий, как добиться автоматизации сборки: http://downloads.red -gate.com / HelpPDF / ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Это построено на SQL Source Control , который интегрируется с SSMS и вашей существующей системой управления источниками.

Answer 3

Одно из возможных решений - изучить внедрение аудита DML в тестовых базах данных, а затем просто свернуть эти журналы аудита в сценарий для окончательного тестирования и оперативного развертывания. SQL Server 2008 значительно улучшает аудит DML, но даже SQL Server 2005 поддерживает его с помощью триггеров.

Answer 4

Книга Рефакторинг баз данных решает многие из этих проблем на концептуальном уровне.

Что касается инструментов, я знаю, что DB Ghost хорошо работает для SQL Server. Я слышал, что версия Visual Studio Data Dude действительно была улучшена в последней версии, но у меня нет никакого опыта с этим.

Поскольку процесс создания базы данных в режиме непрерывной интеграции действительно требует значительных усилий, он становится действительно ресурсоемким и очень быстрым из-за необходимого количества копий базы данных. Это очень выполнимо, когда база данных может поместиться на рабочей станции разработчика, но нецелесообразно, когда база данных настолько велика, что ее необходимо развернуть в сетке. Для этого вам нужно по одной копии базы данных на разработчика [разработчики, которые вносят изменения в DDL, а не только в procs] + 6 общих копий. Общие копии следующие:

1. INT DEV -> Разработчики проверяют свой рефакторинг в INT DEV для тестирования интеграции. Когда тестирование интеграции проходит, эта база данных копируется в DEV.
2. DEV -> Это "официальная" копия разработки базы данных. INT DEV регулярно обновляется копией DEV. Разработчики, работающие над новыми рефакторингами, получают свежую копию базы данных от DEV.
3. INT QA -> Та же идея, что и INT DEV, за исключением команды QA. Когда здесь проходят интеграционные тесты, эта база данных копируется в QA и в DEV *.
4. QA
5. INT PROD -> Та же идея, что и INT QA, за исключением производства. Когда здесь проходят интеграционные тесты, эта база данных копируется в PROD, QA * и DEV *
6. PROD

* При копировании баз данных по линиям DEV / QA / PROD вам также потребуется запустить сценарии для обновления тестовых данных, относящихся к конкретной среде (например, настройка пользователей в QA, которые команда QA использует для тестирования, но которые существуют в производстве).

Answer 5

В этих сообщениях есть куча ссылок, за которыми я хочу продолжить (я "катал свою собственную" систему несколько лет назад, должен посмотреть, есть ли сходства). Одна вещь, которая вам понадобится, и которую я надеюсь упомянуть в этих ссылках, это дисциплина. Я не совсем понимаю, как может работать любая автоматизированная система, если кто-то может что-то изменить в любое время. (Ваш вопрос подразумевает, что это может произойти в ваших производственных системах, но, очевидно, это не может быть правдой.)

Назначение одного человека (легендарного «администратора базы данных») для управления изменениями в базах данных, в частности в производственных базах данных, является очень распространенным решением. Что касается поддержания согласованности в базах данных разработки и тестирования X: если они / они используются многими пользователями, то опять же вам лучше всего выступить в качестве «расчетной палаты» для изменений; если у каждого есть свой экземпляр базы данных, он отвечает за поддержание его в порядке, и наличие централизованного согласованного «источника» базы данных будет иметь решающее значение, когда им потребуется обновленная базовая база данных.

Вот недавняя публикация переполнения стека, которая может представлять интерес: как обновлять тестовый экземпляр sql-сервера-с-производственными данными-без использования