• Вопросы для собеседования кандидатов
• Lead

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

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

• .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

• Процесс сборки должен быть реализован по сервисно, с возможностью выбора веток
• Версия артефакта должна распарсиваться из исходного кода (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)

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

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