Continuous Delivery (CD): какво е и с какво се различава от Continuous Deployment

Какво е Continuous Delivery

Continuous Delivery (CD) — това е разширение на Continuous Integration, което добавя автоматизация на всички етапи от подготовката на версията: изграждане на release build, подписване със сертификати, обфускация, проверка на метаданните на магазина за приложения и deploy до staging. Терминът е въведен от Джез Хъмбъл и Дейвид Фарли в книгата „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 гарантира, че всеки commit преминава през изграждане и тестове. Без CI CD е невъзможно: ако кодът не е проверен, той не може да бъде издаден. CI проверява коректността, CD проверява готовността за бизнес употреба.

Continuous Delivery

CD добавя към CI етапи за подготовка на release build, проверка на метаданните, подписване и разгръщане на staging или в магазина за приложения за бета тестване. Ключовата разлика — решението за издаване в продукция се взема от човек (мениджър, собственик на продукта). 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), подписване с release ключ, обфускация чрез R8/ProGuard, проверка на размера на APK и multidex класовете, генериране на release бележки. Използването на 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 и го качва на вътрешния track на 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 автоматизират качването на описанието, екранните снимки и иконите заедно с build-а.

Gate проверки

Преди изпращане за ревю пайплайнът изпълнява gate проверки: проверка на размера на build-а (APK над 200 MB се отхвърля от Google Play), наличие на всички локализации, липса на debug символи в release build-а, проверка на ProGuard mapping файла за декодиране на crash логове. Ако някоя проверка не мине, пайплайнът блокира версията.

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

Нивото на доверие в CD е право пропорционално на качеството на автоматичните тестове. Ако тестовете не улавят регресии, версията може да счупи продукцията и екипът губи доверие в CD. Мобилният CD изисква тристепенна пирамида за тестване, адаптирана към спецификата на платформата.

Модулни тестове

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

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

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

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 среда

Преди изпращане в продукция build-ът се публикува на staging — среда, идентична с продукцията, но с тестови данни. QA инженерите проверяват функцията на staging build, инсталиран чрез TestFlight или Internal Testing track. Ако staging мине, build-ът получава одобрение за изпращане за ревю в магазина.

Release бележки и changelog

CD автоматично генерира release бележки на базата на commit съобщенията. 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()
}