DevOps

Команда

git

Требования к исходному коду

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

Тип	Паттерн
Сервисы Фронта	ui-service-name
Сервисы Бека.	ms-service-name
Библиотеки.	lib-library-name

Все репозитории проекта обязательно должны содержать файлы:

.gitignore
readme.md

Dokerfile должен хранится в корне проекта. Для сборки контейнеров разрешены только базовые образы AstraLinuxSE.

readme.md должен содержать информацию о сервисе, в части переменных и процесса сборки и запуска.

Примеры

Dockerfile

ARG DOCKER_REGISTRY=
FROM ${DOCKER_REGISTRY}/astra/alse-1.7.4-openjdk:11.0.2
COPY target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","app.jar"]

.gitignore

.idea
*.iml
.DS_Store
/target
/log
/data/
/openapi/*.json

readme.md

# MS SERVICE NAME
## Сборка
Для сборки сервиса требуется:
- maven 3.6.3
- OpenJDK 11.0.2
 
## Переменные среды
- AUDIT_ENABLE: true/false
- LOG_LEVEL: info/debug
- DB_SOURCE_URL: Endpoint для подлючения к БД

Ветки

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

Стандартный набор веток:

develop
release
master/main
feature

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

Конвейер

Pipeline

Сборка

Процесс сборки должен быть реализован по сервисно, с возможностью выбора веток
Версия артефакта должна распарсиваться из исходного кода (pom.xml, package,json и тд.) и подставляться в сборку образа
Сборка должна происходить в docker wrapper, чтобы изолировать сборку на уровне контейнера - это сделает каждый процесс сборки «с чистого листа», так как все зависимости и кеши будут сброшены сразу после того как завершится шаг компиляции (результат не важен)
Необходимо сделать возможность запуска сборки всех или нескольких сервисов проекта через запуск одного задания, для формирования поставки/релиза
Унифицировать процесс сборки для всех видов используемых фреймворков по средства создания shared-librires, где классами и методами описать шаги сборки и публикации компонентов
Реализовать возможность запуска сборок по хуками (PR/MR, Commit)
Обязательное снятие хешей образов и коммитов для последующего обогащения данными чартов
Версия сервиса должна быть обогащена короткой ревизией коммита, что позволит избежать проблем с «перетиранием» готовых контейнеров. Пример: ms-service-name:1.2.3-53e3042dbf
Данные о собранном сервисы должны приходить коммитов в git репозиторий HelmChart

Развертывание

Унифицированный HelmChart с вложенными subChart'ами
Тотальная шаблонизация всех интеграций, служебных подключений, секретов, конфиг-мап
HemlChart должен быть разделен на ветки, где будет происходить обновление данных по средства RP/MR
В процессе развертывания сервисов должна происходить дешифровка сертификатов и секретов (Утилита HMP)

Тестирование

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

HelmChart

Должен обогощаться данными по мере сборки компонентов
Все изменения кода для веток установки в среды Препрод и Прод должны проходить только через Pull Request/Merge Request