Проверьте изменения базы данных (управление версиями)

Мы используем DBGhost для контроля версий база данных. Сценарии для создания текущей базы данных хранятся в TFS (вместе с исходным кодом), а затем DBGhost используется для создания дельта-сценария для обновления среды до текущей версии. DBGhost также может создавать дельта-скрипты для любых статических / справочных / кодовых данных.

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

Сценарии для создания текущей базы данных хранятся в TFS (вместе с исходным кодом), а затем DBGhost используется для создания дельта-сценария для обновления среды до текущей версии. DBGhost также может создавать дельта-скрипты для любых статических / справочных / кодовых данных.

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

Сценарии для создания текущей базы данных хранятся в TFS (вместе с исходным кодом), а затем DBGhost используется для создания дельта-сценария для обновления среды до текущей версии. DBGhost также может создавать дельта-скрипты для любых статических / справочных / кодовых данных.

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

Похоже, вы нарушаете первое и второе правило " Три правила работы с базами данных ". Использование одной базы данных на разработчика и единого авторитетного источника для вашей схемы уже очень поможет. Тогда я не уверен, что у вас есть Baseline для вашей базы данных и, что еще более важно, что вы используете сценарии изменения . Наконец, вы можете найти другие ответы в представлениях, хранимых процедурах и т.п. и в ветвлении и слиянии .

Фактически, все эти ссылки упоминаются в этой замечательной статье Джеффа Этвуда: Получите вашу базу данных под контролем версий . Обязательно прочтите ИМХО.

Я использую простой файл VBScript, основанный на этой статье проекта , чтобы сгенерировать сценарии удаления / создания для всех объектов базы данных. Затем я помещаю эти скрипты в систему контроля версий.

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

• получаю последнюю версию drop / создать сценарии из системы контроля версий (в нашем случае - подрывная деятельность)
• выполнить сценарий SqlExtract для проверяемой базы данных, перезаписав сценарии из системы контроля версий
• , теперь я могу проверить с помощью своего клиента подрывной деятельности (TortoiseSVN), какие файлы не работают. t соответствует версии, находящейся под контролем версий
• , теперь либо обновите базу данных, либо поместите измененные скрипты под контроль версий

Надеюсь, у кого-то есть лучшее решение, чем это, но я делаю это с помощью пары методов:

• Иметь "магистральную" базу данных, текущая разрабатываемая версия. Здесь выполняется вся работа, поскольку он готовится к включению в выпуск.
• Каждый раз, когда выпуск выполняется:
  • "Чистая" база данных последнего выпуска копируется в новую, например, "DB_1.0.4_clean"
  • SQL-Compare используется для копирования изменений из ствола в 1.0.4_clean - это тоже позволяет точно проверить, что включено.
  • SQL Compare снова используется для поиска различий между предыдущим и новым выпусками (изменения с DB_1.0.4_clean на DB_1.0.3_clean), что создает сценарий изменения «1.0.3 на 1.0 .4.sql ".

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

У меня нет этой проблемы, но было бы тривиально защитить базы данных _clean от модификации другими членами команды. Кроме того, поскольку я использую SQL Compare для создания сценариев изменений, разработчикам нет необходимости отслеживать их по ходу выполнения.

• Мы действительно занимались этим какое-то время, и это было ОГРОМНОЙ болью. Об этом было легко забыть, и в то же время вносились изменения, которые не обязательно вносили изменения, поэтому сценарий полного обновления, созданный с использованием индивидуально созданных сценариев изменений, иногда добавлял поле, а затем удалял его, все в один выпуск. Это, очевидно, может быть довольно болезненным, если есть изменения индекса и т. Д.

Хорошая вещь в сравнении SQL - это то, что сценарий, который он генерирует, находится в транзакции, и в случае неудачи он откатывает все назад. Поэтому, если производственная БД была каким-то образом изменена, обновление не удастся а затем группа развертывания может фактически использовать SQL Compare в производственной БД с _clean db и вручную исправить изменения. Нам пришлось сделать это всего один или два раза (проклятые клиенты).

Скрипты изменений .SQL (сгенерированные SQL Compare) сохраняются в нашей системе контроля версий (подрывная деятельность).

Первый момент: сложно поддерживать порядок без «правил». Или, к вашему примеру, разработчики, изменяющие что-либо без уведомления, приведут к серьезным проблемам.

Как бы то ни было - вы говорите «без использования триггеров». Есть ли конкретная причина для этого?

Если нет - ознакомьтесь с DDL-триггерами. Такие триггеры - самый простой способ проверить, произошло ли что-то.

И вы даже можете записать, ЧТО происходило.

Если у вас есть Visual Studio (в частности, версия базы данных), есть проект базы данных , который вы можете создать и направить на базу данных SQL Server. Проект загрузит схему и в основном предложит вам множество других функций. Он ведет себя так же, как проект кода. Он также предлагает вам преимущество создания сценария для всей таблицы и ее содержимого, чтобы вы могли сохранить их в Subversion. Когда вы строите проект, он проверяет целостность базы данных. Это довольно умно.

Вы должны ограничить доступ ко всем базам данных и предоставить разработчикам доступ только к локальной базе данных (где они разрабатывают) и к серверу разработки, где они могут выполнить интеграцию. Лучше всего для них иметь доступ только к своей области разработки локально и выполнять задачи интеграции с помощью автоматизированной сборки. Вы можете использовать такие инструменты, как redgates sql compare, чтобы делать различия в базах данных. Я предлагаю вам держать все свои изменения в системе контроля версий (файлы .sql), чтобы у вас была текущая история того, кто что и когда делал, и чтобы вы могли при необходимости отменить изменения базы данных.

Мне также нравится иметь возможность чтобы разработчики запустили локальный скрипт сборки, чтобы повторно запустить свой локальный ящик разработчика. Таким образом, они всегда могут откатиться. Что еще более важно, они могут создавать интеграционные тесты, которые автоматически проверяют внутреннее устройство своего приложения (репозиторий и доступ к данным) и логику, спрятанную в хранимой процедуре. Выполняется инициализация (сброс db), интеграционные тесты (создание мусора в db), повторная инициализация для возврата db в чистое состояние и т. Д.

Если вы являетесь пользователем стиля SVN / nant (или аналогичным) с одним концепция ветки в вашем репозитории, тогда вы можете прочитать мои статьи по этой теме на DotNetSlackers: http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Build-automation-with -NAnt.aspx и http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Continuous-integration-with-CruiseControl-NET.aspx .

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

UPDATE

@Sazug: «Да, мы используем что-то вроде сборок с несколькими ветвями, когда мы используем базовый сценарий + дополнительные сценарии :) Какие-нибудь базовые советы для такого рода автоматизации без полной статьи? " Чаще всего существуют две формы баз данных:

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

Первый набор up намного проще и может быть полностью автоматизирован от разработки к продукту, а также может включать откат продукта, если это необходимо. Для этого вам просто понадобится папка сценариев, в которой каждое изменение вашей базы данных может храниться в файле .sql. Я не Я предлагаю вам сохранить файл tablename.sql, а затем создать его версию, как файл .cs, где обновления этого артефакта sql фактически изменяются в том же файле с течением времени. Учитывая, что объекты sql очень сильно зависят друг от друга. Когда вы создаете свою базу данных с нуля, ваши скрипты могут столкнуться с критическими изменениями. По этой причине я предлагаю вам сохранить отдельный и новый файл для каждой модификации с порядковым номером перед именем файла. Например, что-то вроде 000024-ModifiedAccountsTable.sql. Затем вы можете использовать настраиваемую задачу или что-то из NAntContrib или прямое выполнение одного из многих инструментов командной строки SQL.exe для запуска всех ваших скриптов в пустой базе данных от 000001-fileName.sql до последнего файла. в папке updateScripts. Затем все эти сценарии возвращаются в систему контроля версий. И поскольку вы всегда начинаете с чистой базы данных, вы всегда можете выполнить откат, если кто-то новый sql нарушит сборку.

Во второй среде автоматизация не всегда лучший путь, учитывая, что вы можете повлиять на производство. Если вы активно разрабатываете для / для производственной среды, то вам действительно нужна среда с несколькими ветвями / средой, чтобы вы могли протестировать свой способ автоматизации, прежде чем вы действительно столкнетесь с производственной средой. Вы можете использовать те же концепции, что указаны выше. Однако вы не можете начать с нуля на prod db, и откат назад сложнее. По этой причине я предлагаю использовать RedGate SQL Compare или аналогичные в процессе сборки. Файл. sql-скрипты регистрируются для целей обновления, но вам необходимо автоматизировать разницу между промежуточной базой данных и производственной базой данных перед запуском обновлений. Затем вы можете попытаться синхронизировать изменения и откатить продукт, если возникнут проблемы. Кроме того, перед автоматической отправкой изменений sql следует выполнить некоторую форму резервного копирования. Будьте осторожны, делая что-либо без бдительного человеческого глаза на производстве! Если вы выполняете настоящую непрерывную интеграцию во всех ваших средах разработки / качества / подготовки / производительности, а затем выполняете несколько ручных действий при переходе к производству ... это действительно не так уж плохо!

В одном из наших проектов мы сохранили версию базы данных внутри базы данных.

Каждое изменение структуры базы данных записывалось в отдельный файл sql, который увеличивал версию базы данных, помимо всех других изменений. Это было сделано разработчиком, который изменил структуру базы данных.

Сценарий развертывания проверил текущую версию базы данных и скрипт последних изменений и применил эти сценарии sql при необходимости.

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

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

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

Когда вносятся изменения,

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

Здесь, в Red Gate, мы вскоре собираемся выпустить новый инструмент, SQL Source Control, предназначенный для превращения этого процесса в намного проще. Мы интегрируемся в SSMS и включим добавление и извлечение объектов в систему управления версиями и из нее одним нажатием кнопки. Если ты' Если вы хотите узнать больше или подписаться на нашу Программу раннего доступа, посетите эту страницу:

http://www.red-gate.com/Products/SQL_Source_Control/index.htm

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