Feature flag: lepaskan tanpa menahan nafas

spinny:~/writing $ vim openfeature-feature-flags-progressive-delivery.md

1~
2Deployment adalah saat kode tiba dalam produksi. Rilis adalah saat seseorang benar-benar dapat menggunakannya. Membingungkan keduanya adalah salah satu cara tercepat untuk membuat setiap penerapan menjadi momen yang menegangkan.
3~
4Tanda feature flag berfungsi untuk memberi jarak di antara dua momen ini. Anda dapat menerapkan hari ini, menjalankannya besok untuk tim internal, lalu untuk pelanggan percontohan, lalu untuk 10% pengguna. Jika terjadi kesalahan, matikan benderanya. Anda tidak perlu melakukan rollback seluruh rilis.
5~
6## Bendera bukan sekedar if
7~
8Secara teknis seringkali berupa `if`. Secara budaya, hal ini lebih dari itu.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18`if` kecil tersebut dapat mewakili peluncuran bertahap, percobaan, migrasi, izin usaha, atau kill switch operasional. Masalahnya, jika tidak dikelola dengan baik, bisa juga menjadi utang teknis yang bertahan dalam kode selama dua tahun.
19~
20## Di mana OpenFeature masuk
21~
22OpenFeature adalah spesifikasi terbuka untuk mengevaluasi feature flag dengan API yang umum. Idenya sederhana: kode aplikasi Anda tidak boleh bergantung langsung pada vendor atau sistem internal yang Anda gunakan untuk flag.
23~
24Aplikasi ini bertanya:
25~
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33~
34Penyedia memutuskan dari mana aturan itu berasal: SaaS, file, layanan internal, flagd, konfigurasi GitOps. Jika suatu saat Anda mengubah fitur penandaan backend, aplikasi tidak perlu ditulis ulang di mana pun.
35~
36Pemisahan ini tampak seperti detail arsitektural, namun terasa seiring berkembangnya proyek.
37~
38## Konteks adalah setengah dari perjuangan
39~
40Bendera aktif atau nonaktif untuk semua orang berguna, namun terbatas. Pengiriman progresif hidup dalam konteks:
41~
42- pengguna internal atau eksternal;
43- paket gratis atau perusahaan;
44- desa;
45- organisasi;
46- versi aplikasi;
47- persentase lalu lintas yang stabil.
48~
49Kunci pentingnya adalah `targetingKey`: harus stabil. Jika berubah pada setiap permintaan, pengguna dapat berakhir satu kali di varian A dan satu kali di varian B. Untuk eksperimen, ini buruk, untuk pembayaran, ini bisa menjadi bencana.
50~
51## Peluncuran yang masuk akal
52~
53Aliran yang saya suka adalah ini:
54~
551. menyebarkan dengan menandai;
562. pengapian untuk pengembang dan QA;
573. aktifkan untuk pelanggan atau penyewa percontohan;
584. 5% peluncuran;
595. peluncuran sebesar 25%;
606. peluncuran 100%;
617. penghapusan kode dan flag lama.
62~
63Poin yang sering terlupakan adalah poin terakhir. Bendera sementara harus memiliki tanggal kematian. Jika tetap selamanya, setiap refactor di masa depan harus bertanya: "tetapi apakah cabang ini masih berguna?".
64~
65## Kill switch: persiapkan terlebih dahulu
66~
67kill switch adalah tanda yang menyelamatkan Anda ketika ketergantungan eksternal mulai mengganggu Anda, pekerjaan menghabiskan terlalu banyak sumber daya, atau logika baru menghasilkan kesalahan aneh.
68~
69kill switch yang baik haruslah:
70~
71- mudah ditemukan;
72- didokumentasikan dalam runbook;
73- diuji sesekali;
74- dapat diamati saat diaktifkan;
75- independen, sejauh mungkin, dari bagian yang dapat pecah.
76~
77Hal terburuknya adalah ketika kecelakaan itu diketahui bahwa bendera itu ada, tetapi tidak ada yang tahu apakah bendera itu masih berfungsi.
78~
79## Observabilitas atau tidak pengiriman progresif
80~
81Mengaktifkan fitur pada 10% tanpa melihat metrik hanyalah optimisme dengan beberapa langkah.
82~
83Setiap peluncuran harus menjawab pertanyaan sederhana:
84~
85- apakah kesalahan meningkat?
86- apakah latensinya berubah?
87- apakah pengguna menyelesaikan alurnya?
88- apakah ada tiket lagi atau percobaan ulang?
89- apakah suatu varian hanya berdampak pada satu segmen?
90~
91OpenFeature mendukung kaitan seputar evaluasi bendera. Mereka berguna untuk mencatat kesalahan, menambahkan metrik, atau menghubungkan peringkat ke trace.
92~
93## Penamaan dan kepemilikan
94~
95Nama penting. `new_ui` tidak mengatakan apa-apa. `checkout.v2.enabled` mengatakan lebih banyak lagi.
96~
97Untuk setiap bendera saya akan menandai setidaknya:
98~
99- nama;
100- keterangan;
101- pemilik;
102- bawaan yang aman;
103- alasan mengapa hal itu ada;
104- tanggal atau kondisi penghapusan.
105~
106Bendera tanpa pemilik hampir selalu merupakan bendera yang tidak akan dihapuskan oleh siapa pun.
107~
108## Tempat untuk mengevaluasinya
109~
110Frontend, backend, atau tepi? Bergantung.
111~
112Jika tandanya untuk tata letak, penyalinan, atau orientasi, frontendnya baik-baik saja. Jika menyangkut perizinan, penagihan, batasan atau data sensitif, itu harus ada di backend. Jika ini melibatkan perutean atau eksperimen dengan lalu lintas tinggi, keunggulan ini mungkin masuk akal.
113~
114Aturan sederhananya: frontend dapat meningkatkan pengalaman, namun tidak boleh menjadi satu-satunya penghalang keamanan.
115~
116## Kesimpulan
117~
118feature flag yang dilakukan dengan baik mengubah hubungan dengan produksi. Tindakan ini tidak menghilangkan risiko, namun membuatnya lebih kecil dan lebih mudah dikelola. Anda dapat melepaskannya sedikit demi sedikit, mengamati, berhenti, kembali, belajar.
119~
120OpenFeature menambahkan fondasi yang bersih: API yang umum, penyedia yang dapat dipertukarkan, dan cara yang lebih rapi untuk mengembangkan sistem. Namun disiplin tetap menjadi milik Anda: default yang aman, nama yang jelas, metrik, pemilik, dan kebersihan.
121~
122Bendera terbaik adalah yang membantu Anda melepaskannya dengan tenang dan kemudian menghilang saat tidak diperlukan lagi.
123~
124## Sumber
125~
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131~

NORMAL · openfeature-feature-flags-progressive-delivery.md [readonly]131 lines · :q to close

2Deployment adalah saat kode tiba dalam produksi. Rilis adalah saat seseorang benar-benar dapat menggunakannya. Membingungkan keduanya adalah salah satu cara tercepat untuk membuat setiap penerapan menjadi momen yang menegangkan.

4Tanda feature flag berfungsi untuk memberi jarak di antara dua momen ini. Anda dapat menerapkan hari ini, menjalankannya besok untuk tim internal, lalu untuk pelanggan percontohan, lalu untuk 10% pengguna. Jika terjadi kesalahan, matikan benderanya. Anda tidak perlu melakukan rollback seluruh rilis.

6## Bendera bukan sekedar if

8Secara teknis seringkali berupa `if`. Secara budaya, hal ini lebih dari itu.

10```typescript

11if (await flags.isEnabled('checkout.v2.enabled', context)) {

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18`if` kecil tersebut dapat mewakili peluncuran bertahap, percobaan, migrasi, izin usaha, atau kill switch operasional. Masalahnya, jika tidak dikelola dengan baik, bisa juga menjadi utang teknis yang bertahan dalam kode selama dua tahun.

19~

20## Di mana OpenFeature masuk

21~

22OpenFeature adalah spesifikasi terbuka untuk mengevaluasi feature flag dengan API yang umum. Idenya sederhana: kode aplikasi Anda tidak boleh bergantung langsung pada vendor atau sistem internal yang Anda gunakan untuk flag.

23~

24Aplikasi ini bertanya:

25~

26```typescript

27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {

28 targetingKey: user.id,

29 plan: user.plan,

30 country: user.country,

31});

32```

33~

34Penyedia memutuskan dari mana aturan itu berasal: SaaS, file, layanan internal, flagd, konfigurasi GitOps. Jika suatu saat Anda mengubah fitur penandaan backend, aplikasi tidak perlu ditulis ulang di mana pun.

35~

36Pemisahan ini tampak seperti detail arsitektural, namun terasa seiring berkembangnya proyek.

37~

38## Konteks adalah setengah dari perjuangan

39~

40Bendera aktif atau nonaktif untuk semua orang berguna, namun terbatas. Pengiriman progresif hidup dalam konteks:

41~

42- pengguna internal atau eksternal;

43- paket gratis atau perusahaan;

44- desa;

45- organisasi;

46- versi aplikasi;

47- persentase lalu lintas yang stabil.

48~

49Kunci pentingnya adalah `targetingKey`: harus stabil. Jika berubah pada setiap permintaan, pengguna dapat berakhir satu kali di varian A dan satu kali di varian B. Untuk eksperimen, ini buruk, untuk pembayaran, ini bisa menjadi bencana.

50~

51## Peluncuran yang masuk akal

52~

53Aliran yang saya suka adalah ini:

54~

551. menyebarkan dengan menandai;

562. pengapian untuk pengembang dan QA;

573. aktifkan untuk pelanggan atau penyewa percontohan;

584. 5% peluncuran;

595. peluncuran sebesar 25%;

606. peluncuran 100%;

617. penghapusan kode dan flag lama.

62~

63Poin yang sering terlupakan adalah poin terakhir. Bendera sementara harus memiliki tanggal kematian. Jika tetap selamanya, setiap refactor di masa depan harus bertanya: "tetapi apakah cabang ini masih berguna?".

64~

65## Kill switch: persiapkan terlebih dahulu

66~

67kill switch adalah tanda yang menyelamatkan Anda ketika ketergantungan eksternal mulai mengganggu Anda, pekerjaan menghabiskan terlalu banyak sumber daya, atau logika baru menghasilkan kesalahan aneh.

68~

69kill switch yang baik haruslah:

70~

71- mudah ditemukan;

72- didokumentasikan dalam runbook;

73- diuji sesekali;

74- dapat diamati saat diaktifkan;

75- independen, sejauh mungkin, dari bagian yang dapat pecah.

76~

77Hal terburuknya adalah ketika kecelakaan itu diketahui bahwa bendera itu ada, tetapi tidak ada yang tahu apakah bendera itu masih berfungsi.

78~

79## Observabilitas atau tidak pengiriman progresif

80~

81Mengaktifkan fitur pada 10% tanpa melihat metrik hanyalah optimisme dengan beberapa langkah.

82~

83Setiap peluncuran harus menjawab pertanyaan sederhana:

84~

85- apakah kesalahan meningkat?

86- apakah latensinya berubah?

87- apakah pengguna menyelesaikan alurnya?

88- apakah ada tiket lagi atau percobaan ulang?

89- apakah suatu varian hanya berdampak pada satu segmen?

90~

91OpenFeature mendukung kaitan seputar evaluasi bendera. Mereka berguna untuk mencatat kesalahan, menambahkan metrik, atau menghubungkan peringkat ke trace.

92~

93## Penamaan dan kepemilikan

94~

95Nama penting. `new_ui` tidak mengatakan apa-apa. `checkout.v2.enabled` mengatakan lebih banyak lagi.

96~

97Untuk setiap bendera saya akan menandai setidaknya:

98~

99- nama;

100- keterangan;

101- pemilik;

102- bawaan yang aman;

103- alasan mengapa hal itu ada;

104- tanggal atau kondisi penghapusan.

105~

106Bendera tanpa pemilik hampir selalu merupakan bendera yang tidak akan dihapuskan oleh siapa pun.

107~

108## Tempat untuk mengevaluasinya

109~

110Frontend, backend, atau tepi? Bergantung.

111~

112Jika tandanya untuk tata letak, penyalinan, atau orientasi, frontendnya baik-baik saja. Jika menyangkut perizinan, penagihan, batasan atau data sensitif, itu harus ada di backend. Jika ini melibatkan perutean atau eksperimen dengan lalu lintas tinggi, keunggulan ini mungkin masuk akal.

113~

114Aturan sederhananya: frontend dapat meningkatkan pengalaman, namun tidak boleh menjadi satu-satunya penghalang keamanan.

115~

116## Kesimpulan

117~

118feature flag yang dilakukan dengan baik mengubah hubungan dengan produksi. Tindakan ini tidak menghilangkan risiko, namun membuatnya lebih kecil dan lebih mudah dikelola. Anda dapat melepaskannya sedikit demi sedikit, mengamati, berhenti, kembali, belajar.

119~

120OpenFeature menambahkan fondasi yang bersih: API yang umum, penyedia yang dapat dipertukarkan, dan cara yang lebih rapi untuk mengembangkan sistem. Namun disiplin tetap menjadi milik Anda: default yang aman, nama yang jelas, metrik, pemilik, dan kebersihan.

121~

122Bendera terbaik adalah yang membantu Anda melepaskannya dengan tenang dan kemudian menghilang saat tidak diperlukan lagi.

123~

124## Sumber

125~

126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)

127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)

128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)

129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)

130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)

131~