Версионирование кода и выпуск релизов для MSSQL

Одним из таких инструментов является Bitbucket - инструмент версионирования кода от компании Atlassian.

Для организации версионирования кода SQL, компанией Microsoft разработан стандарт проектов Visual Studio “Database Project”, об использовании которого мы расскажем в данной статье.

Необходимые инструменты, установка и настройка

1. Visual Studio 2019

a) Плагин Visual Studio Bitbucket Extension
b) Плагин Microsoft Analysis Services Projects
c) SQL Server Data Tools
d) SQL Server ODBC Driver

Список расширений Visual Studio для установки:

Для работы с Bitbucket через плагин потребуется создать персональный аккаунт - в нём необходимо сгенерировать пароль для приложения.
Настройки Bitbucket:

Пароль приложения Bitbucket:

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

2. Git
- для работы с удаленными репозиториями через командную строку ОС.
После установки и подключения аккаунта необходимо выдать соответствующие права доступа к целевому репозиторию - добавить пользователя в соответствующую группу в разделе настроек репозитория ”Repository permissions”, после чего добавить пользователя в разделе “Branch restrictions” на необходимые основные ветки - master, test и dev.

Настройки репозитория Bitbucket:

Далее необходимо открыть репозиторий локально через Visual Studio - для этого надо склонировать репозиторий командой git clone в командной строке - нужный запрос генерируется по нажатию кнопки “Clone” на главной странице репозитория:

В удобной для пользователя локальной директории, в склонированном репозитории, открыть файл с типом “sln” Ниже представлен список веток:

В проекте подключиться через аккаунт Bitbucket, в разделе “Git”открыть “Manage Branches” - откроется список удалённых и локальных веток репозитория.

Работа в репозитории
Правила создания веток

Ветка master соответствует состоянию кода на prod-инстансах.
Ветка test - соответствует состоянию кода на тестовом окружении.
Ветка dev - соответствует состоянию кода на дев-окружении.

В нашем проекте расписание релизов определяется менеджером проекта на текущий год. Под каждый релиз в репозитории от ветки dev создаётся соответствующая ветка (например release/1.0.31):

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

• feature/#NNNNN – внедрение нового функционала,
• bugfix/#NNNNN – исправление “бага”,
• hotfix/#NNNNN – внесение “хотфикса”.
где “#NNNNN” номер задачи.

Слияние веток и разрешение конфликтов

Пулл-реквесты со всех дочерних задач сливаются (“мержатся”) в релизную ветку. Релизные ветки сливаются в ветку dev. При старте тестирования релиза все изменения из ветки dev сливаются в ветку test и в активные релизные ветки - для поддержания актуальности кода в них. После окончания тестирования и выпуска в релиз изменения из ветки test сливаются в master.

При слиянии возникают мерж-конфликты в случае, если одни и те же строки в одном и том же файле редактировались в разных задачах. В таком случае конфликт необходимо разрешать мануально.
Для слияния ветки необходимо:

1. Скопировать ветку из удалённого репозитория на локальную машину - для этого достаточно на неё переключиться в разделе “Remotes”.
2. Переключиться на ветку, в которую будет производиться слияние.
3. Во вкладке “Git”->”Merge Branches” найти ветку из пункта 1, нажать ПКМ и выбрать “Merge ‘branch X’ into ‘branch Y’”

Слияние ветки:

Пауза при слиянии ветки:

В случае мерж-конфликта его необходимо разрешить мануально - для этого нужно во всех файлах в разделе “Unmerged Changes” разрешить все конфликты. На рисунке ниже приведён пример слияния ветки dev в ветку test. В левой части экрана отмечаются изменения из ветки, которую сливают. В правой части экрана отмечаются изменения в текущей ветке. В нижней части экрана приводится результирующий текст - его можно редактировать вручную. Разрешение конфликта:

После разрешения всех конфликтов пишется комментарий к коммиту и мерж-коммит пушится в удалённый репозиторий.

Сборка патча и установка на инстанс

Для корректной сборки патча на одном из dev-окружений должны быть развёрнуты актуальные структуры и скрипты процедур. В случае, когда разные релизы одновременно собираются на разных базах, имеет смысл обновлять одну из dev-баз скриптами из актуальной ветки dev.
Для сборки патча из Database Project необходимо в Visual Studio во вкладке “Tools” выбрать “New Schema Comparison” в разделе “SQL Server”.

В открытом интерфейсе сравнения необходимо будет указать источник и цель сравнения:

После нажатия “Compare” в заголовке интерфейс, необходимо будет вручную выбрать те изменения, которые войдут в собираемый релиз.

После выбора всех нужных изменений по нажатию “Generate Script” сгенерируется скрипт развёртывания.

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

После получения текста скрипта необходимо поменять местами в сравнении источник и цель и сформировать скрипт отката на случай экстренной ситуации.

Полученный скрипт запускается на БД для тестового окружения в соответствии с расписанием релизов (которое определяется менеджером).
Скрипт необходимо обновлять в случае исправлений ошибок патча, выявленных в ходе тестирования.
После окончания тестирования патча актуальный скрипт запускается на БД инстансов в соответствии с расписанием релизов и в тесном взаимодействии с тимлидом web-разработки.
Полученные логи при установке скрипта рекомендуется просматривать на наличие предупреждений и ошибок - в некоторых ситуациях (например, когда процедура не компилируется на инстансе с устаревшей версией SQL Server) необходимо срочное ручное исправление устанавливаемой процедуры. Некоторые ошибки не критические, и их можно разрешать позже - крайне рекомендуется сохранять логи с установки на каждый инстанс локально. Это поможет не только отследить возможные ошибки, но и понимать, когда и какой инстанс действительно был обновлён, и какие изменения на нём применились.

Лог установки: