Feature flag: απελευθερώστε χωρίς να κρατάτε την αναπνοή σας

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

1~
2Η ανάπτυξη είναι όταν ο κώδικας φτάνει στην παραγωγή. Η κυκλοφορία είναι όταν κάποιος μπορεί πραγματικά να το χρησιμοποιήσει. Η σύγχυση των δύο είναι ένας από τους πιο γρήγορους τρόπους για να κάνετε κάθε ανάπτυξη λίγο τεταμένη στιγμή.
3~
4Τα feature flag χρησιμεύουν για να βάλουν χώρο ανάμεσα σε αυτές τις δύο στιγμές. Μπορείτε να αναπτύξετε σήμερα, να ενεργοποιήσετε αύριο για την εσωτερική ομάδα, μετά για έναν πιλοτικό πελάτη και μετά για το 10% των χρηστών. Εάν κάτι πάει στραβά, απενεργοποιήστε τη σημαία. Δεν χρειάζεται απαραίτητα να επαναφέρετε ολόκληρη την κυκλοφορία.
5~
6## Η σημαία δεν είναι απλώς ένα αν
7~
8Τεχνικά είναι συχνά ένα `if`. Πολιτιστικά είναι πολύ περισσότερα.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18Αυτό το μικρό `if` μπορεί να αντιπροσωπεύει μια σταδιακή διάθεση, ένα πείραμα, μια μετεγκατάσταση, μια άδεια επιχείρησης ή ένα λειτουργικό kill switch. Το πρόβλημα είναι ότι αν δεν το διαχειριστείς καλά, μπορεί να γίνει και τεχνικό χρέος που μένει στον κωδικό για δύο χρόνια.
19~
20## Πού μπαίνει το OpenFeature
21~
22Το OpenFeature είναι μια ανοιχτή προδιαγραφή για την αξιολόγηση του feature flag με ένα κοινό API. Η ιδέα είναι απλή: ο κωδικός της εφαρμογής σας δεν πρέπει να εξαρτάται άμεσα από τον προμηθευτή ή το εσωτερικό σύστημα που χρησιμοποιείτε για σημαίες.
23~
24Η εφαρμογή ρωτά:
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~
34Ο πάροχος αποφασίζει από πού προέρχονται οι κανόνες: SaaS, αρχείο, εσωτερική υπηρεσία, σημαία, διαμόρφωση GitOps. Εάν κάποια μέρα αλλάξετε το backend επισήμανσης χαρακτηριστικών, η εφαρμογή δεν χρειάζεται να ξαναγραφτεί παντού.
35~
36Αυτός ο διαχωρισμός φαίνεται σαν μια αρχιτεκτονική λεπτομέρεια, αλλά γίνεται αισθητός καθώς το έργο μεγαλώνει.
37~
38## Το πλαίσιο είναι η μισή μάχη
39~
40Μια σημαία ενεργοποίησης ή απενεργοποίησης για όλους είναι χρήσιμη, αλλά περιορισμένη. Η προοδευτική παράδοση ζει στο πλαίσιο:
41~
42- εσωτερικός ή εξωτερικός χρήστης.
43- δωρεάν ή επιχειρηματικό σχέδιο
44- χωριό
45- οργάνωση·
46- έκδοση εφαρμογής.
47- σταθερό ποσοστό κίνησης.
48~
49Το σημαντικό κλειδί είναι `targetingKey`: πρέπει να είναι σταθερό. Αν αλλάζει με κάθε αίτημα, ένας χρήστης μπορεί να καταλήξει μία φορά στην παραλλαγή Α και μία στην παραλλαγή Β. Για ένα πείραμα είναι τρομερό, για ένα ταμείο μπορεί να είναι καταστροφικό.
50~
51## Μια λογική διάθεση
52~
53Μια ροή που μου αρέσει είναι η εξής:
54~
551. Αναπτύξτε με σημαία σβηστή.
562. ανάφλεξη για προγραμματιστές και QA.
573. Ενεργοποίηση για πιλότο πελάτη ή ενοικιαστή.
584. 5% διάθεση.
595. διάθεση στο 25%.
606. 100% διάθεση.
617. αφαίρεση παλιού κωδικού και σημαίας.
62~
63Το συχνά ξεχασμένο σημείο είναι το τελευταίο. Μια προσωρινή σημαία πρέπει να έχει ημερομηνία θανάτου. Αν μείνει για πάντα, κάθε μελλοντικός ανασχηματιστής θα πρέπει να ρωτήσει: «μα είναι ακόμα χρήσιμο αυτός ο κλάδος;».
64~
65## Kill switch: ετοιμάστε τα πρώτα
66~
67Το kill switch είναι η σημαία που σας σώζει όταν μια εξωτερική εξάρτηση αρχίζει να σας ενοχλεί, μια εργασία καταναλώνει πάρα πολλούς πόρους ή η νέα λογική δημιουργεί περίεργα σφάλματα.
68~
69Ένα καλό kill switch πρέπει να είναι:
70~
71- εύκολο να βρεθεί?
72- τεκμηριωμένη στο runbook.
73- δοκιμάζεται περιστασιακά.
74- παρατηρήσιμο όταν ενεργοποιείται.
75- ανεξάρτητο, όσο το δυνατόν περισσότερο, από το τμήμα που θα μπορούσε να σπάσει.
76~
77Το χειρότερο είναι να ανακαλύψεις κατά τη διάρκεια του ατυχήματος ότι η σημαία υπάρχει, αλλά κανείς δεν ξέρει αν εξακολουθεί να λειτουργεί.
78~
79## Παρατηρησιμότητα ή όχι προοδευτική παράδοση
80~
81Η ενεργοποίηση μιας λειτουργίας στο 10% χωρίς να εξετάζετε μετρήσεις είναι απλώς αισιοδοξία με πολλά βήματα.
82~
83Κάθε κυκλοφορία θα πρέπει να απαντά σε απλές ερωτήσεις:
84~
85- έχουν αυξηθεί τα σφάλματα;
86- έχει αλλάξει η καθυστέρηση;
87- ολοκληρώνουν οι χρήστες τη ροή;
88- υπάρχουν περισσότερα εισιτήρια ή επαναλήψεις;
89- επηρεάζει μια παραλλαγή μόνο ένα τμήμα;
90~
91OpenFeature υποστηρίζει αγκίστρια γύρω από την αξιολόγηση σημαίας. Είναι χρήσιμα για την καταγραφή σφαλμάτων, την προσθήκη μετρήσεων ή τη σύνδεση της βαθμολογίας με ένα trace.
92~
93## Ονομασία και ιδιοκτησία
94~
95Τα ονόματα έχουν σημασία. `new_ui` δεν λέει τίποτα. Το `checkout.v2.enabled` λέει πολλά περισσότερα.
96~
97Για κάθε σημαία θα σημείωνα τουλάχιστον:
98~
99- όνομα
100- περιγραφή
101- ιδιοκτήτης
102- ασφαλής προεπιλογή
103- ο λόγος για τον οποίο υπάρχει.
104- ημερομηνία ή προϋπόθεση απομάκρυνσης.
105~
106Μια σημαία χωρίς ιδιοκτήτη είναι σχεδόν πάντα μια σημαία που κανείς δεν θα καθαρίσει.
107~
108## Πού να τα αξιολογήσετε
109~
110Frontend, backend ή edge; Εξαρτάται.
111~
112Εάν η σημαία είναι για διάταξη, αντιγραφή ή ενσωμάτωση, η διεπαφή είναι εντάξει. Εάν αφορά δικαιώματα, χρέωση, όρια ή ευαίσθητα δεδομένα, πρέπει να βρίσκεται στο backend. Εάν περιλαμβάνει πειράματα δρομολόγησης ή υψηλής επισκεψιμότητας, η άκρη μπορεί να έχει νόημα.
113~
114Ο απλός κανόνας: το frontend μπορεί να βελτιώσει την εμπειρία, αλλά δεν πρέπει να είναι το μόνο εμπόδιο ασφαλείας.
115~
116## Συμπέρασμα
117~
118Το feature flag που έγινε καλά αλλάζει τη σχέση με την παραγωγή. Δεν εξαλείφουν τον κίνδυνο, αλλά τον κάνουν μικρότερο και πιο διαχειρίσιμο. Μπορείτε να απελευθερώσετε σε φέτες, να παρατηρήσετε, να σταματήσετε, να επιστρέψετε, να μάθετε.
119~
120Το OpenFeature προσθέτει μια καθαρή βάση: ένα κοινό API, εναλλάξιμους παρόχους και έναν πιο τακτοποιημένο τρόπο ανάπτυξης του συστήματος. Αλλά η πειθαρχία παραμένει δική σας: ασφαλείς προεπιλογές, ξεκάθαρα ονόματα, μετρήσεις, ιδιοκτήτες και καθαριότητα.
121~
122Η καλύτερη σημαία είναι αυτή που σε βοηθά να απελευθερωθείς ήρεμα και μετά εξαφανίζεται όταν δεν χρειάζεται πλέον.
123~
124## Πηγές
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

2Η ανάπτυξη είναι όταν ο κώδικας φτάνει στην παραγωγή. Η κυκλοφορία είναι όταν κάποιος μπορεί πραγματικά να το χρησιμοποιήσει. Η σύγχυση των δύο είναι ένας από τους πιο γρήγορους τρόπους για να κάνετε κάθε ανάπτυξη λίγο τεταμένη στιγμή.

4Τα feature flag χρησιμεύουν για να βάλουν χώρο ανάμεσα σε αυτές τις δύο στιγμές. Μπορείτε να αναπτύξετε σήμερα, να ενεργοποιήσετε αύριο για την εσωτερική ομάδα, μετά για έναν πιλοτικό πελάτη και μετά για το 10% των χρηστών. Εάν κάτι πάει στραβά, απενεργοποιήστε τη σημαία. Δεν χρειάζεται απαραίτητα να επαναφέρετε ολόκληρη την κυκλοφορία.

6## Η σημαία δεν είναι απλώς ένα αν

8Τεχνικά είναι συχνά ένα `if`. Πολιτιστικά είναι πολύ περισσότερα.

10```typescript

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

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18Αυτό το μικρό `if` μπορεί να αντιπροσωπεύει μια σταδιακή διάθεση, ένα πείραμα, μια μετεγκατάσταση, μια άδεια επιχείρησης ή ένα λειτουργικό kill switch. Το πρόβλημα είναι ότι αν δεν το διαχειριστείς καλά, μπορεί να γίνει και τεχνικό χρέος που μένει στον κωδικό για δύο χρόνια.

19~

20## Πού μπαίνει το OpenFeature

21~

22Το OpenFeature είναι μια ανοιχτή προδιαγραφή για την αξιολόγηση του feature flag με ένα κοινό API. Η ιδέα είναι απλή: ο κωδικός της εφαρμογής σας δεν πρέπει να εξαρτάται άμεσα από τον προμηθευτή ή το εσωτερικό σύστημα που χρησιμοποιείτε για σημαίες.

23~

24Η εφαρμογή ρωτά:

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~

34Ο πάροχος αποφασίζει από πού προέρχονται οι κανόνες: SaaS, αρχείο, εσωτερική υπηρεσία, σημαία, διαμόρφωση GitOps. Εάν κάποια μέρα αλλάξετε το backend επισήμανσης χαρακτηριστικών, η εφαρμογή δεν χρειάζεται να ξαναγραφτεί παντού.

35~

36Αυτός ο διαχωρισμός φαίνεται σαν μια αρχιτεκτονική λεπτομέρεια, αλλά γίνεται αισθητός καθώς το έργο μεγαλώνει.

37~

38## Το πλαίσιο είναι η μισή μάχη

39~

40Μια σημαία ενεργοποίησης ή απενεργοποίησης για όλους είναι χρήσιμη, αλλά περιορισμένη. Η προοδευτική παράδοση ζει στο πλαίσιο:

41~

42- εσωτερικός ή εξωτερικός χρήστης.

43- δωρεάν ή επιχειρηματικό σχέδιο

44- χωριό

45- οργάνωση·

46- έκδοση εφαρμογής.

47- σταθερό ποσοστό κίνησης.

48~

49Το σημαντικό κλειδί είναι `targetingKey`: πρέπει να είναι σταθερό. Αν αλλάζει με κάθε αίτημα, ένας χρήστης μπορεί να καταλήξει μία φορά στην παραλλαγή Α και μία στην παραλλαγή Β. Για ένα πείραμα είναι τρομερό, για ένα ταμείο μπορεί να είναι καταστροφικό.

50~

51## Μια λογική διάθεση

52~

53Μια ροή που μου αρέσει είναι η εξής:

54~

551. Αναπτύξτε με σημαία σβηστή.

562. ανάφλεξη για προγραμματιστές και QA.

573. Ενεργοποίηση για πιλότο πελάτη ή ενοικιαστή.

584. 5% διάθεση.

595. διάθεση στο 25%.

606. 100% διάθεση.

617. αφαίρεση παλιού κωδικού και σημαίας.

62~

63Το συχνά ξεχασμένο σημείο είναι το τελευταίο. Μια προσωρινή σημαία πρέπει να έχει ημερομηνία θανάτου. Αν μείνει για πάντα, κάθε μελλοντικός ανασχηματιστής θα πρέπει να ρωτήσει: «μα είναι ακόμα χρήσιμο αυτός ο κλάδος;».

64~

65## Kill switch: ετοιμάστε τα πρώτα

66~

67Το kill switch είναι η σημαία που σας σώζει όταν μια εξωτερική εξάρτηση αρχίζει να σας ενοχλεί, μια εργασία καταναλώνει πάρα πολλούς πόρους ή η νέα λογική δημιουργεί περίεργα σφάλματα.

68~

69Ένα καλό kill switch πρέπει να είναι:

70~

71- εύκολο να βρεθεί?

72- τεκμηριωμένη στο runbook.

73- δοκιμάζεται περιστασιακά.

74- παρατηρήσιμο όταν ενεργοποιείται.

75- ανεξάρτητο, όσο το δυνατόν περισσότερο, από το τμήμα που θα μπορούσε να σπάσει.

76~

77Το χειρότερο είναι να ανακαλύψεις κατά τη διάρκεια του ατυχήματος ότι η σημαία υπάρχει, αλλά κανείς δεν ξέρει αν εξακολουθεί να λειτουργεί.

78~

79## Παρατηρησιμότητα ή όχι προοδευτική παράδοση

80~

81Η ενεργοποίηση μιας λειτουργίας στο 10% χωρίς να εξετάζετε μετρήσεις είναι απλώς αισιοδοξία με πολλά βήματα.

82~

83Κάθε κυκλοφορία θα πρέπει να απαντά σε απλές ερωτήσεις:

84~

85- έχουν αυξηθεί τα σφάλματα;

86- έχει αλλάξει η καθυστέρηση;

87- ολοκληρώνουν οι χρήστες τη ροή;

88- υπάρχουν περισσότερα εισιτήρια ή επαναλήψεις;

89- επηρεάζει μια παραλλαγή μόνο ένα τμήμα;

90~

91OpenFeature υποστηρίζει αγκίστρια γύρω από την αξιολόγηση σημαίας. Είναι χρήσιμα για την καταγραφή σφαλμάτων, την προσθήκη μετρήσεων ή τη σύνδεση της βαθμολογίας με ένα trace.

92~

93## Ονομασία και ιδιοκτησία

94~

95Τα ονόματα έχουν σημασία. `new_ui` δεν λέει τίποτα. Το `checkout.v2.enabled` λέει πολλά περισσότερα.

96~

97Για κάθε σημαία θα σημείωνα τουλάχιστον:

98~

99- όνομα

100- περιγραφή

101- ιδιοκτήτης

102- ασφαλής προεπιλογή

103- ο λόγος για τον οποίο υπάρχει.

104- ημερομηνία ή προϋπόθεση απομάκρυνσης.

105~

106Μια σημαία χωρίς ιδιοκτήτη είναι σχεδόν πάντα μια σημαία που κανείς δεν θα καθαρίσει.

107~

108## Πού να τα αξιολογήσετε

109~

110Frontend, backend ή edge; Εξαρτάται.

111~

112Εάν η σημαία είναι για διάταξη, αντιγραφή ή ενσωμάτωση, η διεπαφή είναι εντάξει. Εάν αφορά δικαιώματα, χρέωση, όρια ή ευαίσθητα δεδομένα, πρέπει να βρίσκεται στο backend. Εάν περιλαμβάνει πειράματα δρομολόγησης ή υψηλής επισκεψιμότητας, η άκρη μπορεί να έχει νόημα.

113~

114Ο απλός κανόνας: το frontend μπορεί να βελτιώσει την εμπειρία, αλλά δεν πρέπει να είναι το μόνο εμπόδιο ασφαλείας.

115~

116## Συμπέρασμα

117~

118Το feature flag που έγινε καλά αλλάζει τη σχέση με την παραγωγή. Δεν εξαλείφουν τον κίνδυνο, αλλά τον κάνουν μικρότερο και πιο διαχειρίσιμο. Μπορείτε να απελευθερώσετε σε φέτες, να παρατηρήσετε, να σταματήσετε, να επιστρέψετε, να μάθετε.

119~

120Το OpenFeature προσθέτει μια καθαρή βάση: ένα κοινό API, εναλλάξιμους παρόχους και έναν πιο τακτοποιημένο τρόπο ανάπτυξης του συστήματος. Αλλά η πειθαρχία παραμένει δική σας: ασφαλείς προεπιλογές, ξεκάθαρα ονόματα, μετρήσεις, ιδιοκτήτες και καθαριότητα.

121~

122Η καλύτερη σημαία είναι αυτή που σε βοηθά να απελευθερωθείς ήρεμα και μετά εξαφανίζεται όταν δεν χρειάζεται πλέον.

123~

124## Πηγές

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~