Выкатить, залить, накатить — суть терминов и отличия

Что значит «выкатить», «залить», «накатить»

«Выкатить» — самый общий термин, означающий публикацию новой версии программного продукта, фичи или изменения. «Выкатили обновление», «выкатили фикс», «выкатили релиз» — во всех случаях речь идёт о том, что изменение стало доступно пользователям. Термин предполагает достаточно крупное действие: выкатывают обычно версию целиком, а не один файл.

«Залить» — более конкретный термин, означающий загрузку файлов, данных или артефактов на сервер или в хранилище. «Залить билд на сервер», «залить скрипты в БД», «залить ассеты в CDN». В отличие от «выкатить», термин не подразумевает, что залитое стало доступно пользователям — файлы могут лежать на сервере, но ещё не быть подключены к приложению. Нюанс: «залить» также используется про отправку кода в репозиторий («залил на GitHub»).

«Накатить» — термин, означающий применение изменения поверх существующей версии. «Накатить миграцию», «накатить патч», «накатить конфиг». Ключевое отличие — изменение накладывается сверху без полной замены. Если «выкатить» — это запустить новую версию вместо старой, то «накатить» — это добавить изменение к тому, что уже работает. Термин распространён в контексте баз данных (миграции) и патч-релизов.

Дополнительные термины из этого же семантического поля: «раскатить» (распространить изменение на все серверы в кластере), «откатить» (вернуть предыдущую версию), «пролить» (случайно задеплоить не ту версию). Все эти глаголы описывают действия с кодом как с физическим объектом, который можно «катить», «лить» и «катить назад».

Происхождение сленговых терминов

Термин «выкатить» происходит из автомобильной метафоры: «выкатить машину из гаража». Когда код готов к релизу, его «выкатывают» — выпускают наружу, делают доступным для пользователей. Метафора распространилась в early 2000-х с появлением continuous delivery-практик, когда релизы стали регулярными, а не ежегодными. «У нас сегодня выкатка» — означает день релиза.

Термин «залить» имеет корни в раннем вебе, когда сайты загружались на сервера по FTP. «Залить файлы на сервер» — буквально передать файлы по протоколу, который ассоциировался с «заливанием» данных. Слово закрепилось, хотя современный деплой использует CI/CD-пайплайны, а не FTP-клиенты. Интересный факт: в английском языке аналог — «push» (push to server), а не «pour». Русский язык выбрал другую метафору.

Термин «накатить» пришёл из производственной среды: «накатить колесо», «накатить гайку». В контексте ПО — наложить изменение сверху существующей системы, как накатывают резьбу на болт. В базах данных термин особенно органичен: миграции именно «накатываются» (apply) и «откатываются» (rollback). Rollback — один из немногих английских терминов, который имеет точный русский аналог «откат».

Разница между терминами в разных контекстах

В контексте баз данных: миграции «накатывают», данные «заливают», версию схемы «выкатывают». Если нужно добавить новую колонку — накатывают миграцию. Если нужно вставить тестовые данные — заливают дамп. Если меняется структура БД целиком — выкатывают новую схему. Разница отражает разные операции: apply, insert/load, deploy.

В контексте DevOps: «выкатить» — запустить пайплайн, «залить» — загрузить Docker-образ в registry, «накатить» — применить конфигурацию к серверу через Ansible. Пример: «сначала зальём образ в registry, потом накатим конфиг на сервер, и только потом выкатим релиз». Каждый термин соответствует отдельному этапу CI/CD пайплайна.

В контексте мобильной разработки: «залить» — отправить билд в App Store Connect или Google Play Console, «выкатить» — опубликовать в магазине приложений, «накатить» — доставить обновление через механизм in-app updates. Для iOS «выкатить» означает пройти Review, для Android — rollout через Play Console. Временная шкала: «залить» занимает минуты, «выкатить» — часы или дни (из-за ревью).

Этапы процесса релиза: от коммита до продакшена

Этап 1: Сборка (Build). Код компилируется, собирается артефакт (бинарник, Docker-образ, APK/IPA). CI-сервер запускает сборку после каждого коммита в основную ветку. Результат сборки — готовый к деплою артефакт с уникальным тегом версии (semantic versioning или commit hash). Если сборка падает — весь пайплайн останавливается, разработчик получает уведомление.

Этап 2: Тестирование (Test). Запускаются unit-тесты, интеграционные тесты, линтеры, проверка безопасности (SAST). Этот этап должен занимать не более 10–15 минут — если дольше, разработчики теряют контекст и переключаются на другие задачи. Быстрая обратная связь — ключевой принцип CI/CD. По данным Puppet State of DevOps 2023, команды с быстрым тестированием (<10 мин) делают в 3 раза больше релизов.

Этап 3: Деплой на стейджинг (Staging Deploy). Артефакт разворачивается на стейджинг-окружении, идентичном продакшену. На стейджинге выполняются E2E-тесты, smoke-тесты и, при необходимости, ручное тестирование QA. Если на стейджинге обнаружена регрессия — релиз блокируется, изменения отправляются на доработку.

Этап 4: Раскатка на продакшен (Production Deploy). Артефакт разворачивается на продакшен-серверах. В зависимости от стратегии деплоя (rolling, blue-green, canary) раскатка может занимать от нескольких секунд до нескольких часов. После раскатки запускаются post-deploy тесты и мониторинг — если метрики в норме, релиз считается успешным. Автоматический откат при превышении порога ошибок — стандартная практика.

Стратегии деплоя: rolling, blue-green, canary

Rolling deploy — обновление серверов по одному. Пока один сервер обновляется, остальные продолжают обслуживать пользователей. После успешного обновления первого сервера обновляется второй, и так далее. Минус: во время деплоя на серверах работают разные версии, что может вызывать несовместимость. Плюс: zero-downtime и отсутствие необходимости в двойном количестве серверов.

Blue-green deploy — два идентичных окружения: Blue (текущая версия) и Green (новая версия). После того как Green полностью готов и протестирован, балансировщик переключает трафик с Blue на Green. Если на Green обнаружена проблема — переключаемся обратно на Blue. Плюс: мгновенный rollback. Минус: нужно вдвое больше ресурсов (серверов) для поддержки двух окружений. Переключение занимает секунды.

Canary deploy — новая версия сначала разворачивается на небольшой процент серверов (5–10%). Часть пользователей попадает на новую версию, остальные — на старую. Если метрики на canary-группе в норме (error rate не вырос, latency не увеличился), то новая версия постепенно раскатывается на все серверы. Google, Netflix, Spotify используют canary deploy для минимизации рисков. Минус: сложность мониторинга и анализа метрик.

Инструменты автоматизации деплоя

CI/CD серверы — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (для мобильных). Выбираются в зависимости от стека: Jenkins — универсальный, GitLab CI — если репозиторий на GitLab, Bitrise — для iOS/Android. Основная задача CI/CD сервера — автоматическое выполнение пайплайна сборки, тестирования и деплоя без участия человека.

Контейнеризация — Docker, Kubernetes. Docker создаёт изолированные контейнеры с приложением и всеми зависимостями. Kubernetes управляет развёртыванием контейнеров на кластере серверов: автоматический rolling update, масштабирование, балансировка. По данным CNCF Survey 2023, 96% организаций используют контейнеры в production, из них 67% — Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform описывает инфраструктуру (серверы, сети, балансировщики) в виде кода и управляет её состоянием. Ansible — конфигурация серверов: установка ПО, настройка параметров. Комбинация Terraform + Ansible даёт полностью автоматизированную инфраструктуру: Terraform поднимает серверы, Ansible настраивает их. Immutable infrastructure — серверы не обновляются, а заменяются новыми с обновлённым образом.