Розробка

Для правильної роботи із Sonar у пайплайнах у коренів створено sonar-project.properties, який об’єднує основні налаштування із відповідних файлів у підпакетах, включно із винятками, а також перелічує потрібні шлях до вихідних кодів та тестів.

Оскільки існує значна частина коду, яка раніше була продубльована між порталами, то на момент створення репозиторію Sonar показував досить високий показник дублювання (понад 20%). У якості тимчасової міри більшість службових модулів порталів додано у винятки сканування на дублювання за допомогою директиви sonar.cpd.exclusions.

Також для виправлення проблеми із некоректною оцінкою покриття коду тестами через Sonar, яка була викликана збігом деякіх шляхів до файлів у рамках підпакетів використані додаткові налаштування для Jest у підпакетах, які вказують повні шляхи до файлів відносно монорепозиторію у згенерованих файлах coverage-звітів.

Для конфігурації застосунку використовуються константи середовища, які в рамках коду доступні через звернення до process.env.CONSTANT_NAME. Константи формуються на основі змінних середовищ. Також налагоджено механізм, який додає константи, визначені у локальному файлі .env в корені репозиторію (за наявності такого файлу). Цей файл можна використовувати у локальному середовищі під час розробки. Приклад констант можна переглянути у файлі .env.example.

Для доступу до Swagger за замовчанням використовується адреса /swagger-ui. Оскільки передбачається, що поданий сервіс є внутрішнім та не є доступним для зовнішніх користувачів, то використання Swagger не потребує додаткової авторизації.

Форми отримуються за ключем із відповідного сервісу form-provider, URL якого можна отримати із константи оточення FORM_PROVIDER_BASE_URL. У рамках запиту до цього сервісу наскрізь передається токен доступу, отриманий поточним сервісом з тіла заголовку X-Access-Token. Токен передається у заголовку з такою ж назвою. Валідація заголовку виконується поза кодом поточного сервісу.

Також для локальної розробки є можливість налаштувати використання локального набору копій форм ("замоканих" форм).

В директорії src присутні такі дочірні директорії:

Модульні тести зазвичай розміщені поруч із модулями, що тестуються, та мають у своїй назві додатковий суффікс .test; тобто, для модуля example.ts файл тестів називатиметься example.test.ts.

Для логування використовується окремий допоміжний сервіс, який визначено як request-scoped та який приймає об’єкт даних про кожен запит при ініціалізації. Цей сервіс вбудовуються в ряд інших сервісів, що призводить до перестворення їх екземплярів при кожному запиті. Це необхідно для того, щоби при логуванні у об’єкти логів наскрізь передавались в тому числі службові заголовки як от X-B3-TraceId, X-B3-SpanId, X-Request-Id тощо.

Логи виводяться у стандартний буфер виводу у форматі однорядкового JSON, звідки вони зчитуються та обробляються відповідно налаштованими сервісами для обробки та збереження логів на кшталт Kibana.

Для налаштування аліасів використовується поле imports у файлі package.json. Це унеможливлює класичне використання файлів index.ts для реекспорту значень та типів із сусідніх модулів із скороченням шляху до модуля. Натомість для реекспорту використовуються аналогічні файли exports.ts.