должны ли изменения в БД всегда быть частью КИ? - PullRequest
4 голосов
/ 27 июля 2011

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

Should changes to the database be part of the CI script?

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

Существует ли документ по "передовому опыту" для КИ, который ответил бы на этот вопрос? Это то, что обсуждается среди тех, кто увлечен КИ?

Мнение Мартина Фаулера об этом:

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

Ответы [ 2 ]

2 голосов
/ 27 июля 2011

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

Мне очень нравится использовать функциональные возможности Visual Studio 2010 Premium для обработки схемы базы данных.Это делает схему базы данных частью структуры проекта, имея основную схему под управлением исходного кода.Свежая база данных может быть создана прямо из проекта.Сценарии обновления для подъема существующих баз данных в новую схему генерируются автоматически.

Правильное выполнение управления изменениями для баз данных без VS2010 Premium или аналогичного инструмента в лучшем случае будет болезненным, если вообще возможно.Если у вас нет поддержки этого инструмента, я могу понять вашего коллегу, который хочет не допустить КИ в БД.Если у вас есть проблемы, требующие включения БД в CI, то, возможно, стоит сначала получить набор инструментов спуска для работы с БД?Если у вас есть нужные инструменты, это естественный шаг для включения БД в CI.

0 голосов
/ 27 июля 2011

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

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

Это, конечно, нелегкий предмет. В проекте, в котором я работаю, мы используем alter скрипты, которые необходимо проверить вместе с изменениями исходного кода. Эти сценарии выполняются в нашей тестовой базе данных, чтобы гарантировать не только правильность текущей сборки, но также и то, что возможно обновление / понижение одной версии вверх / вниз, а сам процесс обновления ничего не портит. Я считаю, что это лучшее решение, чем удаление и воссоздание всей базы данных, оно позволяет вам иметь последовательный путь для постепенного обновления базы данных и позволяет использовать базу данных в некоторой тестовой среде - с данными, пользователями и т. Д.

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