====== DevOps ======
===== Команда =====
  * [[nc-questions|Вопросы для собеседования кандидатов]]
  * [[lead-wrk|Lead]]

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

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

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

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

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

**Примеры**
<file dockerfile 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"]
</file>
----
<file ini .gitignore>
.idea
*.iml
.DS_Store
/target
/log
/data/
/openapi/*.json
</file>
----
<file md 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 для подлючения к БД
</file>

==== Ветки ====
Все сервисы должны следовать единому 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
  * В процессе развертывания сервисов должна происходить дешифровка сертификатов и секретов (Утилита [[https://git.1denwin.keenetic.pro/rust/hmp|HMP]])

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

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