В классическом релизном цикле принято копить изменения в большие пачки и выкладывать их все вместе. Скажем, если вы в один день сделали две фичи, одна из которых изменяет структуру данных, а другая добавляет полезную функциональность для пользователей, то в продакшен они «поедут» вместе. Если миграция из первой фичи почему‑то не пройдёт, то вторая фича с полезной функциональностью тоже, скорее всего, не запустится.

Или вы неделю делали большую фичу, для работы которой нужно обновить версию фреймворка, сделать пять разных миграций и запустить 2000 строк кода. В классическом релизном цикле вы, скорее всего, будете запускать её разом, и если хотя бы в какой‑то из этих частей что‑то пойдёт не так — вы узнаете об этом в самый последний момент, близко к дедлайну.

При непрерывной доставке всё проще: написали код — и сразу выкладываете на продакшен. Можно даже выкладывать частями — скажем, нашу гигантскую фичу на 2000 строк можно выложить четырьмя маленькими кусочками по 500 строк. Получится, что к моменту запуска уже бо́льшая часть вашего кода будет на продакшене, а значит, все вещи, которые могли выстрелить в момент публикации, например непроходящие миграции, скорее всего, выстрелят заранее.

Работающая непрерывная доставка — признак высокой инженерной культуры. К примеру, в классическом подходе каждый релиз — это большая работа для тестировщика: нужно руками проверить, что ничего не сломалось. Если доставлять код несколько раз в день, придётся либо нанимать неразумное количество тестировщиков, либо всё‑таки автоматизировать тестирование. Выкладывание кода тоже придётся автоматизировать — если вы привыкли вручную перекладывать файлы и запускать компиляцию ассетов, то никакой непрерывной доставки у вас не получится.

См. также: