Автоматизация схемы базы данных Visual Studio Сравнение и проверка на GIT

Question

У меня есть проект DB Visual Studio 2015 для базы данных SQL Server, где я могу сравнить сравнение и сравнение схемы и проверить проект в GIT вручную. Я хотел автоматизировать этот полный процесс сравнения схем/данных, сгенерировать скрипты и проверить их в GIT. Можно ли это сделать? Если да, то как?

Может быть, я сделаю что-нибудь подобное? Automating Visual Studio with EnvDTE

Answer 1

Добро пожаловать в мир управления жизненным циклом базы данных (DLM).Это довольно большая тема, я сделаю все возможное, чтобы это было как можно короче.

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

Существует ряд инструментов Microsoft, сторонних разработчиков и с открытым исходным кодом, которые помогают вам создавать сценарий вашей базы данных и получать ее в Git (или любую другую систему управления версиями). Некоторые из наиболее популярных - SSDT, Redgate SQL Source Control, Redgate ReadyRoll, Flyway, DBup, Liquibase и DB Maestro, но есть и многие другие.

Упаковка и развертывание этого исходного кода абсолютно автоматизированы. Для автоматизации большинство людей используют инструмент автоматизации (или конвейер инструментов), такой как TeamCity, TFS/VSTS, Jenkins и/или Octopus Deploy для упаковки исходного кода и (необязательно) его развертывания в базу данных (или несколько баз данных). Это может быть сделано либо с фиксацией, либо нажатием одной кнопки. Конечно, точно, как это все работает (и как хорошо все это работает) будет зависеть от используемых вами инструментов.

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

Однако, использование источника базы данных и автоматизация процесса выпуска являются фантастически ценными, поэтому я призываю вас продолжать работу. Из вашего вопроса ясно, что вы хотите улучшить свои процессы. :-)

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

• Automating with SSDT (Microsoft) < - Блог сообщение от Phil фактор
• Redgate ReadyRoll (Третья сторона)
• FlyWay (с открытым исходным кодом)

Отдельно кажется вам имеют аудиторскую озабоченность. Отслеживание изменений, которые происходят непосредственно на производстве, например, когда люди делают горячие исправления, не проходя контроль источника. Есть еще одна отличная запись в блоге Phil Factor на эту тему, которая подробно описывает how to create your own automated process for tracking drift. Однако, если бы я был вами, я бы посмотрел на Redgate DLM Dashboard. Это сторонний инструмент, но он свободен, поэтому зачем тратить время на повторное изобретательство колеса?

Если вам нужна дополнительная поддержка/обучение моей компании, DLM Consultants, работает weekly online workshops (в партнерстве с Redgate), где вы получите практическую настройку управления исходным кодом, CI и процессов управления выпуском для SQL Server.

Answer 2

Возможно, вам придется немного пересмотреть свой подход.

В общем, рабочий процесс

Внесение изменений в базу данных -> Project Update Database -> Commit Changes в систему управления версиями

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

Если это был проект .NET, вы бы исправляли двоичные файлы на сервере с помощью шестнадцатеричного редактора, а затем декомпилировали результаты в файлы csproj и связанные с ними файлы cs для хранения в исходном элементе управления? Это звучит смешно, но это похоже на рабочий процесс, который вы предлагаете для своих проектов баз данных.

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

Вносите изменения в производстве -> Update Control Source

IMV, Вы, вероятно, следует искать, чтобы решить «источник контроля "и" аудита "отдельно.

Для этого (с помощью SSDT) ​​необходимо обновить проект базы данных вручную после и добавить полученные файлы в исходный код.

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

Предположительно это всего лишь подмножество данных в базе данных - «статические» или «ссылочные» данные - которые нужно хранить в исходном элементе управления? Наиболее распространенный способ сделать это - использовать сценарии после развертывания в проекте базы данных.

Что касается аудита, у вас есть несколько вариантов. Учитывая, что история ваших «преднамеренных» изменений будет в контроле источника, основная проблема аудита заключается в обнаружении неконтролируемого изменений в производстве. Это можно сделать с помощью триггеров базы данных или, я полагаю, некоторыми коммерческими продуктами (которые обычно используют триггеры базы данных за кулисами). При обнаружении таких изменений у вас есть несколько вариантов - откат изменений, запуск DBA, обновление файлов в исходном управлении и т. Д. И т. Д. Я не уверен, что разумно автоматизировать эту часть процесса, так как вы вероятно, захочет рассмотреть , почему эти изменения произошли.