“Поставка” (или Release Candidate) — это пакет, который прошел все этапы тестирования и включает:

1. Артефакты Приложения: Обновлённые части системы на бэке и фронте

2. Миграции Базы Данных

3. Обновления Конфигурации: Новые настройки — разные параметры, без которых система не сможет нормально работать:

   • данные для подключения к внешним сервисам ключи API (например, платёжки или доставка),

   • лимиты, пороги, включённые/выключенные фичи и т.п.

Формирование поставки: что делает команда

Формирование поставки — это полноценный рабочий процесс, поэтому, когда оценивают задачи, обычно закладывают отдельное время на сборку релиза:

• отдельно на то, чтобы собрать и подготовить фронтенд,

• отдельно — бэкенд,

• а если система разбита на много отдельных кусочков (отдельные сервисы),
  то ещё и на сборку каждой такой части.

Определить состав поставки

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

Смотрят список задач и их статус и выбирают только те, которые:

• уже влиты в общий нужную ветку (весь нужный код по задачам уже собран в одном месте);

• были проверены на тестовой версии системы;

• не несут с собой очевидных серьёзных рисков (например, не затрагивают критичную логику).

Примечание

Для микросервисов: по каждому сервису свой набор задач → своя поставка и свой скоринг (оценка готовности и рисков перед релизом).

Подготовить артефакты для выката

Технически сборкой занимается CI (настроенный автоматический процесс, который сам собирает проект и делает из кода рабочую версию), но команда отвечает за то, чтобы:

• код по нужным задачам также смёржен в правильную ветку;

• для фронта и бэка есть корректно собранные артефакты (из этого кода получены рабочие “сборки”);

• нужные версии артефактов задеплоены на TEST / STAGE (эти сборки установлены на тестовые стенды, где команда и тестировщики могут их проверить);

• все «обязательные» тесты по этой поставке пройдены.

Создать задачи на раскатку

Нужно отдельно оформить, что именно мы собираемся выкатывать:

• создают отдельную задачу «выкатить новую версию» для той части, где крутится логика и данные (бэкенд);

• отдельную задачу — для той части, которая видна пользователю (фронтенд);

• если система состоит из многих отдельных кусочков (микросервисы),
  то для каждого крупного сервиса может быть своя отдельная задача и свой разбор готовности.

В задачу команда обычно вкладывает:

• точно указанные номера сборок, которые нужно выкатывать
  (не «последнюю версию», а конкретно: какую именно версию поставить на сервер);

• краткое описание изменений — что появится или изменится для пользователя и для бизнеса;

• план выката:
  куда именно едет новая версия, в каком порядке и кто/что её запускает
  (например: сначала тестовый сервер, потом боевой; кто нажимает кнопку запуска);

• план отката:
  до какой прошлой версии можно вернуться, если что-то пойдёт не так,
  и как это делается на практике (чёткие шаги);

• для бэкенда — информацию о миграциях БД (какие изменения структуры нужно запустить, когда именно, и есть ли среди них такие, которые потом уже не откатить без боли);

• ссылки на результаты проверок:
  что уже протестировано на тестовых стендах, какие сценарии прошли.

Получить согласования перед выкатом

После того как поставка собрана, команда тратит время на то, чтобы получить “добро” от тех, кто отвечает за разные части системы.

Обычно это выглядит так:

• Ответственный за разработку (техлид / лид разработчиков) говорит:
  «Технически всё ок, можно выкатывать, критичных дыр не вижу».

• Ответственный за тестирование (QA-лид) говорит:
  «Мы прогнали нужные проверки, всё, что обещали протестировать — протестировано».

Иногда дополнительно подключаются:

• специалисты по безопасности — смотрят, нет ли новых дыр, утечек и подозрительных мест;
• архитектор — оценивает, не ломает ли релиз общую конструкцию системы;
• владелец продукта / бизнес — подтверждает, что изменения ему подходят и ничего лишнего не включили;
• человек, который отвечает за базу данных (DBA), — если затронута сама структура данных и есть риск что-то повредить или потерять.
• Релиз-менеджер — назначается ответственный за релиз (сбор и внедрение)

Заключение

Что дальше?

➡️ Узнаем как происходят процессы внедрения и масштабирования