Continuous Delivery (CD): что это, чем отличается от Continuous Deployment

Что такое Continuous Delivery

Continuous Delivery (CD) — это расширение Continuous Integration, добавляющее автоматизацию всех этапов подготовки релиза: сборку релизного билда, подписание сертификатами, обфускацию, проверку метаданных магазина приложений и деплой на стейджинг. Термин был введён Джезом Хамблом и Дэвидом Фарли в книге «Continuous Delivery» (2010), где они формализовали практику, позволяющую командам делать релизы предсказуемыми и низкорисковыми.

Эволюция доставки ПО

До внедрения CD релизы были событием: команда собиралась в комнате, выполняла чек-лист из 20 пунктов, запускала скрипты вручную и надеялась, что ничего не сломается. Continuous Delivery превращает релиз из события в процесс: небольшое изменение кода может быть выкачено пользователям за минуты, а не недели. Amazon, Netflix и Etsy первыми внедрили CD в 2010-х — сегодня это стандарт для продуктовых команд.

Бизнес-ценность CD

Быстрая доставка фич — конкурентное преимущество. Если конкурент выкатывает новую функциональность за дни, а вы — за месяцы, рынок выбирает конкурента. DORA метрики показывают: elite-команды (с CD) имеют время выкатки менее 1 часа, low-команды (без CD) — от 1 недели до 1 месяца. CD также радикально снижает риск: маленькие изменения сломать что-то сложнее, чем большой релиз раз в квартал.

CD vs CI vs Continuous Deployment

Термины CI, CD и Continuous Deployment часто путают, но между ними есть чёткая граница. Понимание различий помогает правильно спроектировать пайплайн и выбрать уровень автоматизации, соответствующий зрелости команды и бизнес-требованиям.

Continuous Integration

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

Continuous Delivery

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

Continuous Deployment

Continuous Deployment — это полная автоматизация: каждое изменение, прошедшее все стадии CD-пайплайна, автоматически отправляется в продакшн без ручного подтверждения. Continuous Deployment применим для SaaS-продуктов и веб-сервисов, но редко используется в мобильной разработке из-за политик магазинов приложений (App Store Review, Google Play Review требует ручной отправки).

Continuous Delivery для мобильных приложений

CD для мобильных приложений имеет особенности, отличающие его от веб- и backend-пайплайнов. Мобильные релизы проходят через магазины приложений (App Store Review, Google Play Review), что добавляет временной и процессуальный барьер. CD автоматизирует всё, что можно автоматизировать до отправки на ревью, чтобы максимизировать шанс прохождения проверки с первого раза.

Подготовка к публикации в Google Play

Android CD пайплайн включает: сборку AAB (Android App Bundle), подписание релизным ключом, обфускацию через R8/ProGuard, проверку размера APK и классов multidex, генерацию релизных нот. Использование Gradle product flavors (free/paid, dev/staging/prod) позволяет управлять несколькими конфигурациями из одного пайплайна.

Подготовка к публикации в App Store

iOS CD требует подписания сертификатами через Fastlane match, проверки соответствия иконок (требование App Store — 1024×1024 px), валидации метаданных (название, описание, ключевые слова), проверки отсутствия приватных API. Techincal validation выполняется через altool --validate-app без загрузки в App Store Connect, что даёт быструю обратную связь.

# Fastfile — полный CD пайплайн для iOS и Android
platform :ios do
  desc "iOS CD — подготовка релиза и загрузка в TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "Android CD — сборка AAB и загрузка в Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight собирает скриншоты, получает сертификаты через match, собирает IPA и загружает в TestFlight. Лейн deliver_to_internal для Android собирает Release AAB через Gradle и загружает его на внутренний трек Google Play Console. Оба пайплайна запускаются из CI после прохождения тестов.

Компоненты CD-пайплайна

CD-пайплайн состоит из последовательных этапов, каждый из которых добавляет уверенность в том, что релиз готов к пользователям. Этапы делятся на технические (сборка, подписание) и продуктовые (проверка метаданных, скриншотов, описания). Пропуск любого этапа увеличивает риск отклонения релиза магазином приложений.

Управление версиями

Критический компонент CD — автоматическое управление версиями. Version bump (versionCode и versionName для Android, CFBundleVersion и CFBundleShortVersionString для iOS) выполняется на основе Git-тегов или предыдущей версии в магазине. Fastlane increment_version_number и команды Gradle (versionCode auto-increment) автоматизируют этот шаг.

Метаданные магазина

Google Play Console и App Store Connect требуют: описание приложения, ключевые слова, категорию, рейтинг, ссылки на политику конфиденциальности. CD включает проверку наличия и корректности метаданных. Fastlane deliver и supply автоматизируют загрузку описания, скриншотов и иконок вместе с билдом.

Gate-проверки

Перед отправкой на ревью пайплайн выполняет gate-проверки: проверка размера билда (APK > 200 МБ отклоняется Google Play), наличие всех локализаций, отсутствие debug-символов в релизном билде, проверка ProGuard mapping file для декодирования crash-логов. Если хоть одна проверка не прошла — пайплайн блокирует релиз.

Автоматизированное тестирование для CD

Уровень доверия к CD прямо пропорционален качеству автоматических тестов. Если тесты не ловят регрессии — релиз может сломать продакшн, и команда теряет уверенность в CD. Мобильный CD требует трёхуровневой пирамиды тестирования, адаптированной под специфику платформы.

Модульные тесты

Юнит-тесты проверяют бизнес-логику изолированно. Покрытие кода должно быть не менее 70% для критических модулей (аутентификация, платежи, работа с сетью). CI запускает юнит-тесты на каждый push, и если они падают — CD-пайплайн блокируется до исправления.

Интеграционные тесты

Проверяют взаимодействие компонентов: сетевой слой с реальным API (или mock-сервером), база данных, файловая система. Room DAO тесты для Android, Core Data тесты для iOS — примеры интеграционных тестов. Они медленнее юнит-тестов (1–5 минут) и выполняются на этапе CD, а не CI при каждом коммите.

UI и скриншотные тесты

Сриншотные тесты (snapshot testing) сравнивают экраны приложения с эталонными изображениями. Если изменение кода изменило UI — тест падает, и разработчик проверяет, ожидаемо ли изменение. Android поддерживает Roborazzi и Paparazzi, iOS — SnapshotTesting от Point-Free. Скриншотные тесты выполняются перед релизом как часть CD-пайплайна.

Лучшие практики Continuous Delivery

Внедрение Continuous Delivery требует не только инструментов, но и изменения культуры команды. Практики ниже основаны на многолетнем опыте мобильных команд из Google, Spotify и Uber и адаптированы для проектов любого размера.

Feature flags

Код новой фичи поставляется в продакшн, но скрыт за флагом. Feature flags позволяют выкатить код раньше, чем фича будет готова к показу пользователям, и мгновенно отключить её при проблемах. Библиотеки: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags — обязательное условие для CD в мобильных проектах.

Staging окружение

Перед отправкой в продакшн билд выкладывается на staging — окружение, идентичное продакшну, но с тестовыми данными. QA-инженеры проверяют фичу на staging билде, установленном через TestFlight или Internal Testing трек. Если staging проходит — билд получает approval для отправки на ревью в магазин.

Релизные ноты и changelog

CD автоматически генерирует релизные ноты на основе commit messages. Conventional Commits (feat:, fix:, chore:) и Git-теги в формате semantic versioning позволяют парсить историю изменений. Fastlane changelog_from_git_commits собирает изменения между последними двумя тегами и форматирует их для магазина приложений.

Мониторинг после релиза

CD не заканчивается публикацией — после релиза запускается мониторинг: crash rate, ANR rate для Android, время запуска, частота отказов в платежах. Если метрики выходят за пределы нормы — CD пайплайн должен автоматически откатить релиз или оповестить команду. Инструменты: Firebase Crashlytics, Sentry, New Relic.

// Пример Feature Flag с Firebase Remote Config для CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Использование в коде
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}