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 метрики показують: елітні команди (з CD) мають час викатки менше 1 години, низькі команди (без 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. Технічна валідація виконується через 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()
}