[DevOps] Подготовка сервера сборки и создание шаблонов сборки

Что нужно сделать

Общие требования

1. Текущий сервер сборки на Jenkins ver. 2.176.2 (2019-07-17).
2. Можно использовать текущий сервер. Если он устарел, то можно подготовить новый на новой виртуальной машине. Рассматриваем возможность использования Gitlab CI\CD.
3. Сборка должна выполняться под Windows: это ограничение идет от особенности сборки компилятора для прошивок.
4. Все внесенные изменения в настройки всех сборок должны быть под системой контроля версий. Т.е. должна быть возможность посмотреть вносимые изменения и автора.
5. Необходимо, чтобы сборочный сервер можно было легко развернуть в случае необходимости на другой виртуальной машине.
6. Необходимо, чтобы была возможность управлять доступом к сборкам: редактированию, просмотру каждого билда индивидуально или по группам.

Взаимодействие с системой контроля версий исходников проекта

1. В настоящий момент в качестве системы контроля версий используем Gitlab.
2. Сервер сборки отправляет сообщение об успешной сборке на Gitlab, данное событие будет автоматически разрешать Merge request в ветку dev. При отсутствии данного подтверждения Merge request закрыть невозможно.

Этап сборки

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

Этап проведения модульного тестирования

1. Для каждого проекта существует дополнительный зависимый проект, который запускает модульные тесты.
2. Модульные тесты должны запускаться после успешной сборки артефактов проекта.

Правила формирования номера прошивки

Прошивки могут быть 3 типов:

1. Feature branch
2. Dev
3. Release

Номер прошивки присваивается системой сборки автоматически в зависимости от типа ветки. При этом мажорное и минорное числа формируются по настройкам в билде. Например, для Мажорного числа 1 и минорного 0 будет формироваться следующий номер прошивки:

1. 1.0.123-ADS-111
2. 1.0.123-dev
3. 1.0.123

Где 123 - это порядковый номер билда для данной ветки, ADS-111 - это обязательный префикс названия ветки в Gitlab, которое обязано начинаться с номера задачи, привязанной к Jira.

Если ветка не соответствует требования, то она не собирается.

Настройки билда

В настройках проекта сборки должны быть следующие параметры:

1. Формат названия ветки должен: Фильтр на первые символы веток. Например, ADS-%d. Где число может принимать только десятичное положительное значение.
2. Мажорное.Минорное числа прошивки. Например, 1.0. Данные параметры будут использоваться для проверки совместимости структур данных и форматов хранения. Этот механизм будет позволять контролировать апгрейд и даунгрейд.
3. Включить или выключить проверку модульных тестов.
4. Какие билд агенты использовать для сборки.
5. Текущий билд агент для сборки: Данный параметр должен быть доступен при запуске билда.
6. Генерация паспорта прошивки.

Правила хранения прошивок

1. Все прошивки должны храниться в течение не менее 3 лет с момента билда в специальном надежном хранилище. В этом хранилище должна быть привязка к ветке, по которой были сделаны эти билды. Лог сборки.
2. Все библиотеки должны быть расположены в репозитарии (Например, NuGet) для возможности подгрузки их в проект приложений.
3. Для всех артефактов должна быть система публикации артефактов в надежное хранилище, где она будет храниться. Можно организовать непосредственно на самом билд агенте, но только нужно настроить бекапы.
4. Для библиотеки добавляется этап выгрузки артефактов в NuGet.

Шаблоны сборки

Необходимо подготовить шаблоны сборки, которые будут облегчать подготовку новых билдов.

Шаблон создает сборку для следующих типов артефактов:

1. приложение - прошивка тахографа
2. библиотека - для интеграции в прошивку тахографа

Шаблон выполняет следующие действия:

1. Запрашивает название проекта и формирует имя проекта:

1. Для приложения формирует название: app-name
2. Для приложения формирует название: lib-name

1. Создает репозитарий в Gitlab с именем проекта.

1. В проект подключается шаблон пустого приложения с правильным именем.
2. Создается ветка dev.
3. Устанавливается ветка для интеграции dev по умолчанию.
4. По умолчанию в Gitlab на данный проект устанавливаются правила интеграции веток:
   1. Интеграция ветки в ветку dev возможна только менеджером проекта
   2. Интеграция возможна только после апрува от 3х участников проекта: один из них должен быть QA, developer-reviewer, сервера сборки.
5. Создается подпроект с модульными тестами GoogleTest для Visual Studio.

1. Создает новую сборку с привязкой к созданному Gitlab проекта.
2. Для библиотеки добавляется этап выгрузки в NuGet.