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

Для работы с 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) необходимо срочное ручное исправление устанавливаемой процедуры. Некоторые ошибки не критические, и их можно разрешать позже - крайне рекомендуется сохранять логи с установки на каждый инстанс локально. Это поможет не только отследить возможные ошибки, но и понимать, когда и какой инстанс действительно был обновлён, и какие изменения на нём применились.

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