git_64_slides_simple_language_ru

1.

СОВРЕМЕННАЯ
GIT-АРХИТЕКТУРА
КОД
ПРОВЕРКА
От веток и webhook (автоматическое сообщение о
событии)-событий до автоматических проверок,
AI-анализа, задач и отчётности
АВТОМАТИЗАЦИЯ
РЕЛИЗ
Практический вариант архитектуры команды разработки
1

2.

Что мы хотим получить от Git
Не просто хранение исходного кода, а управляемый инженерный процесс
• Каждое изменение кода должно иметь понятное происхождение: задача → ветка → Merge
Request (запрос на добавление изменений) → commit (сохранённая точка изменений) → релиз.
• Проверки должны запускаться автоматически и не зависеть от того, вспомнил ли разработчик
запустить тесты вручную.
• Разные этапы — разработка, тестирование и production (рабочая версия для пользователей) —
должны иметь разные уровни контроля.
• Система должна уметь ответить не только «что изменилось?», но и «что ещё не сделано?» и
«готов ли релиз?».
• Результат изменений должен автоматически превращаться в понятный отчёт для
разработчиков, QA и руководителя.
Простыми словами: Git помогает понять, что поменяли, кто это сделал и можно ли безопасно выпускать новую версию.
Git = источник кода + событий + доказательств готовности
2

3.

Базовая модель: три главные ветки
development (среда
ежедневной разработки)
staging (тестовая среда
перед выпуском)
main
Сюда попадает готовая
работа из feature-веток.
Среда для ежедневной
разработки и быстрых
проверок.
Кандидат на релиз.
Здесь выполняются
интеграционные, E2E — полный
путь пользователя и приёмочные
проверки.
Только проверенный код.
Каждое изменение потенциально
является production (рабочая
версия для пользователей)релизом.
feature/* → development (среда ежедневной разработки) → staging
(тестовая среда перед выпуском) → main → production (рабочая
версия для пользователей)
Простыми словами: изменение сначала проверяется внутри команды, затем на тестовой среде и только после этого попадает к пользователям.
Важно: это модель проекта для доклада. В реальных командах стратегия ветвления выбирается под частоту релизов и процессы команды.
3

4.

Как изменение проходит через систему
Один разработчик видит короткий путь; за ним работает целая цепочка автоматизации
1. Задача
2. Feature-ветка
3. Merge Request (запрос на
добавление изменений)
Что нужно сделать
Изолированная работа
Обсуждение и review
4. Автопроверки
5. Merge
6. Webhook — автоматическое
сообщение о событии
Тесты и качество
Переход на новый этап
Событие для сервисов
После merge система сама решает, какие проверки, отчёты и действия
нужны дальше.
4

5.

Git: не просто хранилище файлов
Git хранит граф изменений и позволяет воспроизводимо управлять историей проекта
Commit — сохранённая точка
изменений
Working tree
Staging area
Локально изменённые файлы.
Набор изменений для следующего commit
(сохранённая точка изменений).
Branch
Remote
Tag
Указатель на линию разработки.
Общий репозиторий команды.
Именованная версия для релиза.
Неизменяемая точка истории.
Простыми словами: часть ошибок ловится ещё на компьютере разработчика до отправки работы коллегам.
Git хранит не «последний код», а проверяемую историю инженерных решений.

6.

Жизненный цикл изменения в Git
От локального файла до общего репозитория
Изменение
git add
working tree
staging (тестовая
среда перед
выпуском)
git commit
(сохранённая
локальная
история
точка
изменений)
git push
remote branch (ветка
разработки)
Merge Request
(запрос на
review + CI
добавление
изменений)
Простыми словами: Git сообщает нашей системе, что произошло событие, а автоматика решает, что запустить дальше.
Каждый этап можно сделать наблюдаемым: кто изменил, что проверено и почему изменение
разрешено.

7.

Стратегия веток: типы рабочих веток
Главные ветки задают среды, короткоживущие ветки — тип работы
feature/*
Новая функциональность → development (среда ежедневной разработки)
bugfix/*
Исправление дефекта → development (среда ежедневной разработки)
release/*
Опциональная стабилизация конкретного релиза
hotfix/*
Срочное production (рабочая версия для пользователей)-исправление + обратная
синхронизация
Короткоживущие ветки уменьшают конфликты и стоимость интеграции.

8.

Merge, Rebase и Squash
Три инструмента решают разные задачи
Merge
Rebase
Squash merge
Сохраняет ветвление и merge commit
(сохранённая точка
изменений)._x000B_Полная история
ветки.
Переносит commits на новую
базу._x000B_Удобно локально перед MR
(запрос на изменение).
Рабочие commits → один итоговый.
Чище история целевой ветки.
Protected branches должны запрещать случайный force push и прямые изменения main/staging (тестовая
среда перед выпуском).
Простыми словами: здесь выполняются быстрые проверки, чтобы дешёвые ошибки находились как можно раньше.
История Git должна помогать расследовать изменения, а не скрывать происхождение кода.

9.

Merge Request (запрос на добавление изменений) как Quality Gate
(обязательная
проверка
перед следующим
Код, review, автоматические доказательства
и ответственность
сходятся в одной точкеэтапом)
Review
CODEOWNERS
CI status
1–2 approvals для критичных областей
Владелец модуля подключается
автоматически
Merge запрещён при красных
обязательных jobs
Discussion
Branch policy
Traceability
Blocking-комментарии закрыты
Нет прямого push в main/staging (тестовая
среда перед выпуском)
MR (запрос на изменение) связан с issue,
commit (сохранённая точка изменений) и
релизом
Простыми словами: на staging мы проверяем уже не отдельные файлы, а работу приложения как единого целого.
Merge — формальное решение: изменение достаточно проверено для следующего этапа.

10.

Tags, версии и Hotfix
Связываем Git-историю с конкретным production (рабочая версия для пользователей)-релизом
main @ a83fc21
tag v2.8.0
image app:2.8.0
Проверенный commit (сохранённая точка
изменений)
Именованная версия
Неизменяемый artifact (готовый пакет
программы)
Hotfix: production (рабочая версия для пользователей) bug → hotfix/* → обязательные проверки → main → новый tag/image
→ синхронизация исправления обратно в development (среда ежедневной разработки)/staging (тестовая среда перед
выпуском).
Простыми словами: пользователям отправляется именно та версия программы, которую мы уже проверили.
Rollback (возврат к предыдущей версии) возвращает известный artifact (готовый пакет программы); новый hotfix
создаёт новую версию, а не переписывает старую.

11.

Локальные Git Hooks: первая линия защиты
git commit
(сохранённая
точка
изменений)
pre-commit
(сохранённая
точка изменений)
lint / format /
typecheck
commit
(сохранённая
точка
изменений)
• pre-commit (сохранённая точка изменений) — быстрые проверки до создания commit (сохранённая
точка изменений);
• commit (сохранённая точка изменений)-msg — проверка формата сообщения и номера задачи;
• pre-push — более тяжёлые тесты перед отправкой изменений;
• lint-staged позволяет проверять только изменённые файлы и не тормозить разработчика;
• хуки удобны, но их можно обойти, поэтому критические правила обязательно повторяются на CI.
Простыми словами: архитектурные правила можно проверять автоматически, а не надеяться только на внимательность разработчика.
5

12.

Webhook — автоматическое сообщение о событии: как Git запускает
наши
сервисы
GitLab/GitHub
сообщает внешней системе о событии HTTP-запросом
Merge / Push /
Tag
GitLab
Webhook —
автоматическое
сообщение о
событии
Наш NestJS
endpoint
Queue
• Webhook — автоматическое сообщение о событии содержит проект, автора, commits,
source_branch, target_branch и тип события.
• Endpoint проверяет секретный токен и валидирует payload — нельзя доверять входящему запросу
без проверки.
• Тяжёлая работа не выполняется внутри HTTP-запроса: событие быстро кладётся в очередь.
• Worker получает событие из очереди и запускает нужный сценарий: анализ, тесты, отчёт,
уведомление или deployment.
Webhook — автоматическое сообщение о событии = мост
между Git и нашей системой автоматизации
6

13.

Маршрутизация: ветка определяет уровень проверки
development (среда
ежедневной
разработки)
Быстро проверить, что разработка не сломала проект.
staging (тестовая
среда перед
выпуском)
Доказать, что функциональность готова к релизу.
main
Убедиться, что можно безопасно выпускать в production (рабочая версия для
пользователей).
Простыми словами: AI собирает результаты разных проверок и объясняет, чего ещё не хватает до готового релиза.
Таким образом, один и тот же webhook (автоматическое сообщение о событии)-сервис не дублирует логику, а выбирает pipeline по контексту события.
7

14.

Development: быстрые автоматические проверки
Сборка
Lint — автоматическая
проверка правил кода
Typecheck — проверка типов
данных
Компилируется ли проект?
Нет ли нарушений правил кода?
Совпадают ли типы?
Unit tests — тесты отдельных
функций
Affected
Dev deploy
Проверяем только затронутые
модули.
Разворачиваем тестовую версию.
Не сломана ли локальная логика?
Цель development (среда ежедневной разработки): найти дешёвую ошибку как
можно раньше, до QA и production (рабочая версия для пользователей).
Результат: статус pipeline + технический отчёт о том, что изменилось и какие проверки прошли.
8

15.

Staging: проверяем не файл, а поведение системы
Интеграционные
тесты — проверка
связи частей
системы
API-контракты —
правила обмена
между системами
Security scan —
автоматическая
проверка
безопасности
Взаимодействие модулей и сервисов
Не сломали ли клиентов API
Зависимости, секреты, SAST — поиск
уязвимостей в коде
E2E — полный путь
пользователя
Пользовательские сценарии от
начала до конца
Миграции БД
Применение, совместимость, rollback
(возврат к предыдущей версии)
Smoke test —
быстрая проверка
после запуска
Работает ли развёрнутая среда
QUALITY GATE (обязательная проверка): разрешить или
запретить переход в main
9

16.

Пирамида тестирования
Чем выше уровень, тем дороже тест — быстрых тестов должно быть больше
Unit
сотни / тысячи • быстро
Integration / API
десятки–сотни
UI / E2E — полный путь
пользователя
критические сценарии
Load — обычная
высокая нагрузка /
точечные тяжёлые проверки
Security /
Acceptance
Pipeline должен учитывать стоимость проверки и риск изменения — не всё запускается на каждый commit
(сохранённая точка изменений).

17.

Unit-тесты — проверки отдельных функций: локальная бизнеслогика
Самый быстрый слой обратной связи — feature/development (среда ежедневной разработки)
Frontend
Backend
Mock boundaries
service / pipe / component logic
service method
валидация формы
преобразование данных
расчёт цены
retry policy
permission rule
HTTP, DB, filesystem, clock — если это
не предмет теста
Пример: timeout платежа → максимум 3 retry; после этого controlled failure и отсутствие дублирующего заказа.
Unit-тест отвечает: сломалась ли конкретная логика — без браузера, сети и реальной БД.

18.

Integration и API tests — проверка обмена данными
Проверяем взаимодействие модулей, базы, очередей и внешних контрактов
DB integration
API integration
repository + тестовая БД
HTTP → controller → service → DB
constraints / transaction / migration
status + validation
Contract tests
Queue / async
producer/consumer schema
producer → broker → worker
обязательные поля и типы
retry / idempotency / DLQ
Простыми словами: Docker позволяет одинаково запускать проверенную программу на разных серверах.
Этот слой ловит SQL, serialization, transaction и contract-ошибки, которых unit-тесты не видят.

19.

UI / Component tests
Проверяем интерфейс и взаимодействия пользователя
Компонент
Interaction
render states
click / input / keyboard
validation
loading / error
modal / dropdown / pagination
Accessibility
Visual regression
role / label / keyboard navigation
снимок страницы/компонента
базовые a11y-проверки
неожиданные визуальные изменения
UI-тесты полезны для Angular/React: проверяют DOM и поведение интерфейса, а не только функции.

20.

E2E — полный путь пользователя: критические пользовательские
сценарии
Playwright / Cypress: браузер проходит систему от UI до backend
Авторизация
Покупка
login → session → профиль
каталог → корзина → checkout → success
Права
Ошибка
обычный пользователь не открывает admin route
backend 500 → UI показывает error + retry
E2E — полный путь пользователя покрывает критические бизнес-пути; не нужно дублировать через браузер все unitтесты.

21.

Нагрузочное тестирование
Не только «сколько RPS выдержит», а как система ведёт себя в разных режимах
Load — обычная высокая нагрузка
Stress — поиск предела системы
ожидаемая рабочая нагрузка
повышаем нагрузку
например 200 RPS
ищем предел деградации
Spike — резкий скачок нагрузки
Soak — долгая нагрузка
резкий всплеск
длительная нагрузка
например ×10 за 30 секунд
memory leak / pool / деградация
k6 / JMeter / Gatling: p95/p99 latency, error rate, throughput, CPU/RAM, saturation.

22.

Пример нагрузочного Quality Gate (обязательная проверка перед
следующим
этапом)
Релиз блокируется по прозрачным
порогам
p95 latency
p99 latency
Error rate
< 400 ms
< 900 ms
< 1%
Throughput
CPU
Memory
> 200 RPS
< 80%
без устойчивого роста
Числа — пример. Реальные thresholds должны исходить из SLO продукта и production (рабочая версия для
пользователей)-метрик.

23.

Security, resilience и специальные проверки
Качество — это не только функциональная корректность
SAST — поиск уязвимостей в
коде / secrets
Dependencies
DAST — проверка безопасности
запущенного приложения
статический анализ + поиск секретов
CVE + license policy + lockfile
проверка развёрнутого приложения
Resilience
Migration
Smoke
timeout / retry / circuit breaker
forward/backward + rollback (возврат к
предыдущей версии)
health / login / критический API
Набор проверок выбирается по риску изменения: платежи, auth и миграции требуют более строгого
gate.

24.

Какие тесты запускать на каком этапе
Баланс скорости обратной связи и глубины проверки
Feature / MR (запрос на
изменение)
development (среда
ежедневной
разработки)
staging (тестовая среда
перед выпуском)
main / prod
lint / typecheck / unit
integration / API
○
UI / E2E — полный путь
пользователя
○
affected
smoke
secrets
SAST — поиск
уязвимостей в коде
verify
—
—
SAST — поиск
уязвимостей в коде +
DAST — проверка
безопасности
●запущенного
/ schedule
приложения
security
load / stress
canary
● обязательно • ○ выборочно/affected • тяжёлые проверки переносим ближе к staging (тестовая среда перед выпуском)
и релизу.

25.

Больше практических примеров тестов
Не только список типов, а конкретные проверки, которые можно положить в CI/CD
Unit
Component
API
DB
service / pure logic
форма / состояние UI
контроллер + validation
migration + rollback (возврат к
предыдущей версии)
Contract
E2E — полный путь
пользователя
Visual
A11y
критический user flow
скриншотный diff
доступность интерфейса
Security
Smoke
Canary
secrets / CVE / SAST — поиск
уязвимостей в коде
health after deploy
метрики после релиза
schema / OpenAPI
Load — обычная высокая
нагрузка
RPS + latency
Главная идея: каждый тип теста отвечает на свой вопрос и запускается в правильном месте pipeline.

26.

Unit test: пример для NestJS service
Проверяем бизнес-правило без HTTP, браузера и реальной базы
describe('OrderService', () => {
it('не создаёт дубликат заказа при retry', async () => {
payments.charge
.mockRejectedValueOnce(new TimeoutError())
.mockResolvedValueOnce({ id: 'pay_42' });
Что проверяет
• быстро запускается на каждом MR (запрос на
изменение)
• mock внешних зависимостей
await service.checkout(dto);
await service.checkout(dto); // повтор после timeout
• ловит ошибки локальной логики
expect(repo.createOrder).toHaveBeenCalledTimes(1);
expect(payments.charge).toHaveBeenCalledTimes(2);
});
});
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

27.

Angular component test
Проверяем состояние формы, ошибки и события компонента
it('блокирует Submit, пока форма невалидна', async () => {
await render(LoginFormComponent, {
imports: [ReactiveFormsModule],
});
await user.click(screen.getByRole('button', { name: /login/i }));
expect(screen.getByText('Email обязателен')).toBeVisible();
expect(api.login).not.toHaveBeenCalled();
});
Что проверяет
• проверяет DOM и поведение
• быстрее полного E2E — полный путь пользователя
• хорошо подходит для форм и состояний
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

28.

API test: Supertest / HTTP level
Проверяем validation, status code и контракт ответа
it('POST /users возвращает 400 при плохом email', async () => {
await request(app.getHttpServer())
.post('/users')
.send({ email: 'wrong', name: 'Sergey' })
.expect(400)
.expect(({ body }) => {
expect(body.message).toContain('email must be an email');
});
});
Что проверяет
• controller + pipes + filters
• видит реальные HTTP-ошибки
• удобно для backend regression
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

29.

DB integration test
Проверяем реальные constraints, транзакции и работу repository
it('не позволяет создать два активных профиля', async () => {
await repo.save({ userId: 7, status: 'active' });
await expect(
repo.save({ userId: 7, status: 'active' })
).rejects.toThrow(/unique/i);
});
Что проверяет
• использовать test container / test DB
• очищать данные между тестами
• ловит SQL и constraint ошибки
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

30.

Migration test: forward + rollback (возврат к предыдущей версии)
Миграция должна применяться и откатываться предсказуемо
test('migration 20260827_add_status', async () => {
await migrate.up();
await db.query("insert into orders(status) values('new')");
const columns = await tableColumns('orders');
expect(columns).toContain('status');
await migrate.down();
expect(await tableColumns('orders')).not.toContain('status');
});
Что проверяет
• особенно важно перед staging (тестовая среда перед
выпуском)/main
• проверяет совместимость данных
• rollback (возврат к предыдущей версии) не должен быть
формальностью
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

31.

Contract / OpenAPI test
Не ломаем клиентов API незаметным изменением schema
it('response соответствует OpenAPI schema', async () => {
const res = await request(app).get('/api/profile').expect(200);
expect(res.body).toMatchSchema(
openapi.components.schemas.ProfileResponse
);
});
Что проверяет
• полезно для публичного API
• ловит удаление/переименование полей
• можно запускать на staging (тестовая среда перед
выпуском)
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

32.

Queue / async worker test
Проверяем idempotency, retry и обработку ошибок в очереди
it('worker не отправляет email дважды', async () => {
await queue.add('welcome', { userId: 15 });
await queue.add('welcome', { userId: 15 });
await worker.drain();
expect(mail.sendWelcome).toHaveBeenCalledTimes(1);
expect(await outbox.count({ userId: 15 })).toBe(1);
});
Что проверяет
• важно для фоновых задач
• проверяет повторную доставку
• защищает от дублей и race condition
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

33.

Playwright E2E — полный путь пользователя
Проверяем главный пользовательский сценарий через браузер
Что проверяет
test('пользователь оформляет заказ', async ({ page }) => {
await page.goto('/catalog');
await page.getByText('Тариф Pro').click();
await page.getByRole('button', { name: 'Купить' }).click();
await page.getByLabel('Email').fill('user@mail.com');
await page.getByRole('button', { name: 'Оплатить' }).click();
• критические бизнес-пути
await expect(page.getByText('Заказ создан')).toBeVisible();
});
• лучше запускать на staging (тестовая среда перед
выпуском)
• не дублировать каждый unit
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

34.

Visual regression
Ловим случайные визуальные изменения после правок CSS/UI
test('страница профиля визуально не изменилась', async ({ page }) => {
await page.goto('/profile');
await expect(page).toHaveScreenshot('profile-page.png', {
maxDiffPixelRatio: 0.01,
});
});
Что проверяет
• полезно для дизайн-системы
• требует стабильных данных
• лучше держать baseline под контролем
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

35.

Accessibility test
Проверяем, что интерфейс доступен клавиатуре и screen reader
test('home page не имеет критичных a11y-ошибок', async ({ page }) => {
await page.goto('/');
const results = await new AxeBuilder({ page }).analyze();
expect(results.violations).toEqual([]);
});
Что проверяет
• role / label / contrast
• важно для форм и навигации
• может быть частью UI/E2E — полный путь
пользователя gate
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

36.

k6 Load — обычная высокая нагрузка test
Проверяем скорость API под ожидаемой рабочей нагрузкой
export const options = {
vus: 50,
duration: '3m',
thresholds: {
http_req_failed: ['rate<0.01'],
http_req_duration: ['p(95)<400'],
},
};
export default function () {
http.get(`${BASE_URL}/api/products`);
}
Что проверяет
• измеряем p95/p99 latency
• error rate должен быть малым
• запускать на staging (тестовая среда перед выпуском)
или по расписанию
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

37.

Spike — резкий скачок нагрузки / Stress — поиск предела системы
сценарий
Проверяем резкий рост нагрузки и предел деградации
export const options = {
stages: [
{ duration: '30s', target: 20 },
{ duration: '30s', target: 300 }, // spike
{ duration: '2m', target: 300 },
{ duration: '30s', target: 0 },
],
};
Что проверяет
• показывает предел системы
• важны CPU/RAM/DB pool
• нужны отдельные test data и среда
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

38.

Security checks в CI
Ищем секреты, уязвимости и опасные зависимости до merge
security:
stage: test
script:
- gitleaks detect --source . --no-git
- npm audit --audit-level=high
- semgrep scan --config auto
allow_failure: false
Что проверяет
• секреты не должны попасть в Git
• critical CVE блокирует merge
• SAST — поиск уязвимостей в коде дополняет review
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

39.

Smoke test — быстрая проверка после запуска after deploy
После deploy быстро доказываем, что среда реально жива
test('production (рабочая версия для пользователей) smoke', async ({ request }) => {_x000B_
await expect.poll(async
Что проверяет() => {_x000B_
• проверка после deployment
• health + login + critical API
• быстро даёт сигнал rollback (возврат к предыдущей
версии)/canary
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.
const re

40.

Canary + monitoring gate
После релиза смотрим не только тесты, но и production (рабочая версия для пользователей)-метрики
canary_gate:_x000B_
wait: 10m_x000B_
checks:_x000B_
error_rate: '< 1%'_x000B_
p95_latency: '<
500ms'_x000B_
Что
проверяет crash_loop: '= 0'_x000B_
• CI не видит всё заранее
• метрики закрывают post-release риск
• canary снижает blast radius
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

41.

GitLab CI: пример stages для разных тестов
Один pipeline собирает быстрые и тяжёлые проверки в понятный порядок
stages: [fast, build, integration, ui, security, load, deploy]_x000B__x000B_unit:_x000B_
stage: fast_x000B_
script: npm run test:unit_x000B__
Что проверяет
• fast checks на каждый MR (запрос на изменение)
• E2E — полный путь пользователя ближе к staging
(тестовая среда перед выпуском)
• load можно запускать по расписанию
Где запускать
• MR (запрос на изменение)/development (среда
ежедневной разработки) — если быстро
• staging (тестовая среда перед выпуском) — если нужен
deploy
• schedule/release — если тяжёлый тест
Пример можно адаптировать под Jest, Vitest, Playwright, Cypress, k6, GitLab CI или GitHub Actions.

42.

Как выбирать тесты под конкретное изменение
Тесты должны следовать за риском, а не запускаться одинаково для каждой строки кода
Изменили UI
Изменили API
component + visual + E2E — полный путь пользователя критического flow
unit + API + contract + smoke
Изменили БД
Изменили auth/payment
migration + integration + rollback (возврат к предыдущей версии) + backup
plan
security + E2E — полный путь пользователя + load + canary
Изменили Docker/infra
Изменили background jobs
build image + vulnerability scan + deploy smoke
queue test + idempotency + observability
Хороший pipeline не просто «гоняет всё», а выбирает проверки по типу риска и этапу поставки.

43.

Main: production (рабочая версия для пользователей) должен быть
воспроизводимым
Commit —
сохранённая точка
изменений
Tag
Artifact — готовый
пакет программы
Production
Точная версия кода
Например v2.8.0
Docker image — упакованная
версия программы / package
Развёрнут тот же artifact
(готовый пакет программы)
• Не пересобираем приложение отдельно для staging (тестовая среда перед выпуском) и production
(рабочая версия для пользователей) — продвигаем уже проверенный artifact (готовый пакет
программы).
• Любой production (рабочая версия для пользователей)-инцидент можно связать с конкретным
commit (сохранённая точка изменений) и набором изменений.
• Rollback (возврат к предыдущей версии) означает возврат к известному предыдущему artifact
(готовый пакет программы), а не попытку срочно пересобрать старый код.
• После успешного релиза автоматически формируется release report.
1
0

44.

Автоматическая проверка архитектуры
• Границы модулей: UI не должен напрямую обращаться к инфраструктурному слою, если архитектура
это запрещает.
• Циклические зависимости: A → B → C → A должны обнаруживаться автоматически.
• Запрещённые импорты: приложение не должно использовать внутренние файлы другого домена в
обход публичного API.
• Размер bundle и performance budget: изменение не должно незаметно увеличить клиентское
приложение на сотни килобайт.
• Новые зависимости: можно блокировать неподходящие лицензии или библиотеки с известными
уязвимостями.
Архитектурное правило становится исполняемой проверкой, а не
страницей в документации.
1
1

45.

Главный дополнительный вопрос: что ещё осталось сделать?
Задача / MR
(запрос на
изменение)
Git diff
Результаты CI
AI
• Сравнить acceptance criteria задачи с фактически изменённым кодом.
• Найти TODO/FIXME, временные заглушки и оставленные feature flags.
• Проверить, появились ли тесты для новой логики и прошли ли они.
• Понять, требуется ли обновление API-документации, changelog или пользовательской документации.
• Определить, есть ли незавершённая миграция, отсутствие rollback (возврат к предыдущей версии) или
неподтверждённый сценарий.
• Сформировать конкретный список остаточных действий, а не абстрактное «нужно проверить».
1
2

46.

AI-анализ готовности: четыре источника истины
1. НАМЕРЕНИЕ
2. РЕАЛИЗАЦИЯ
3. ДОКАЗАТЕЛЬСТВА
4. ПРОБЕЛЫ
Issue, описание MR
(запрос на изменение),
acceptance criteria
Diff, новые файлы,
изменённые
зависимости
Тесты, build,
security, deployment
Что обещали,
но не доказали
Результат: оценка готовности + объяснение + список
оставшихся действий
AI здесь не заменяет CI: он связывает разрозненные технические факты и объясняет их человеку.
1
3

47.

Автоматическое создание задач — но с контролем
Найден пробел
Проверка
контекста
Поиск дубликатов
Создание задачи
Назначение owner
• Задача должна содержать ссылку на MR (запрос на изменение)/commit (сохранённая точка изменений) и
конкретные файлы или проверки, из-за которых она появилась.
• Автоматизация добавляет критерии готовности: что именно нужно изменить и чем подтвердить
выполнение.
• Перед созданием выполняется поиск похожих открытых issues, чтобы не плодить дубликаты.
• Для критических действий лучше использовать режим «предложить задачу / запросить подтверждение»,
а не бесконтрольное автосоздание.
• После закрытия задачи система может повторно проверить, действительно ли пробел устранён.
1
4

48.

Definition of Done становится измеримым
Код собран
Тесты пройдены
E2E — полный путь пользователя пройден
Нет critical security
Документация обновлена
Rollback (возврат к предыдущей версии) проверен
Нет незакрытых блокеров
Готовность релиза: 92% — условно готов
Процент — не магическая AI-оценка: он должен строиться на прозрачных правилах и результатах проверок.
1
5

49.

Что происходит, если проверка не пройдена
Блокировать merge
Pipeline
Ошибка
Создать комментарий в MR (запрос на изменение)
Сформировать задачу
Уведомить ответственного
Разные ошибки имеют разную серьёзность: warning не обязан блокировать merge, а critical security issue — обязан.
1
6

50.

Отчёт для разработчиков
Техническая презентация после merge в development (среда ежедневной разработки)
• Какие задачи и Merge Request (запрос на добавление
изменений) вошли в изменение.
• Какие приложения, библиотеки и домены затронуты.
DEV REPORT
• Ключевые изменения в коде и архитектуре.
• Результаты build, lint, typecheck и unit tests.
• Новые зависимости и изменения API.
• Технический долг, TODO/FIXME и найденные остаточные
действия.
• Что должен знать следующий разработчик, продолжающий
работу.
Технический
контекст
Риски
Что осталось
сделать
1
7

51.

Отчёт для QA
Презентация после merge в staging (тестовая среда перед выпуском)
• Какие пользовательские сценарии изменились.
• Какие области приложения необходимо регрессионно
проверить.
QA REPORT
• Какие API и данные изменились.
• Какие миграции будут применены на staging (тестовая среда
перед выпуском).
• Результаты integration/E2E — полный путь
пользователя/smoke тестов.
• Известные проблемы и ограничения.
• Список сценариев, которые автоматика не смогла доказать и
требуется проверить вручную.
Что проверять
Где риск
Что уже
проверила
автоматика
1
8

52.

Отчёт о релизе
Презентация после merge/tag в main
• Версия, commit (сохранённая точка изменений), tag и
production (рабочая версия для пользователей) artifact (готовый
пакет программы).
• Новые возможности продукта — нормальным языком, без
списка технических commits.
• Исправленные ошибки и важные изменения поведения.
• Результаты обязательных quality gates.
• Известные риски и оставшиеся некритичные задачи.
• План rollback (возврат к предыдущей версии) и ссылка на
предыдущую стабильную версию.
• Краткое резюме для руководителя / Product Owner / заказчика.
RELEASE REPORT
Что вышло
Можно ли
доверять релизу
Что осталось
после релиза
1
9

53.

Пример: как один Merge Request (запрос на добавление изменений)
превращается в знания
MR (запрос на
изменение) #482
Payment retry
Diff + CI
AI анализ
Структурированный
результат
• Готово: добавлен retry для временных ошибок платёжного API.
• Доказано: unit и integration tests прошли.
• Риск: изменён внешний API-клиент и логика повторов.
• Не доказано: нет E2E — полный путь пользователя для expired_card.
• Осталось: добавить E2E — полный путь пользователя и обновить раздел документации о
статусах платежа.
• Для staging (тестовая среда перед выпуском): автоматически добавить оба пункта в QA Report.
2
0

54.

Дополнительные возможности Git, усиливающие процесс
git bisect
Автоматически найти commit (сохранённая
точка изменений), который внёс регрессию.
git worktree
Параллельно работать с
несколькими ветками или AIагентами.
git reflog
Восстановить потерянные commits и
состояния HEAD.
git blame
Найти commit (сохранённая точка
изменений) и контекст появления
конкретной строки.
signed
commits/tags
Подтвердить происхождение commit
(сохранённая точка изменений) или
релизного tag.
CODEOWNERS
Автоматически требовать review
владельца затронутой области.
2
1

55.

Полная архитектура решения
Разработчик
Webhook —
автоматическое
сообщение о
событии API
GitLab
CI / Tests
Security
Очередь
AI-анализ
Workers
Задачи
development (среда
ежедневной разработки)
staging (тестовая среда
перед выпуском)
main
DEV REPORT
QA REPORT
RELEASE REPORT
В каждом этапе система хранит не только результат, но и доказательства: какие проверки были выполнены и почему принято решение.
2
2

56.

Что это даёт команде
Разработчику
Быстрая обратная связь и меньше
ручных проверок.
QA
Чёткий список того, что изменилось и
где сосредоточить тестирование.
Tech Lead
Контроль архитектурных правил и
технического долга.
Product Owner
Понятное состояние готовности задач
и релиза.
Руководителю
Автоматический отчёт без чтения десятков
Merge Request (запрос на добавление
изменений).
Проекту
Прослеживаемость: от требования до
production (рабочая версия для
пользователей) artifact (готовый пакет
программы).
Меньше ручной рутины → больше прозрачности → более
предсказуемые релизы
2
3

57.

Главный вывод
Git становится центром событийной архитектуры
разработки
КОД
СОБЫТИЕ
GIT
ПРОВЕРКА
AI-АНАЛИЗ
ЗАДАЧИ
РЕЛИЗ
Система должна отвечать на три вопроса:
1. Что изменилось?
2. Готово ли это?
3. Что ещё осталось сделать?
И автоматически объяснять ответ нужной аудитории.
2
4

58.

Где Docker находится в нашей архитектуре
Docker соединяет проверенный исходный код с реально запускаемым приложением
Git / Merge
CI-проверки
Docker Build
Registry
Окружение
• После того как код прошёл обязательные проверки, CI собирает Docker image — упакованная
версия программы — фиксированную версию приложения вместе с runtime и зависимостями.
• Image сохраняется в Container Registry и получает идентификатор, связанный с commit
(сохранённая точка изменений) SHA или версией релиза.
• Дальше мы не переносим исходный код вручную: окружения запускают контейнер из конкретного
image.
• Таким образом Docker является слоем доставки между CI/CD и DEV, STAGING, PRODUCTION.
Git хранит код → CI проверяет → Docker фиксирует исполняемую
версию
2
5

59.

Что именно даёт Docker
Главная ценность — воспроизводимость окружения
Одинаковый
runtime
Версия Node.js и системные
зависимости задаются Dockerfile.
Изоляция
Повторяемость
CI и сервер запускают один и тот же
образ приложения.
Версионировани
е
Быстрый rollback
(возврат к
предыдущей
версии)
Можно вернуть предыдущий
проверенный image.
Автоматизация
Frontend, backend, worker и другие
сервисы запускаются отдельно.
Image можно связать с commit (сохранённая
точка изменений), tag и release.
Сборка и доставка image
выполняются CI/CD без ручного
копирования.
2
6

60.

Dockerfile тоже является частью Git-архитектуры
repository/
apps/
frontend/
backend/
Dockerfile
docker-compose.yml
.gitlab-ci.yml
package.json
Dockerfile описывает, КАК собрать и запустить
приложение
docker-compose.yml описывает, КАК сервисы работают
вместе локально
CI-конфигурация описывает, КОГДА собрать, проверить
и опубликовать image
Окружение перестаёт быть набором ручных инструкций и становится
версионируемой конфигурацией рядом с кодом.
2
7

61.

Build once — deploy many
Один проверенный Docker image — упакованная версия программы проходит через окружения
commit
(сохранённая
точка изменений)
a83fc21
DEV
Docker Build
STAGING
registry/app:a83fc21
PRODUCTION
Критически важно: staging (тестовая среда перед выпуском) и production (рабочая версия для пользователей) не
должны получать разные пересобранные версии одного и того же релиза.
Продвигается один и тот же immutable artifact (готовый пакет программы); меняется только конфигурация окружения и секреты.
2
8

62.

Docker и наши три ветки
development (среда
ежедневной
разработки)
Быстрые проверки → image кандидата → DEV-среда.
Команда видит актуальную интеграционную версию.
staging (тестовая
среда перед
выпуском)
Полные проверки → развёртывание проверяемого image → E2E — полный путь пользователя /
smoke / QA.
Фиксируем кандидата на релиз.
main
Quality Gate (обязательная проверка перед следующим этапом) → release tag → продвижение уже
проверенного image в production (рабочая версия для пользователей).
Создаём release report.
Docker не заменяет ветки или CI — он фиксирует результат их работы в переносимый исполняемый артефакт.
2
9

63.

Docker Compose: локальная модель приложения
Удобно для разработки многосервисного приложения
Angular
frontend
NestJS
backend
MySQL
Redis
Worker
Общая Docker Network
• Разработчику не нужно вручную устанавливать MySQL, Redis и дополнительные сервисы.
• Команда получает единый способ запуска проекта: конфигурация хранится в репозитории.
• Можно быстро поднять изолированную среду для CI, интеграционных тестов или нового разработчика.
• Production при этом не обязан использовать Docker Compose — там может быть отдельная система
оркестрации.
3
0

64.

Итоговая архитектура: место Docker в общей концепции
Разработчик
Webhook —
автоматическое
сообщение о
событии
Git
CI / AI
Quality Gate
(обязательная
проверка перед
следующим
этапом)
Docker
DEV
STAGING
PRODUCTION
Dev Report
QA Report
Release Report
Registry
Docker отвечает за воспроизводимый артефакт; Git и CI — за
происхождение и доказательство его качества.
3
1