Feature Toggle — dasar, jenis sakelar, dan penerapan

Q: Seberapa sering toggles lama harus dihapus?

Release toggles harus dihapus dalam 1–2 minggu setelah peluncuran selesai. Experiment toggles — segera setelah pengujian A/B selesai. Business toggles memerlukan audit rutin (setiap kuartal). Disarankan untuk menyiapkan pemeriksaan CI yang memblokir merge jika PR menambahkan toggle baru tanpa tugas penghapusan di task tracker.

Q: Bagaimana cara menguji kode dengan feature toggles?

Metode utama — pengujian matriks: menjalankan semua tes dengan toggle aktif dan nonaktif. Untuk N toggles, pengujian matriks penuh memerlukan 2^n kali proses, sehingga dalam praktiknya kombinasi kritis dipilih. Tes unit harus melakukan mock pada nilai toggle. Tes integrasi memeriksa skenario spesifik. Dalam CI, ditambahkan langkah yang menjalankan tes dengan kombinasi toggles acak untuk mendeteksi interaksi yang tidak terduga.

Penulis: IT Sectr Diterbitkan: 2026-04-13 Waktu membaca: 8 mnt

Feature Toggle adalah mekanisme untuk mengalihkan fungsionalitas aplikasi saat runtime, memungkinkan pengembang mengelola ketersediaan fitur tanpa mengubah kode dan men-deploy ulang. Tidak seperti kompilasi bersyarat (ifdef), toggle bekerja pada level runtime dan dapat berubah secara dinamis. Menurut Martin Fowler (2024), feature toggles adalah elemen kunci dari trunk-based development dan pengiriman berkelanjutan. Feature toggle memberi tim fleksibilitas dalam mengelola rilis dan eksperimen.

Poin Utama

Feature Toggle — sakelar dinamis yang mengontrol perilaku aplikasi melalui konfigurasi
Jenis utama: business toggles, release toggles, experiment toggles, dan infrastructure toggles
Feature Toggle vs Flag — toggle lebih sering merujuk pada sakelar biner sederhana, flag — pada platform lengkap
Integrasi dengan CI/CD memungkinkan pemeriksaan dan pengujian toggles secara otomatis di setiap tahap pipeline
Masalah utama — akumulasi stale toggles yang perlu diaudit dan dihapus secara teratur

Apa itu Feature Toggle

Feature Toggle (sakelar fungsionalitas) — adalah teknik di mana kode fitur baru dibungkus dalam konstruksi bersyarat yang memeriksa nilai parameter konfigurasi. Jika parameter true — fungsionalitas baru aktif, jika false — kode lama dijalankan. Perbedaan utama dari feature flag adalah bahwa toggle adalah sakelar biner yang bekerja berdasarkan prinsip „aktif/nonaktif”, tanpa aturan penargetan dan distribusi lalu lintas yang rumit.

Definisi dan prinsip kerja

Feature toggle diimplementasikan sebagai konstruksi if biasa di sekitar fungsionalitas baru. Nilai toggle disimpan dalam konfigurasi aplikasi — variabel lingkungan, file JSON, atau basis data. Saat startup, aplikasi memuat konfigurasi dan menggunakannya untuk mengambil keputusan tentang visibilitas fitur. Dalam kasus paling sederhana, mengubah nilai toggle memerlukan restart aplikasi, tetapi dalam sistem produksi, toggles biasanya mendukung muat ulang panas (hot reload) melalui server konfigurasi eksternal atau API.

Contoh toggle sederhana

Mari kita lihat implementasi feature toggle di JavaScript (Node.js). Sakelar disimpan dalam konfigurasi JSON dan dimuat saat server mulai. Middleware memeriksa nilai toggle sebelum mengarahkan permintaan ke handler baru atau lama. Implementasi semacam itu memungkinkan penambahan fungsionalitas baru ke cabang utama kode tanpa mengganggu kerja versi API saat ini.

const config = require("./config.json");

const toggles = {
    get(name) {
        return config.features[name] ?? false;
    },
    isEnabled(name, context) {
        const toggle = config.features[name];
        if (!toggle) return false;
        if (toggle.enabled === true) return true;
        if (toggle.percentage && context.userId) {
            return hashCode(context.userId) % 100 < toggle.percentage;
        }
        return false;
    }
};

const app = express();

app.use("/api/checkout", (req, res, next) => {
    if (toggles.isEnabled("new_checkout", req)) {
        return newCheckoutHandler(req, res);
    }
    return legacyCheckoutHandler(req, res);
});

Jenis feature toggles

Pete Hodgson dari ThoughtWorks mengidentifikasi tiga jenis utama feature toggles, mengklasifikasikannya berdasarkan masa pakai dan tujuan penggunaan. Penentuan jenis toggle yang tepat membantu memilih mekanisme penyimpanan dan proses manajemen yang sesuai. Mari kita lihat setiap jenis dalam konteks pengembangan mobile.

Business dan Release toggles

Business toggles — sakelar yang paling panjang umur. Mereka mengelola aturan bisnis yang hanya tersedia untuk kategori pengguna tertentu (fitur premium, karakteristik regional). Toggles semacam itu dapat bertahan selama bertahun-tahun dan biasanya memiliki logika yang lebih kompleks daripada sekadar aktif/nonaktif biner. Release toggles — sakelar sementara untuk menyembunyikan fungsionalitas yang belum selesai. Siklus hidup mereka berkisar dari beberapa hari hingga beberapa minggu. Setelah fungsionalitas selesai, release toggle dihapus dari kode. Toggles ini adalah dasar dari trunk-based development, memungkinkan pengembang untuk melakukan commit ke cabang utama tanpa menunggu seluruh fungsionalitas selesai.

Experiment dan Infrastructure toggles

Experiment toggles digunakan untuk pengujian A/B dan peluncuran bertahap. Tidak seperti release toggles, experiment toggles mendukung distribusi persentase pengguna dan integrasi dengan sistem analitik. Mereka dapat bertahan lebih lama dari release toggles (hingga beberapa bulan), tetapi juga harus dihapus setelah eksperimen selesai. Infrastructure toggles — sakelar untuk mengelola perubahan infrastruktur: migrasi basis data, peralihan ke penyedia API baru, perubahan algoritma cache. Toggles ini memerlukan perhatian khusus dalam pengujian karena peralihannya memengaruhi stabilitas seluruh layanan.

Jenis toggle	Durasi	Audien	Contoh
Business	Bulan-tahun	Berdasarkan peran/wilayah	Fitur premium
Release	Hari-minggu	Pengembang/QA	Layar belum selesai
Experiment	Minggu-bulan	% pengguna	Uji A/B antarmuka
Infrastructure	Hari-minggu	Internal	Migrasi DB

Feature Toggle vs Feature Flag

Meskipun istilah „feature toggle” dan „feature flag” sering digunakan secara bergantian, ada perbedaan konseptual di antara keduanya. Memahami perbedaan ini membantu memilih alat yang tepat untuk tugas tertentu dan menghindari kebingungan dalam tim. Mari kita lihat perbedaan utama dan area penerapan masing-masing pendekatan.

Perbedaan dalam pendekatan

Feature toggle — pertama-tama adalah mekanisme teknis: sakelar biner yang tertanam dalam kode aplikasi. Toggle dikelola melalui konfigurasi dan tidak memerlukan infrastruktur eksternal. Feature flag — adalah konsep yang lebih luas yang mencakup platform manajemen: UI untuk konfigurasi, SDK untuk integrasi, pemantauan penggunaan, analitik, dan audit. Flag mendukung aturan penargetan yang kompleks (berdasarkan wilayah, versi, perangkat), eksperimen A/B, dan penghapusan otomatis. Dapat dikatakan bahwa feature flag adalah evolusi dari feature toggle: tim mulai dengan sakelar konfigurasi sederhana, dan seiring pertumbuhan, beralih ke platform khusus.

Kapan toggle cukup

Untuk tim kecil dan proyek dengan satu layanan atau monolit, toggles konfigurasi sederhana sudah cukup. Jika Anda memiliki 5–10 pengembang dan 1–2 toggles aktif secara bersamaan — platform eksternal akan berlebihan. Platform feature flag (LaunchDarkly, Unleash) menjadi diperlukan ketika jumlah flag aktif melebihi 20–30, tim memiliki 20+ pengembang, atau diperlukan manajemen akses yang tepat ke fitur untuk segmen pengguna yang berbeda. Untuk aplikasi mobile, di mana pembaruan klien memakan waktu berhari-hari, platform feature flag memberikan keuntungan tambahan — kemampuan untuk mengubah perilaku aplikasi tanpa menerbitkan versi baru.

Alat manajemen

Pemilihan alat untuk mengelola feature toggles tergantung pada ukuran tim, tumpukan teknologi, dan persyaratan keamanan. Mari kita lihat opsi dari file konfigurasi sederhana hingga platform manajemen industri, termasuk alternatif open-source.

Integrasi ke dalam CI/CD

Feature toggles harus menjadi warga kelas satu dari pipeline CI/CD. Pada tahap build, pipeline memeriksa apakah semua release toggles yang direncanakan untuk dihapus dalam sprint saat ini benar-benar telah dihapus dari kode. Pada tahap pengujian, tes matriks dengan berbagai kombinasi toggles dijalankan. Pada tahap deploy, sistem secara otomatis menyinkronkan konfigurasi toggles dengan lingkungan produksi. Integrasi dengan PagerDuty atau Opsgenie memungkinkan pembuatan peringatan saat mendeteksi stale toggles atau saat melampaui jumlah toggles aktif yang diizinkan.

Solusi populer

Untuk skenario sederhana, konfigurasi JSON di Git dengan code review pada perubahan sudah cukup. Opsi yang lebih canggih — Togglz (Java) atau Gofeature (Go) — pustaka yang menambahkan UI minimal untuk mengelola toggles. Untuk sistem produksi, direkomendasikan Unleash (open-source) dengan SDK untuk semua bahasa dan dukungan strategi aktivasi, atau Flagsmith dengan pengujian A/B bawaan. LaunchDarkly tetap menjadi standar untuk proyek enterprise dengan persyaratan audit dan kepatuhan yang tinggi. Untuk aplikasi mobile, semua solusi menyediakan SDK native dengan caching dan mode offline.

Utang teknis dan penghapusan

Feature toggles adalah pedang bermata dua. Tanpa disiplin manajemen, mereka berubah menjadi utang teknis yang memperlambat pengembangan dan meningkatkan kompleksitas kode. Menurut penelitian CodeScene (2024), 35–50% basis kode mengandung stale toggles — sakelar yang tetap berada dalam kode setelah peluncuran selesai. Mari kita lihat strategi pencegahan dan penghapusan utang semacam itu.

Penghapusan toggles

Proses penghapusan feature toggle terdiri dari empat langkah. Pertama: pastikan toggle diaktifkan untuk 100% audiens atau dinonaktifkan untuk 0% (tergantung pada cabang kode mana yang harus dipertahankan). Kedua: hapus semua pemeriksaan bersyarat toggle dari kode, hanya menyisakan cabang yang harus menjadi perilaku produksi. Ketiga: hapus definisi toggle dari sistem penyimpanan (konfigurasi, DB, atau platform). Keempat: jalankan tes untuk mengonfirmasi bahwa penghapusan tidak merusak fungsionalitas. Setiap toggle harus memiliki pemilik dan tanggal penghapusan yang direncanakan, ditetapkan saat pembuatan sakelar.

Otomatisasi audit

Audit manual toggles tidak efisien pada skala lebih dari 50 sakelar. Otomatisasi didasarkan pada tiga prinsip: pemeriksaan CI (keberadaan stale toggles memblokir merge), pemantauan (dasbor dengan usia setiap toggle dan statusnya), peringatan (pemberitahuan kepada pemilik jika toggle tidak berubah selama N hari). Alat analisis kode statis (SonarQube, plugin ESLint) dapat mendeteksi toggles yang selalu aktif atau selalu nonaktif dalam kode — tanda jelas dari stale toggle. Pemeriksaan terakhir — code review, di mana pengulas harus memastikan bahwa toggle baru benar-benar diperlukan dan cabang kode lama akan dihapus.

package toggles

type Toggle struct {
    Name      string
    Enabled   bool
    Owner     string
    CreatedAt time.Time
    TTL       time.Duration
}

type ToggleManager struct {
    store map[string]*Toggle
}

func NewToggleManager() *ToggleManager {
    return &ToggleManager{store: make(map[string]*Toggle)}
}

func (m *ToggleManager) IsEnabled(name string) bool {
    t, ok := m.store[name]
    if !ok {
        return false
    }
    return t.Enabled
}

func (m *ToggleManager) GetStaleToggles() []string {
    var stale []string
    for name, t := range m.store {
        if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
            stale = append(stale, name)
        }
    }
    return stale
}

Pertanyaan yang Sering Diajukan

Apa perbedaan feature toggle dengan feature flag?

Istilah sering digunakan secara bergantian, tetapi secara teknis feature toggle adalah sakelar biner dalam kode (kondisi if yang memeriksa konfigurasi). Feature flag adalah konsep yang lebih luas yang mencakup platform manajemen dengan UI, SDK, analitik, dan aturan penargetan yang kompleks. Toggle tidak memerlukan infrastruktur eksternal, flag — biasanya ya.

Seberapa sering toggles lama harus dihapus?

Release toggles harus dihapus dalam 1–2 minggu setelah peluncuran selesai. Experiment toggles — segera setelah pengujian A/B selesai. Business toggles memerlukan audit rutin (setiap kuartal). Disarankan untuk menyiapkan pemeriksaan CI yang memblokir merge jika PR menambahkan toggle baru tanpa tugas penghapusan di task tracker.

Bisakah toggles digunakan untuk aplikasi mobile?

Ya, feature toggles aktif digunakan dalam pengembangan mobile. Alat utama — Firebase Remote Config, yang memungkinkan pengelolaan sakelar secara dinamis tanpa menerbitkan versi baru aplikasi. Alternatif: LaunchDarkly SDK untuk iOS/Android, Unleash SDK, server toggle sendiri dengan REST API. Penting untuk mengimplementasikan caching nilai untuk bekerja dalam mode offline.

Bagaimana cara menguji kode dengan feature toggles?

Metode utama — pengujian matriks: menjalankan semua tes dengan toggle aktif dan nonaktif. Untuk N toggles, pengujian matriks penuh memerlukan 2^n kali proses, sehingga dalam praktiknya kombinasi kritis dipilih. Tes unit harus melakukan mock pada nilai toggle. Tes integrasi memeriksa skenario spesifik. Dalam CI, ditambahkan langkah yang menjalankan tes dengan kombinasi toggles acak untuk mendeteksi interaksi yang tidak terduga.

Apa risiko dari feature toggles?

Risiko utama: 1) stale toggles — kode dengan kedua cabang (aktif/nonaktif) menjadi kompleks dan sulit dipelihara; 2) kompleksitas kombinatorial pengujian — setiap toggle menggandakan jumlah status; 3) dead code — cabang lama tetap dalam kode setelah toggle diaktifkan secara permanen; 4) keamanan — sakelar yang mengontrol akses menciptakan kerentanan pada konfigurasi yang salah. Semua risiko dapat dikelola dengan disiplin dan otomatisasi.

Kesimpulan

Feature Toggle — sakelar biner fungsionalitas yang dikelola melalui konfigurasi aplikasi
Jenis utama: business (bulan-tahun), release (hari-minggu), experiment (minggu-bulan), infrastructure (hari-minggu)
Feature Toggle vs Flag — toggle lebih sederhana (if + konfigurasi), flag mencakup platform manajemen lengkap
Integrasi CI/CD wajib: pemeriksaan stale toggles, tes matriks, sinkronisasi konfigurasi
Stale toggles — risiko utama: 35–50% basis kode mengandung sakelar yang tidak digunakan
Penghapusan toggle memerlukan proses: konfirmasi status, hapus kode, hapus konfigurasi, jalankan tes
Otomatisasi audit melalui CI, dasbor, dan analisis kode statis mencegah akumulasi utang teknis

Kami akan mengembangkan aplikasi seluler turnkey

IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.

Diskusikan proyek