Процесс Внедрения — это финальный этап жизненного цикла разработки ПО, который заключается в доставке протестированного и утвержденного кода в производственную (Production) среду, делая его доступным для конечных пользователей.

Кто Выкатывает: Модели Внедрения

Существует две основные модели того, кто выкатывает функционал.

Модель 1: Команда Сопровождения

Это классическая модель, где существует разделение труда:

  1. Команда Разработки (Dev): Пишет код и передает “поставку” (артефакты) и “План Раскатки” (инструкцию) другой команде.

  2. Команда Сопровождения (Ops): Специализированная команда, которая отвечает только за стабильность “Прода”. Они получают инструкции и выполняют релиз (часто ночью или в “окно обслуживания”).

Модель 2: Команда Сама (You Build, You Run)

Это современный подход “You Build It, You Run It” (“Кто строит, тот и поддерживает”).

  1. Команда Продукта : Та же команда, что писала код, несет полную ответственность за его развертывание и работу в Проде.

  2. Процесс: Релиз выполняется через CI/CD Пайплайн (Набор автоматических шагов). Инженер нажимает кнопку в CD системе (например, GitLab CI, Jenkins), и автоматизированный скрипт выполняет все шаги.

Терминология

  • DevOps / SRE (Site Reliability Engineering): Инженеры, отвечающие за инфраструктуру.
  • Release Manager: Координатор, который управляет графиком релизов и согласовывает действия команд.
  • CI/CD :

    • CI (Непрерывная Интеграция): Автоматическая сборка и тестирование кода (на INT и TEST стендах).
    • CD (Непрерывная Доставка ): Автоматизация процесса доставки кода на Staging или Production среду, где он ждет ручного одобрения для Релиза.

Подходы к релизам: что, когда и как выпускаем

Подход к релизам — это договорённость команды и бизнеса:
насколько крупными порциями мы выкатываем изменения и как часто это делаем.

От этого зависят:

  • скорость появления фич у пользователей,
  • размер рисков,
  • предсказуемость для бизнеса,
  • и насколько команда живёт в пожаре.

Релизный подход

Команда копит большой пакет изменений и выкатывает их одним большим релизом.

  • Похоже на «крупное обновление раз в какое-то время».
  • Плюс: удобно коммуницировать бизнесу — один большой «выход».
  • Минус: много всего меняется сразу → выше риск, так как сложнее найти, что именно сломалось.

По-фичевый подход

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

  • Похоже на «починили/сделали → сразу выкатили».
  • Плюс: быстрая доставка ценности, мелкие порции изменений.
  • Минус: нужно аккуратнее с процессами и качеством, чтобы не превращать прод в «вечный эксперимент».

Релизные поезда

Релизы выходят по расписанию: например, раз в неделю или раз в две недели.

  • Готовые фичи «успевают на поезд» и едут в ближайший релиз.
  • Всё, что не успели доделать, просто ждёт следующего «поезда».

Плюсы:

  • бизнесу понятно: когда именно ждать изменения;
  • команде проще планировать и не рвать прод каждый день.

Минусы:

  • Долго ждать, если не успели на поезд. А не успеть можно вообще по любому “непредвиденному чиху”.

По-сервисный подход

Есть существующая система, которую нужно переписать и перевести в новое техническое пространство (платформу, архитектуру, стек).

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

Новые сервисы постепенно заменяют соответствующие участки старой системы, пока монолит (или старый контур) не будет полностью выведен из эксплуатации

Плюсы:

  • Гибкость в приоритетах: можно начинать с самых критичных или самых “болевых” зон.

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

Минусы:

  • Риск “залипнуть” в переходном состоянии: часть переписали, часть нет, и гибридная архитектура начинает мешать развитию.

  • Технический долг на стыках: временные адаптеры, прокси, синхронизация данных, обратная совместимость.

Стратегии Раскатки

Как именно новая версия заменяет старую в Production.

100% (All-at-once)

  • Что это: Старая версия останавливается, новая запускается.

  • Процесс: Все 100% пользователей мгновенно переключаются.

  • Результат: Почти всегда приводит к Даунтайму.

  • Когда: Используется, если миграция БД несовместима со старым кодом, или для внутренних систем.

Плавная (Rolling Update / Постепенная)

  • Что это: Обновление серверов по одному.

  • Процесс: Если у вас 10 серверов, “балансировщик нагрузки” (Load Balancer) временно перестает слать трафик на Сервер 1. Он обновляется, проверяется, и возвращается в работу. Затем процесс повторяется для Сервера 2, и так далее.

  • Результат: Нулевой Даунтайм (Zero Downtime), так как 9 серверов всегда в работе.

”Канареечная”

  • Что это: Самый безопасный плавный метод. Новая версия “выкатывается” рядом со старой.

  • Процесс:

    1. Фаза 1: Балансировщик (распределитель трафика) направляет 99% пользователей на старую версию, и только 1% (“канарейки”) — на новую.

    2. Команда внимательно следит за метриками этого 1%.

    3. Фаза 2: Если ошибок нет, трафик на новую версию увеличивают (10%… 50%…).

    4. Фаза 3: В итоге 100% трафика идет на новую версию, старая выключается.

  • Результат: Минимальный риск. Если у 1% пользователей возникают ошибки, откат происходит мгновенно (трафик возвращается на 100% старой версии).

Заключение

Что дальше?

➡️ Разберём финальный процесс — документирование изменений

НазадДалее