Continuous Delivery (CD): ano ito at ano ang kaibahan nito sa Continuous Deployment

Ano ang Continuous Delivery

Continuous Delivery (CD) — ito ay extension ng Continuous Integration na nagdaragdag ng automation sa lahat ng yugto ng paghahanda ng release: pagbuo ng release build, pagpirma gamit ang mga certificate, obfuscation, pagsusuri sa metadata ng app store, at deploy sa staging. Ang termino ay ipinakilala nina Jez Humble at David Farley sa aklat na „Continuous Delivery“ (2010), kung saan nila pinormalisa ang practice na nagbibigay-daan sa mga team na gawing predictable at mababa ang panganib ang mga release.

Ebolusyon ng paghahatid ng software

Bago ang pagpapatupad ng CD, ang mga release ay isang pangyayari: nagtitipon ang team sa isang silid, ginagawa ang isang checklist na may 20 na item, manu-manong nagpapatakbo ng mga script, at umaasa na walang masisira. Continuous Delivery ay ginagawang isang proseso ang release mula sa pangyayari: ang maliit na pagbabago sa code ay maaaring maihatid sa mga user sa loob ng ilang minuto, hindi mga linggo. Ang Amazon, Netflix, at Etsy ang unang nagpatupad ng CD noong mga 2010 — ngayon ito ay pamantayan para sa mga product team.

Business value ng CD

Ang mabilis na paghahatid ng mga feature ay competitive advantage. Kung ang kakumpitensya ay naglulunsad ng bagong functionality sa loob ng mga araw, at ikaw ay sa loob ng mga buwan, pipiliin ng merkado ang kakumpitensya. DORA metrics ay nagpapakita: ang elite team (may CD) ay may oras ng pag-release na mas mababa sa 1 oras, ang low team (walang CD) — mula 1 linggo hanggang 1 buwan. Ang CD din ay radikal na binabawasan ang panganib: mas mahirap sirain ang maliliit na pagbabago kaysa sa malaking release isang beses sa isang quarter.

CD vs CI vs Continuous Deployment

Ang mga terminong CI, CD at Continuous Deployment ay madalas na napagkakamalan, ngunit may malinaw na hangganan sa pagitan nila. Ang pag-unawa sa mga pagkakaiba ay nakakatulong upang maayos na idisenyo ang pipeline at pumili ng antas ng automation na naaayon sa kapanahunan ng team at mga pangangailangan ng negosyo.

Continuous Integration

Ang CI ay ang pundasyon kung saan binuo ang CD. Ginagarantiya ng CI na ang bawat commit ay dumadaan sa build at mga test. Kung walang CI, imposible ang CD: kung hindi na-verify ang code, hindi ito maaaring i-release. Ang CI ay sumusuri sa kawastuhan, ang CD ay sumusuri sa kahandaan para sa paggamit ng negosyo.

Continuous Delivery

Ang CD ay nagdaragdag sa CI ng mga yugto ng paghahanda ng release build, pagsusuri ng metadata, pagpirma, at deployment sa staging o sa app store para sa beta testing. Ang pangunahing pagkakaiba — ang desisyon tungkol sa release sa produksyon ay ginagawa ng tao (manager, product owner). Ginagawa ng CD na „isang pagpindot“ ang release — simple at ligtas.

Continuous Deployment

Ang Continuous Deployment ay buong automation: ang bawat pagbabago na dumaan sa lahat ng yugto ng CD pipeline ay awtomatikong ipinapadala sa produksyon nang walang manu-manong kumpirmasyon. Naaangkop ang Continuous Deployment para sa mga produkto ng SaaS at web services, ngunit bihirang ginagamit sa mobile development dahil sa mga patakaran ng app store (ang App Store Review, Google Play Review ay nangangailangan ng manu-manong pagsusumite).

Continuous Delivery para sa mga mobile app

Ang CD para sa mga mobile app ay may mga katangian na nagpapaiba nito sa mga web at backend pipeline. Ang mga mobile release ay dumadaan sa mga app store (App Store Review, Google Play Review), na nagdaragdag ng hadlang sa oras at proseso. Ina-automate ng CD ang lahat ng maaaring i-automate bago ipadala sa review, upang ma-maximize ang tsansa na maipasa ang pagsusuri sa unang pagsubok.

Paghahanda para sa publikasyon sa Google Play

Ang Android CD pipeline ay may kasamang: pagbuo ng AAB (Android App Bundle), pagpirma gamit ang release key, obfuscation sa pamamagitan ng R8/ProGuard, pagsusuri sa laki ng APK at mga multidex class, pagbuo ng mga release notes. Ang paggamit ng Gradle product flavors (free/paid, dev/staging/prod) ay nagbibigay-daan upang pamahalaan ang maraming configuration mula sa isang pipeline.

Paghahanda para sa publikasyon sa App Store

Ang iOS CD ay nangangailangan ng pagpirma gamit ang mga certificate sa pamamagitan ng Fastlane match, pagsusuri sa pagsunod ng mga icon (kinakailangan ng App Store — 1024×1024 px), pag-validate ng metadata (pangalan, deskripsyon, mga keyword), pagsusuri sa kawalan ng mga private API. Ang teknikal na validation ay ginagawa sa pamamagitan ng altool --validate-app nang hindi nag-a-upload sa App Store Connect, na nagbibigay ng mabilis na feedback.

# Fastfile — kumpletong CD pipeline para sa iOS at Android
platform :ios do
  desc "iOS CD — paghahanda ng release at pag-upload sa 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 — pagbuo ng AAB at pag-upload sa 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

Ang Fastlane deliver_to_testflight ay nag-iipon ng mga screenshot, kumukuha ng mga certificate sa pamamagitan ng match, nagbu-build ng IPA, at nag-a-upload sa TestFlight. Ang lane na deliver_to_internal para sa Android ay nagbu-build ng Release AAB sa pamamagitan ng Gradle at ina-upload ito sa internal track ng Google Play Console. Ang parehong pipeline ay pinapatakbo mula sa CI pagkatapos maipasa ang mga test.

Mga bahagi ng CD pipeline

Ang CD pipeline ay binubuo ng magkakasunod na yugto, na ang bawat isa ay nagdaragdag ng kumpiyansa na ang release ay handa para sa mga user. Ang mga yugto ay nahahati sa teknikal (build, pagpirma) at produkto (pagsusuri ng metadata, screenshots, deskripsyon). Ang paglaktaw sa anumang yugto ay nagpapataas ng panganib ng pagtanggi sa release ng app store.

Pamamahala ng bersyon

Ang kritikal na bahagi ng CD ay awtomatikong pamamahala ng bersyon. Ang Version bump (versionCode at versionName para sa Android, CFBundleVersion at CFBundleShortVersionString para sa iOS) ay ginagawa batay sa mga Git tag o nakaraang bersyon sa store. Ang Fastlane increment_version_number at mga command ng Gradle (versionCode auto-increment) ay nag-a-automate sa hakbang na ito.

Metadata ng store

Ang Google Play Console at App Store Connect ay nangangailangan ng: deskripsyon ng app, mga keyword, kategorya, rating, mga link sa privacy policy. Kasama sa CD ang pagsusuri sa presensya at kawastuhan ng metadata. Ang Fastlane deliver at supply ay nag-a-automate ng pag-upload ng deskripsyon, screenshots, at mga icon kasama ng build.

Mga gate check

Bago ipadala sa review, ang pipeline ay nagsasagawa ng mga gate check: pagsusuri sa laki ng build (ang APK na higit sa 200 MB ay tinatanggihan ng Google Play), presensya ng lahat ng localization, kawalan ng debug symbols sa release build, pagsusuri sa ProGuard mapping file para sa pag-decode ng mga crash log. Kung may hindi maipasa sa mga check, binablock ng pipeline ang release.

Automated na testing para sa CD

Ang antas ng tiwala sa CD ay direktang proporsyonal sa kalidad ng mga awtomatikong test. Kung hindi nahuhuli ng mga test ang mga regression, ang release ay maaaring makasira sa produksyon, at mawawalan ng tiwala ang team sa CD. Ang mobile CD ay nangangailangan ng tatlong antas na testing pyramid, na inangkop sa katangian ng platform.

Unit test

Ang mga unit test ay sumusuri sa business logic nang nakahiwalay. Ang code coverage ay dapat na hindi bababa sa 70% para sa mga kritikal na module (authentication, pagbabayad, paggamit ng network). Pinapatakbo ng CI ang mga unit test sa bawat push, at kung pumalpak ang mga ito, binablock ang CD pipeline hanggang sa maayos.

Integration test

Sinusuri ang interaksyon ng mga component: ang network layer na may tunay na API (o mock server), database, file system. Ang mga Room DAO test para sa Android, mga Core Data test para sa iOS — mga halimbawa ng integration test. Mas mabagal ang mga ito kaysa sa mga unit test (1–5 minuto) at pinapatakbo sa yugto ng CD, hindi sa CI sa bawat commit.

UI at screenshot test

Ang mga screenshot test (snapshot testing) ay naghahambing ng mga screen ng app sa mga reference na imahe. Kung binago ng pagbabago sa code ang UI, pumapalpak ang test, at sinusuri ng developer kung inaasahan ang pagbabago. Sinusuportahan ng Android ang Roborazzi at Paparazzi, iOS — ang SnapshotTesting mula sa Point-Free. Ang mga screenshot test ay pinapatakbo bago ang release bilang bahagi ng CD pipeline.

Pinakamahusay na practices ng Continuous Delivery

Ang pagpapatupad ng Continuous Delivery ay nangangailangan hindi lamang ng mga tool, kundi pati na rin ng pagbabago sa kultura ng team. Ang mga practice sa ibaba ay nakabatay sa maraming taon ng karanasan ng mga mobile team mula sa Google, Spotify, at Uber at inangkop para sa mga proyekto ng anumang laki.

Feature flags

Ang code ng bagong feature ay inihahatid sa produksyon ngunit nakatago sa likod ng isang flag. Ang mga Feature flags ay nagbibigay-daan na ilabas ang code nang mas maaga bago handa ang feature na ipakita sa mga user, at agad itong patayin kung may mga problema. Mga library: LaunchDarkly, Firebase Remote Config, Unleash. Ang mga Feature flags ay obligadong kondisyon para sa CD sa mga mobile na proyekto.

Staging environment

Bago ipadala sa produksyon, ang build ay inilalagay sa staging — kapaligiran na kapareho ng produksyon ngunit may test data. Ang mga QA engineer ay sumusuri sa feature sa staging build, na naka-install sa pamamagitan ng TestFlight o Internal Testing track. Kung naipasa ang staging, ang build ay makakatanggap ng approval para sa pagsusumite sa review sa store.

Release notes at changelog

Ang CD ay awtomatikong gumagawa ng mga release notes batay sa mga commit message. Ang Conventional Commits (feat:, fix:, chore:) at mga Git tag sa format ng semantic versioning ay nagbibigay-daan upang i-parse ang kasaysayan ng mga pagbabago. Ang Fastlane changelog_from_git_commits ay nag-iipon ng mga pagbabago sa pagitan ng huling dalawang tag at ina-format ang mga ito para sa app store.

Monitoring pagkatapos ng release

Hindi natatapos ang CD sa publikasyon — pagkatapos ng release, nagsisimula ang monitoring: crash rate, ANR rate para sa Android, oras ng pagsisimula, dalas ng mga failure sa pagbabayad. Kung lumampas ang mga metric sa normal na limitasyon, dapat na awtomatikong i-revert ng CD pipeline ang release o ipaalam sa team. Mga tool: Firebase Crashlytics, Sentry, New Relic.

// Halimbawa ng Feature Flag na may Firebase Remote Config para sa 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")
    }
}

// Paggamit sa code
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}