Continuous Delivery (CD): apa itu dan apa bedanya dengan Continuous Deployment

Apa itu Continuous Delivery

Continuous Delivery (CD) — ini adalah perluasan dari Continuous Integration yang menambahkan otomatisasi untuk semua tahap persiapan rilis: membangun build rilis, penandatanganan dengan sertifikat, obfuskasi, pemeriksaan metadata toko aplikasi, dan deploy ke staging. Istilah ini diperkenalkan oleh Jez Humble dan David Farley dalam buku „Continuous Delivery“ (2010), di mana mereka memformalkan praktik yang memungkinkan tim membuat rilis menjadi dapat diprediksi dan berisiko rendah.

Evolusi pengiriman perangkat lunak

Sebelum penerapan CD, rilis adalah sebuah peristiwa: tim berkumpul di sebuah ruangan, mengerjakan daftar periksa 20 poin, menjalankan skrip secara manual, dan berharap tidak ada yang rusak. Continuous Delivery mengubah rilis dari sebuah peristiwa menjadi sebuah proses: perubahan kecil pada kode dapat dikirimkan kepada pengguna dalam hitungan menit, bukan minggu. Amazon, Netflix, dan Etsy adalah yang pertama menerapkan CD pada tahun 2010-an — saat ini ini adalah standar untuk tim produk.

Nilai bisnis CD

Pengiriman fitur yang cepat adalah keunggulan kompetitif. Jika pesaing meluncurkan fungsionalitas baru dalam hitungan hari dan Anda dalam hitungan bulan, pasar akan memilih pesaing. Metrik DORA menunjukkan: tim elite (dengan CD) memiliki waktu rilis kurang dari 1 jam, tim low (tanpa CD) — dari 1 minggu hingga 1 bulan. CD juga secara radikal mengurangi risiko: perubahan kecil lebih sulit untuk dirusak daripada rilis besar sekali dalam seperempat.

CD vs CI vs Continuous Deployment

Istilah CI, CD, dan Continuous Deployment sering tertukar, tetapi ada batas yang jelas di antara ketiganya. Memahami perbedaannya membantu merancang pipeline dengan benar dan memilih tingkat otomatisasi yang sesuai dengan kematangan tim dan kebutuhan bisnis.

Continuous Integration

CI adalah fondasi tempat CD dibangun. CI memastikan setiap commit lolos build dan pengujian. Tanpa CI, CD tidak mungkin dilakukan: jika kode belum diverifikasi, kode tidak dapat dirilis. CI memeriksa kebenaran, CD memeriksa kesiapan untuk penggunaan bisnis.

Continuous Delivery

CD menambahkan ke CI tahap persiapan build rilis, pemeriksaan metadata, penandatanganan, dan deployment ke staging atau ke toko aplikasi untuk pengujian beta. Perbedaan utama — keputusan tentang rilis ke produksi dibuat oleh manusia (manajer, pemilik produk). CD membuat rilis menjadi „satu klik“ — sederhana dan aman.

Continuous Deployment

Continuous Deployment adalah otomatisasi penuh: setiap perubahan yang lolos semua tahap pipeline CD secara otomatis dikirim ke produksi tanpa konfirmasi manual. Continuous Deployment berlaku untuk produk SaaS dan layanan web, tetapi jarang digunakan dalam pengembangan seluler karena kebijakan toko aplikasi (App Store Review, Google Play Review memerlukan pengiriman manual).

Continuous Delivery untuk aplikasi seluler

CD untuk aplikasi seluler memiliki kekhasan yang membedakannya dari pipeline web dan backend. Rilis seluler melewati toko aplikasi (App Store Review, Google Play Review), yang menambah hambatan waktu dan proses. CD mengotomatiskan semua yang dapat diotomatiskan sebelum pengiriman ke review, untuk memaksimalkan peluang lolos pemeriksaan pada percobaan pertama.

Persiapan publikasi di Google Play

Pipeline Android CD mencakup: membangun AAB (Android App Bundle), penandatanganan dengan kunci rilis, obfuskasi melalui R8/ProGuard, pemeriksaan ukuran APK dan kelas multidex, pembuatan catatan rilis. Menggunakan Gradle product flavors (free/paid, dev/staging/prod) memungkinkan mengelola beberapa konfigurasi dari satu pipeline.

Persiapan publikasi di App Store

iOS CD memerlukan penandatanganan dengan sertifikat melalui Fastlane match, pemeriksaan kesesuaian ikon (persyaratan App Store — 1024×1024 px), validasi metadata (nama, deskripsi, kata kunci), pemeriksaan tidak adanya API privat. Validasi teknis dilakukan melalui altool --validate-app tanpa mengunggah ke App Store Connect, yang memberikan umpan balik cepat.

# Fastfile — pipeline CD lengkap untuk iOS dan Android
platform :ios do
  desc "iOS CD — persiapan rilis dan unggah ke 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 — membangun AAB dan unggah ke 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 mengumpulkan tangkapan layar, mendapatkan sertifikat melalui match, membangun IPA, dan mengunggahnya ke TestFlight. Lane deliver_to_internal untuk Android membangun Release AAB melalui Gradle dan mengunggahnya ke trek internal Google Play Console. Kedua pipeline dijalankan dari CI setelah pengujian lolos.

Komponen pipeline CD

Pipeline CD terdiri dari tahapan berurutan, yang masing-masing menambah keyakinan bahwa rilis siap untuk pengguna. Tahapan dibagi menjadi teknis (build, penandatanganan) dan produk (pemeriksaan metadata, tangkapan layar, deskripsi). Melewatkan tahap apa pun meningkatkan risiko penolakan rilis oleh toko aplikasi.

Manajemen versi

Komponen penting CD adalah manajemen versi otomatis. Version bump (versionCode dan versionName untuk Android, CFBundleVersion dan CFBundleShortVersionString untuk iOS) dilakukan berdasarkan tag Git atau versi sebelumnya di toko. Fastlane increment_version_number dan perintah Gradle (versionCode auto-increment) mengotomatiskan langkah ini.

Metadata toko

Google Play Console dan App Store Connect memerlukan: deskripsi aplikasi, kata kunci, kategori, peringkat, tautan ke kebijakan privasi. CD mencakup pemeriksaan keberadaan dan kebenaran metadata. Fastlane deliver dan supply mengotomatiskan pengunggahan deskripsi, tangkapan layar, dan ikon bersama dengan build.

Pemeriksaan gate

Sebelum pengiriman ke review, pipeline melakukan pemeriksaan gate: pemeriksaan ukuran build (APK lebih dari 200 MB ditolak oleh Google Play), keberadaan semua lokalisasi, tidak adanya simbol debug dalam build rilis, pemeriksaan file mapping ProGuard untuk mendekode log crash. Jika salah satu pemeriksaan gagal, pipeline memblokir rilis.

Pengujian otomatis untuk CD

Tingkat kepercayaan pada CD berbanding lurus dengan kualitas pengujian otomatis. Jika pengujian tidak menangkap regresi, rilis dapat merusak produksi, dan tim kehilangan kepercayaan pada CD. CD seluler memerlukan piramida pengujian tiga tingkat yang disesuaikan dengan kekhasan platform.

Pengujian unit

Unit test memeriksa logika bisnis secara terisolasi. Cakupan kode harus minimal 70% untuk modul kritis (otentikasi, pembayaran, kerja jaringan). CI menjalankan unit test pada setiap push, dan jika gagal, pipeline CD diblokir sampai diperbaiki.

Pengujian integrasi

Memeriksa interaksi komponen: lapisan jaringan dengan API nyata (atau server mock), basis data, sistem file. Test Room DAO untuk Android, test Core Data untuk iOS — contoh pengujian integrasi. Test ini lebih lambat daripada unit test (1–5 menit) dan dijalankan pada tahap CD, bukan di CI pada setiap commit.

Pengujian UI dan tangkapan layar

Snapshot test (snapshot testing) membandingkan layar aplikasi dengan gambar referensi. Jika perubahan kode mengubah UI, test gagal, dan pengembang memeriksa apakah perubahan tersebut diharapkan. Android mendukung Roborazzi dan Paparazzi, iOS — SnapshotTesting dari Point-Free. Snapshot test dijalankan sebelum rilis sebagai bagian dari pipeline CD.

Praktik terbaik Continuous Delivery

Penerapan Continuous Delivery memerlukan tidak hanya alat, tetapi juga perubahan budaya tim. Praktik di bawah ini didasarkan pada pengalaman bertahun-tahun tim seluler dari Google, Spotify, dan Uber dan disesuaikan untuk proyek dengan ukuran apa pun.

Feature flags

Kode fitur baru dikirim ke produksi tetapi disembunyikan di balik flag. Feature flags memungkinkan merilis kode lebih awal sebelum fitur siap ditampilkan kepada pengguna, dan langsung menonaktifkannya jika ada masalah. Pustaka: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags adalah prasyarat untuk CD dalam proyek seluler.

Lingkungan staging

Sebelum pengiriman ke produksi, build ditempatkan di staging — lingkungan yang identik dengan produksi tetapi dengan data uji. Insinyur QA memeriksa fitur pada build staging yang diinstal melalui TestFlight atau trek Internal Testing. Jika staging lolos, build mendapatkan persetujuan untuk pengiriman ke review di toko.

Catatan rilis dan changelog

CD secara otomatis membuat catatan rilis berdasarkan pesan commit. Conventional Commits (feat:, fix:, chore:) dan tag Git dalam format semantic versioning memungkinkan mengurai riwayat perubahan. Fastlane changelog_from_git_commits mengumpulkan perubahan antara dua tag terakhir dan memformatnya untuk toko aplikasi.

Pemantauan setelah rilis

CD tidak berakhir dengan publikasi — setelah rilis, pemantauan dimulai: crash rate, ANR rate untuk Android, waktu mulai, frekuensi kegagalan pembayaran. Jika metrik melebihi batas normal, pipeline CD harus secara otomatis memutar balik rilis atau memberi tahu tim. Alat: Firebase Crashlytics, Sentry, New Relic.

// Contoh Feature Flag dengan Firebase Remote Config untuk 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")
    }
}

// Penggunaan dalam kode
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}