CI/CD та гейти якості (GitLab)

In progress

Розділ містить неточності, потребує доопрацювання та перевірки на реальних проєктах.
Після фіналізації та оновлення розділу буде створено загальну політку по роботі з Gitlab CI для розробників.

Мета

Забезпечити автоматичну перевірку якості коду на кожному етапі доставки — від коміту до деплою — і зробити процес прозорим, передбачуваним і детермінованим.

CI/CD не просто запускає тести — він гарантує, що жоден код без перевірки не потрапить у production.

Структура пайплайну

Етап	Опис	Приклад job’ів
prepare	кеш, середовище, залежності	install, build:deps
lint	перевірка якості коду	eslint, stylelint, typecheck
test	юніт та інтеграційні тести	test:node, test:jsdom
build	збірка docker image dev/stage/prod	build:dev, build:prod
deploy	деплой у dev/stage/prod	deploy:dev, deploy:prod
smoke	e2e smoke тести основних сценаріїв	smoke:dev, smoke:prod

Приклад .gitlab-ci.yml

stages:
  - prepare
  - lint
  - test
  - build
  - deploy

  # 🧱 Базовий шаблон для тестів
  .test_template: &test_template
    image: node:22-bookworm-slim
    stage: test
    cache:
      key: vitest-${CI_COMMIT_REF_SLUG}
    paths:
      - .vitest/
  variables:
    TZ: "UTC"
    CI: "true"
  artifacts:
    when: always
    expire_in: 7 days
    paths:
      - reports/
    reports:
      junit: reports/junit-*.xml
      coverage_report:
        coverage_format: cobertura
        path: reports/coverage/cobertura-coverage.xml

  # ✅ Lint & TypeCheck
  lint:
    stage: lint
    image: myorg/node-lint:20
    script:
      - pnpm eslint . --max-warnings=0
      - pnpm tsc --noEmit
    artifacts:
      reports:
        dotenv: reports/lint.env

  # 🧪 Tests
  test:node:
    <<: *test_template
    script:
      - pnpm vitest run --project node --coverage --reporter=junit --outputFile=reports/junit-node.xml

  test:jsdom:
    <<: *test_template
    script:
      - pnpm vitest run --project jsdom --coverage --reporter=junit --outputFile=reports/junit-jsdom.xml

  ...

Coverage & Quality гейти

Метрика	Значення	Дія при порушенні
Coverage (global)	≥ 80%	job fail
Coverage (new code)	≥ 70%	коментар у MR
Lint errors	0	job fail
Type errors	0	job fail
Flaky tests	< 2%	job warning
Test duration	≤ 5 хв	warning у MR

Гейти — це не формальність, а контроль стабільності - якщо pipeline зелений, код безпечний для релізу.

MR Reports і інтеграції

GitLab автоматично підтягує:

Тип звіту	Файл	Відображення
JUnit	reports/junit-*.xml	список пройдених / упалих тестів
Coverage (Cobertura)	reports/coverage/cobertura-coverage.xml	% покриття в MR
Lint	reports/lint.env	результати ESLint
Performance (Lighthouse)	reports/lighthouse.json	(опціонально)
Bundle Size	reports/size.json	(опціонально)

Quality gates для Merge Request

Поки MR відкритий:

• ✅ must pass:
  • lint
  • typecheck
  • test:node
  • test:jsdom
• 🟡 optional / informational:
  • coverage:summary
  • bundle-size
  • lighthouse

Важливо

MR не може бути злито, якщо хоча б один must-pass job завершився з помилкою.

Робота з артефактами

Тип	Що містить	Зберігається
JUnit	результати Vitest	7 днів
Coverage (HTML, XML)	покриття	7 днів
Lint reports	eslint, tsc	7 днів
Logs	консоль job’ів	14 днів
Screenshots / debug	(опціонально для e2e)	14 днів

Ці файли передаються у reports/, тому легко завантажити для локального аналізу.

Автоматичне блокування при регресі

• Якщо покриття нового коду < 70% --- у MR автоматично з’являється warning-коментар.
• Якщо pipeline червоний → блокування merge (через Merge Checks у GitLab, якщо доступно).
• При різкому падінні покриття (наприклад, -5%) - створюється issue “Coverage regression”.

Retry, Fail-fast, Notifications

• retry: 1 для тестових job’ів (перезапуск при флейку).
• interruptible: true - старі job’и автоматично скасовуються при новому пуші.
• fail-fast: якщо lint або typecheck падає - pipeline не витрачає час на тести.
• Slack / Email сповіщення: при падінні test або coverage < 80%.

Branch policies

Тип гілки	Політика
feature/*	тести обов’язкові при MR, coverage ≥ 70%
dev	повний пайплайн + quality stage
release/*	обов’язкове проходження всіх job’ів
main	автодеплой після зеленого пайплайну

Мета

Тримати dev завжди в робочому стані й не переносити червоні тести далі.

Оптимізація CI-затрат

• Docker multi-stage для мінімізації образів.
• pnpm store + cache - прискорення установки залежностей.
• parallel jobs + needs: → 30-40% швидше.
• no-install jobs (для lint/typecheck) - використовують кеш із prepare.