Continuous Delivery (CD): шта је то и по чему се разликује од Continuous Deployment

Шта је Continuous Delivery

Continuous Delivery (CD) — то је проширење Continuous Integration-а, које додаје аутоматизацију свих фаза припреме издања: прављење издавачког билда, потписивање сертификатима, обфускацију, проверу метаподатака продавнице апликација и деплој на 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 гарантује да сваки комит пролази прављење и тестове. Без CI-ја CD је немогућ: ако код није верификован, не може се издати. CI проверава исправност, CD проверава спремност за пословну употребу.

Continuous Delivery

CD додаје CI-ју фазе припреме издавачког билда, провере метаподатака, потписивања и распоређивања на 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), потписивање издавачким кључем, обфускацију преко 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 MB одбија Google Play), постојање свих локализација, одсуство debug симбола у издавачком билду, проверу ProGuard mapping датотеке за декодовање crash логова. Ако било која провера не прође — пајплајн блокира издање.

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

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

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

Јунит тестови проверавају пословну логику изоловано. Покривеност кода треба да буде најмање 70% за критичне модуле (аутентификација, плаћања, рад са мрежом). CI покреће јунит тестове на сваки push, и ако падају — CD пајплајн се блокира до исправке.

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

Проверавају интеракцију компоненти: мрежни слој са правим API-јем (или mock сервером), база података, датотечни систем. Room DAO тестови за Android, Core Data тестови за iOS — примери интеграционих тестова. Спорији су од јунит тестова (1–5 минута) и извршавају се на CD фази, а не на CI-ју при сваком комиту.

UI и screenshot тестови

Снимак тестови (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 прође — билд добија одобрење за слање на ревју у продавницу.

Белешке за издање и changelog

CD аутоматски генерише белешке за издање на основу 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()
}