Управление базой данных SQL Server с непрерывной интеграцией

Question

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

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

Answer 1

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

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

Вот некоторые ключевые выводы:

• Во многих магазинах код проверяется модулем в момент фиксации. Для баз данных предпочтительно запускать все модульные тесты одновременно и последовательно с базой данных QA, против разработки, как часть шага Test
• Этап тестирования является важной частью любого процесса CI / CD. Сценарии тестирования, включая сами модульные тесты, также должны быть версионированы в системе контроля версий, извлечены в точке шага сборки и выполнены
• Извлечение данных из производства привлекательно как быстрый способ, но никогда не является хорошей идеей
• Наилучшим подходом является использование инструмента или скрипта для быстрого, многократного и надежного создания синтетических тестовых данных для ваших транзакционных таблиц
• Запуск модульных тестов для получения сводных результатов по потреблению человеком отрицательно сказывается на цели автоматизации. Нам нужны машиночитаемые результаты, которые могут позволить автоматическому процессу прервать, разветвить и / или продолжить.
• Выполнение процесса CI, для которого требуется 100% всех испытаний, похоже на отсутствие CI вообще, если конвейер рабочего процесса настроен атомарно для остановки при сбое, что и должно быть. Чтобы заправить иглу, тесты должны иметь встроенные пороговые значения, которые будут вызывать ошибку, основанную либо на проценте неудачных тестов, либо в некоторых случаях, если некоторые тесты с высоким приоритетом не пройдут.
• В конечном итоге все процессы должны давать логический результат прохождения или сбоя, но некоторые неавтоматизированные процессы могут легко найти свой путь в конвейер рабочего процесса CI (например, модульное тестирование). Программное обеспечение должно быть plug-n-play в любой конвейер рабочего процесса, принимая известные входные данные и создавая ожидаемые результаты - например, pass, fail.
• Процесс CI / CD должен быть прерван в случае сбоя, и электронное письмо с уведомлением должно быть немедленно отправлено против продолжения цикла конвейера.
• Процесс CI не должен повторяться, пока не будут исправлены ошибки в последней сборке. В случае неудачи вся команда должна получить уведомление об ошибке, включая как можно больше подробностей о том, что не удалось.
• Если конвейеру от начала до конца требуется 1 час до завершения, включая все тесты, тогда все интервалы сборки должны быть установлены не менее одного часа, а все новые коммиты должны быть поставлены в очередь и применены к следующему строить.
• В сценариях автоматизации не должно быть паролей в виде простого текста

Answer 2

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

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

Answer 3

Вы смотрели на FluentMigrator ? Загрузка по умолчанию включает в себя сценарии Nant, которые было бы легко добавить в CI. Бесплатный, с открытым исходным кодом и простой в использовании. Работает для широкого спектра баз данных.

Answer 4

Red Gate - довольно надежное решение, и оно работает «из коробки». Но самое приятное, что вы можете интегрировать его в процесс непрерывной интеграции. Я использую это с Msbuild и Hudson. быстро объясним, как это работает: http://blog.vincentbrouillet.com/post/2011/02/10/Database-schema-synchronisation-with-RedGate

если вам нужно узнать больше об этом, не стесняйтесь спрашивать

Answer 5

Подход Red Gate с использованием SQL Source Control и командной строки SQL Compare Pro подробно описан с примерами кода: http://downloads.red -gate.com / HelpPDF / ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Трой Хант написал статью о Simple Talk под названием «Непрерывная интеграция для баз данных SQL Server»: http://www.simple -talk.com / содержание / article.aspx? Статья = 1247

Answer 6

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

Вот версия с нотами обрыва, чтобы намочить ноги, но в этом месте есть много: http://www.infoq.com/news/2008/02/versioning_databases_series

Мне также нравятся некоторые идеи, которые есть у Скотта Амблера, сайт хороший, но книга удивительно глубока для такого сложного набора проблем. http://www.agiledata.org/ http://www.amazon.com/exec/obidos/ASIN/0321293533/ambysoftinc

Answer 7

Я знаю, что этот пост старый, но у нас есть новое решение, которое использует следующий подход:

1. Разработчики пишут индивидуальные изменения SQL и фиксируют их в исходном коде. контроль.
2. Наша программа ( OneScript ) извлекает файлы сценариев изменений из Управление исходным кодом, фильтрует и сортирует их, а также генерирует единый файл сценария выпуска
3. Этот файл сценария выпуска затем применяется к база данных, чтобы сделать релиз.

Наша домашняя страница здесь объясняет этот процесс более подробно и содержит ссылку на пример, который выполняет эти шаги автоматически из ловушки Subversion. Поэтому вскоре после коммита разработчик получает электронное письмо с сообщением, был ли релиз успешным или имел ошибки. Код PowerScript включен.

Отказ от ответственности - Я работаю в компании, которая делает OneScript.

Answer 8

Последняя версия (5.0) DB Ghost не страдает от проблемы «не ASCII-символов» (это просто означает, что файл имеет кодировку UTF8), и она должна иметь возможность делать именно то, что вам нужно.

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

По сути, для внесения изменений в схему вы обновляете сценарии создания отдельных объектов и сценарии вставки для каждой таблицы (для справочных данных), которые находятся под контролем исходного кода, так же, как вы разрабатывали базу данных «с первого дня». Инструменты DB Ghost используются для включения всего этого путем встраивания этих сценариев в совершенно новую базу данных (с использованием непрерывной интеграции при необходимости), а затем сравнения и обновления целевой базы данных, которая может быть копией рабочей базы данных. Этот процесс создает дельта-скрипт, который можно использовать в реальной производственной базе данных во время запуска.

Вы даже можете создать проект базы данных Visual Studio и добавить его в любые имеющиеся у вас решения.

Malc