Melampaui Kode Aplikasi: Memperluas CI/CD ke Konfigurasi, Mobile, dan Feature Flags
Anda sudah memiliki pipeline CI/CD yang berjalan untuk kode aplikasi, migrasi database, dan provisioning infrastruktur. Deployment lebih mulus, rollback lebih cepat, dan tim Anda tidur lebih nyenyak di malam hari. Tapi ada perasaan mengganjal bahwa masih ada sesuatu yang kurang.
Masalahnya muncul dalam hal-hal kecil. Seorang rekan tim perlu mengubah string koneksi database untuk lingkungan staging. Perbaikannya sepele — hanya memperbarui nilai konfigurasi — tapi butuh siklus deployment penuh karena konfigurasi terkubur di dalam kode. Atau tim mobile Anda merilis versi baru, tapi review app store memakan waktu tiga hari, dan tidak ada yang merencanakan penundaan itu. Atau sebuah fitur yang seharusnya diluncurkan secara bertahap ke pengguna ternyata menyala atau mati sepenuhnya karena tidak ada mekanisme untuk mengontrolnya tanpa melakukan deployment ulang.
Ini bukan kasus pinggiran. Ini adalah area di mana sebagian besar implementasi CI/CD mulai menunjukkan keretakan. Kabar baiknya, memperluas pipeline Anda untuk menangani konfigurasi, aplikasi mobile, dan feature flags cukup mudah dilakukan setelah Anda tahu apa yang harus dicari.
Konfigurasi sebagai Jalur Pengiriman Terpisah
Sebagian besar tim memulai dengan menyimpan konfigurasi di environment variables atau file konfigurasi yang berada di samping kode aplikasi. Ini berfungsi sampai suatu saat tidak berfungsi lagi. Saat Anda perlu mengubah nilai untuk satu lingkungan tanpa menyentuh lingkungan lain, Anda menyadari bahwa konfigurasi dan kode memiliki kebutuhan siklus hidup yang berbeda.
Perubahan konfigurasi seharusnya tidak memerlukan build. Seharusnya tidak perlu menjalankan rangkaian tes lengkap. Seharusnya tidak memerlukan deployment yang me-restart aplikasi. String koneksi database, kunci API, atau nilai toggle fitur bukanlah kode. Memperlakukannya seperti kode hanya menambah gesekan yang tidak perlu.
Solusinya adalah memisahkan konfigurasi dari kode dan memberinya pipeline sendiri. Pipeline ini lebih sederhana daripada pipeline untuk kode aplikasi:
- Perubahan pada nilai konfigurasi di-commit ke repository
- Perubahan melalui proses review yang sama seperti perubahan kode
- Setelah disetujui, konfigurasi diterapkan ke lingkungan target
- Aplikasi mengambil nilai baru tanpa restart
Perbedaan utamanya adalah pipeline konfigurasi melewati tahap build dan test. Tidak ada yang perlu dikompilasi atau di-unit test. Yang penting adalah konfigurasi mencapai server yang tepat dan aplikasi dapat memuat ulang secara dinamis.
Pendekatan ini juga memudahkan audit. Setiap perubahan konfigurasi terlacak di version control, direview oleh rekan, dan diterapkan melalui pipeline. Tidak perlu lagi SSH ke server untuk mengubah nilai dan berharap tidak ada yang tahu.
Pipeline Mobile Memiliki Kendala Berbeda
Aplikasi mobile terlihat seperti proyek perangkat lunak lainnya sampai Anda mencoba men-deploy-nya. Proses build menghasilkan file installer yang harus ditandatangani secara digital. Distribusi melalui app store yang memiliki proses review sendiri. Dan begitu sebuah versi sudah di tangan pengguna, Anda tidak bisa memaksa mereka untuk memperbarui.
Kendala ini mengubah cara Anda mendesain pipeline. Tahap build dan unit test bekerja sama seperti untuk aplikasi backend. Tapi tahap deployment membutuhkan dua jalur terpisah:
Jalur pertama adalah untuk distribusi internal. Sebelum mengirim build ke app store, tim Anda perlu mengujinya di perangkat nyata. Platform seperti Firebase App Distribution untuk Android dan TestFlight untuk iOS memungkinkan Anda mendistribusikan build ke tim QA dan penguji beta tanpa melalui proses review app store. Pipeline Anda harus secara otomatis mengunggah build ke platform ini setiap kali versi baru siap untuk diuji.
Jalur kedua adalah untuk rilis produksi. Di sinilah pipeline mengirimkan build yang sudah ditandatangani ke Google Play Store atau Apple App Store. Pipeline tidak bisa mengontrol berapa lama review berlangsung, tapi bisa melacak statusnya. Saat review disetujui, pipeline dapat memicu rilis aktual ke pengguna.
Risk gate untuk pipeline mobile perlu mencakup pemeriksaan khusus untuk mobile. Tanggal kedaluwarsa sertifikat, validitas kunci penandatanganan, dan kenaikan nomor versi semuanya harus diverifikasi secara otomatis. Build dengan sertifikat kedaluwarsa akan ditolak oleh app store, dan mengetahuinya setelah menunggu review sangat menyakitkan.
Feature Flags Memungkinkan Peluncuran Bertahap
Feature flags adalah mekanisme yang memungkinkan Anda menyalakan atau mematikan fitur tanpa men-deploy kode baru. Mereka memecahkan masalah umum: sebuah fitur sudah selesai, tapi Anda tidak yakin apakah fitur itu siap untuk semua pengguna. Mungkin perlu pengujian lebih lanjut. Mungkin Anda ingin meluncurkannya ke persentase kecil pengguna terlebih dahulu. Mungkin Anda ingin kemampuan untuk menonaktifkannya dengan cepat jika ada yang salah.
Tanpa feature flags, pilihan Anda terbatas. Anda bisa menunda deployment sampai yakin, yang memperlambat pengiriman. Atau Anda bisa deploy dan berharap yang terbaik, yang meningkatkan risiko. Feature flags memberi Anda opsi ketiga: deploy fitur dalam keadaan dinonaktifkan, lalu aktifkan secara bertahap.
Menambahkan feature flags ke pipeline Anda memerlukan dua perubahan:
Pertama, pipeline harus memverifikasi bahwa kode berfungsi dengan benar di kedua keadaan. Saat sebuah fitur dibungkus dalam flag, tes harus dijalankan dengan flag diaktifkan dan dinonaktifkan. Ini menangkap masalah di mana logika feature flag itu sendiri memiliki bug, atau di mana keadaan dinonaktifkan merusak fungsionalitas yang ada.
Kedua, pipeline harus membantu Anda membersihkan flag yang tidak lagi diperlukan. Feature flags yang tetap berada di codebase selamanya menjadi utang teknis. Mereka menambah kompleksitas, membuat kode lebih sulit dibaca, dan meningkatkan risiko bug. Praktik yang baik adalah menambahkan tahap pipeline yang memeriksa flag yang telah diluncurkan sepenuhnya ke semua pengguna untuk periode tertentu, lalu secara otomatis membuat task untuk menghapusnya.
Checklist Praktis untuk Memperluas Pipeline Anda
Sebelum Anda mulai mengimplementasikan perubahan ini, jalankan checklist ini untuk mengidentifikasi apa yang perlu mendapat perhatian:
- Dapatkah Anda mengubah nilai konfigurasi untuk satu lingkungan tanpa men-deploy ulang aplikasi?
- Apakah setiap perubahan konfigurasi terlacak di version control dan direview sebelum diterapkan?
- Apakah pipeline mobile Anda secara otomatis mendistribusikan build ke penguji internal?
- Apakah pipeline mobile Anda memverifikasi kedaluwarsa sertifikat dan validitas kunci penandatanganan?
- Apakah feature flags diuji dalam keadaan diaktifkan dan dinonaktifkan?
- Apakah Anda memiliki proses untuk menghapus feature flags yang tidak lagi diperlukan?
Jika Anda menjawab tidak untuk salah satu dari ini, Anda memiliki langkah selanjutnya yang jelas.
Kesimpulan
CI/CD tidak lengkap ketika kode aplikasi Anda ter-deploy dengan mulus. CI/CD lengkap ketika setiap perubahan yang memengaruhi perilaku perangkat lunak Anda — apakah itu kode, konfigurasi, atau toggle fitur — melalui proses yang terkontrol, terotomatisasi, dan dapat diaudit. Pipeline konfigurasi menghilangkan gesekan perubahan spesifik lingkungan. Pipeline mobile menangani kendala unik distribusi app store. Feature flags memberi Anda kemampuan untuk mengontrol risiko tanpa memperlambat pengiriman.
Mulailah dengan area yang paling menyebabkan rasa sakit di tim Anda hari ini. Untuk sebagian besar tim, itu adalah manajemen konfigurasi. Setelah itu berfungsi, beralihlah ke mobile atau feature flags tergantung pada apa yang dikirimkan tim Anda. Tujuannya bukan untuk membangun pipeline yang sempurna di hari pertama. Tujuannya adalah memastikan tidak ada yang lolos dari celah.