Σχεδιασμός συστήματος feature flags: κανόνες που δεν θα μετανιώσετε σε δεκαοκτώ μήνες

Βασικά συμπεράσματα

• Τα flags δεν είναι όλα ίδια. Η ταξινόμηση του Pete Hodgson διακρίνει release, experiment, ops και permission toggles, και κάθε κατηγορία χρειάζεται διαφορετική διάρκεια ζωής και διαφορετικό υπεύθυνο (martinfowler.com, 2017).
• Το χρέος από flags μετριέται. Στο Chrome, το 53% των release toggles βρισκόταν ακόμη στον κώδικα μετά από 10 εκδόσεις (Rahman et al., MSR 2016). Η Uber έφτιαξε εργαλείο που παρήγαγε diffs καθαρισμού για 1,381 παρωχημένα flags, το 17% του συνόλου των flags της (Ramanathan et al., ICSE-SEIP 2020).
• Αξιολογείτε τα server-side flags μέσα στη διεργασία, πάνω σε ένα ruleset στην cache. Έτσι λειτουργούν το LaunchDarkly, το Unleash και η τοπική λειτουργία του Flagsmith, και έτσι η υπηρεσία flags μένει εκτός της διαδρομής των αιτημάτων σας.
• Κάθε αξιολόγηση χρειάζεται ασφαλή προεπιλεγμένη τιμή για όταν η υπηρεσία flags δεν είναι προσβάσιμη. Η προδιαγραφή OpenFeature το κάνει αυστηρό κανόνα: η αξιολόγηση «πρέπει πάντα να επιστρέφει την προεπιλεγμένη τιμή σε περίπτωση μη ομαλής εκτέλεσης» (OpenFeature).
• Η καλύτερα τεκμηριωμένη αποτυχία flag προήλθε από την επαναχρησιμοποίηση ενός παλιού flag. Η Knight Capital έχασε πάνω από $460 εκατομμύρια σε περίπου 45 λεπτά (SEC, 2013).

Συνοπτικά

Ένα σύστημα feature flags που θα είναι ακόμη υγιές σε δεκαοκτώ μήνες κρίνεται από έξι αποφάσεις. Πρώτον, διαχωρίστε τους τύπους flags και δώστε στον καθένα διάρκεια ζωής. Δεύτερον, αξιολογείτε μέσα στη διεργασία, όχι μέσω δικτύου. Τρίτον, επιλέξτε συνειδητά προεπιλεγμένη τιμή για κάθε flag, ώστε μια διακοπή να μην αλλάζει αυτό που βλέπουν οι χρήστες. Τέταρτον, καταγράφετε κάθε αλλαγή, με το ποιος την έκανε και γιατί. Πέμπτον, μην επαναχρησιμοποιείτε ποτέ όνομα flag. Έκτον, κάντε τον καθαρισμό μέρος της παράδοσης ενός feature, όχι ξεχωριστό έργο. Για τις περισσότερες μικρές και μεσαίες ομάδες B2B, η αγορά μιας hosted υπηρεσίας (ή η λειτουργία μιας open-source λύσης πίσω από το OpenFeature SDK) είναι προτιμότερη από την ανάπτυξη δικής σας. Οι κανόνες όμως μετράνε περισσότερο από το εργαλείο, και θα τους χρειαστείτε σε κάθε περίπτωση.

Γιατί στραβώνουν τα συστήματα feature flags;

Αποτυγχάνουν αργά και μετά ξαφνικά. Ένα flag ξεκινά ως μια εντολή if μίας γραμμής που κάνει ένα ριψοκίνδυνο release αναστρέψιμο. Κανείς δεν την αφαιρεί. Έξι μήνες αργότερα υπάρχουν 200 τέτοια, κανείς δεν ξέρει ποια είναι ενεργά, και ο έλεγχος κάθε συνδυασμού καταστάσεων έχει πάψει προ πολλού να είναι εφικτός.

Ο κλασικός πλέον οδηγός του Pete Hodgson στο martinfowler.com περιγράφει το σωστό νοητικό μοντέλο: «Οι έμπειρες ομάδες βλέπουν τα Feature Toggles τους ως απόθεμα που έχει κόστος διατήρησης και φροντίζουν να το κρατούν όσο το δυνατόν χαμηλότερα» (martinfowler.com, 2017). Κάθε ενεργό flag διπλασιάζει τις διαδρομές εκτέλεσης σε ένα κομμάτι κώδικα. Προσθέτει επίσης μια τιμή ρύθμισης που μπορεί κάποιος να αλλάξει χωρίς deploy, και μια ερώτηση που κάθε νέος μηχανικός θα πρέπει να κάνει.

Τα δεδομένα το επιβεβαιώνουν. Μια μελέτη του κώδικα του Google Chrome σε 39 εκδόσεις, από το 2010 έως το 2015, διαπίστωσε ότι «τα μισά toggles επιβίωναν για 12 ή περισσότερες εκδόσεις». Ακόμη και τα release toggles, ο τύπος που υποτίθεται ότι ζει λίγο, παρέμεναν: «το 53% υπάρχει ακόμη μετά από 10 εκδόσεις, γεγονός που δείχνει ότι πολλά μένουν ως τεχνικό χρέος» (Rahman et al., MSR 2016). Το Chrome βγάζει νέα έκδοση περίπου κάθε έξι εβδομάδες, άρα δέκα εκδόσεις ισοδυναμούν με περισσότερο από έναν χρόνο.

Οι μικρές ομάδες δεν γλιτώνουν. Απλώς έχουν λιγότερους ανθρώπους που θυμούνται γιατί υπάρχει ένα flag.

Βήμα 1: Αποφασίστε ποια είδη flags χρησιμοποιείτε

Ξεκινήστε ονομάζοντας τους τύπους flags σας, γιατί ο τύπος καθορίζει διάρκεια ζωής, υπεύθυνο και προεπιλογή. Οι τέσσερις κατηγορίες του Hodgson παραμένουν ο σαφέστερος διαχωρισμός (martinfowler.com, 2017):

Το λάθος είναι να αντιμετωπίζετε και τις τέσσερις κατηγορίες με τον ίδιο τρόπο. Ένα release toggle που υπάρχει ακόμη μετά από 90 ημέρες είναι χρέος. Ένα permission flag που υπάρχει εδώ και 90 ημέρες είναι απλώς ο τρόπος που λειτουργεί η τιμολόγησή σας, και μάλλον ανήκει στο μοντέλο δικαιωμάτων σας παρά σε εργαλείο flags.

Το Unleash ενσωματώνει αυτόν τον διαχωρισμό στο ίδιο το προϊόν. Οι προεπιλεγμένες αναμενόμενες διάρκειες ζωής του είναι 40 ημέρες για release και experiment flags, 7 ημέρες για operational flags (βραχύβιες τεχνικές αλλαγές, όπως migrations) και μόνιμη για kill switches και permission flags. Ο τύπος kill switch του Unleash είναι ό,τι πλησιέστερο σε αυτό που ο Hodgson ονομάζει ops toggles. Μετά από αυτό το διάστημα, «το Unleash επισημαίνει αυτόματα όλα τα flags ως πιθανώς παρωχημένα» (τεκμηρίωση Unleash). Όποιο εργαλείο κι αν χρησιμοποιείτε, υιοθετήστε την ιδέα: ο τύπος ενός flag πρέπει να ορίζει την ημερομηνία λήξης του τη στιγμή που δημιουργείται.

Βήμα 2: Επιλέξτε τοπική αξιολόγηση για ό,τι τρέχει στον server

Αξιολογείτε τα flags μέσα στη δική σας διεργασία, πάνω σε ένα ruleset αποθηκευμένο στη μνήμη. Μην καλείτε μια υπηρεσία flags μέσω δικτύου σε κάθε έλεγχο. Αυτή η μία επιλογή καθορίζει την καθυστέρηση, τη συμπεριφορά σας σε διακοπές και την προσέγγισή σας στην ιδιωτικότητα.

Οι μεγάλες πλατφόρμες συμφωνούν. Τα server-side SDKs του LaunchDarkly λαμβάνουν «ολόκληρο το ruleset που αντιστοιχεί σε ένα SDK key κατά την αρχικοποίηση» και στη συνέχεια αξιολογούν «με βάση το ruleset στην cache» μέσω «ενός αλγορίθμου αξιολόγησης flags μέσα στη διεργασία», ενώ οι ενημερώσεις αποστέλλονται μέσω μόνιμης σύνδεσης (τεκμηρίωση LaunchDarkly). Τα backend SDKs του Unleash «αποθηκεύουν όλα τα δεδομένα feature flags στη μνήμη και εφαρμόζουν τις στρατηγικές ενεργοποίησης τοπικά», και ως παρενέργεια «τα δεδομένα των χρηστών σας μένουν μέσα στην εφαρμογή σας και δεν κοινοποιούνται ποτέ στον server του Unleash» (τεκμηρίωση Unleash).

Το Flagsmith προσφέρει και τις δύο λειτουργίες, κάτι που κάνει το αντιστάθμισμα ξεκάθαρο. Στην απομακρυσμένη λειτουργία, το SDK κάνει ένα blocking αίτημα δικτύου κάθε φορά που ανακτάτε τα flags ενός περιβάλλοντος. Στην τοπική λειτουργία, το SDK ελέγχει για αλλαγές «κάθε 60 δευτερόλεπτα (από προεπιλογή)» (τεκμηρίωση Flagsmith).

Δείτε πώς συγκρίνονται τα δύο μοντέλα:

Οι browsers και οι εφαρμογές για κινητά αποτελούν την εξαίρεση. Δεν μπορείτε να στείλετε όλους τους κανόνες στόχευσης (μαζί με τα IDs άλλων πελατών) σε μια συσκευή χρήστη, γι' αυτό τα client-side SDKs «αναθέτουν την αξιολόγηση των flags στο LaunchDarkly για λογαριασμό ενός συγκεκριμένου evaluation context» (τεκμηρίωση LaunchDarkly). Αυτό είναι αποδεκτό. Απλώς να ξέρετε ποια σημεία του προϊόντος σας εξαρτώνται από το δίκτυο για να απαντήσουν σε έλεγχο flag.

Βήμα 3: Ορίστε τη συμπεριφορά των kill switches πριν τα χρειαστείτε

Κάθε flag χρειάζεται ρητή απάντηση σε ένα ερώτημα: τι κάνει αυτός ο κώδικας όταν το σύστημα flags δεν μπορεί να απαντήσει; Αποφασίστε το όταν δημιουργείτε το flag, όχι εν μέσω περιστατικού.

Η προδιαγραφή OpenFeature το μετατρέπει σε συμβόλαιο. Η απαίτηση 1.4.10 ορίζει ότι οι μέθοδοι αξιολόγησης «ΔΕΝ ΠΡΕΠΕΙ να πετούν exceptions ή να τερματίζουν με άλλον μη ομαλό τρόπο. Οι κλήσεις αξιολόγησης flags πρέπει πάντα να επιστρέφουν την default value σε περίπτωση μη ομαλής εκτέλεσης». Η προεπιλεγμένη τιμή είναι επίσης υποχρεωτικό όρισμα σε κάθε κλήση (προδιαγραφή OpenFeature). Το Flagsmith εφαρμόζει την ίδια ιδέα με έναν default flag handler, που εκτελείται «όταν ένα flag δεν βρίσκεται ή όταν αποτυγχάνει το αίτημα δικτύου προς το API» (τεκμηρίωση Flagsmith).

Η σχεδιαστική δουλειά βρίσκεται στην επιλογή αυτών των προεπιλογών:

• Τα release flags είναι από προεπιλογή απενεργοποιημένα. Αν το σύστημα flags είναι εκτός λειτουργίας, οι χρήστες βλέπουν την παλιά, δοκιμασμένη συμπεριφορά.
• Τα kill switches έχουν από προεπιλογή το feature ενεργό. Ένα kill switch υπάρχει για να απενεργοποιεί κάτι σε έκτακτη ανάγκη. Αν η υπηρεσία flags δεν είναι προσβάσιμη, δεν θέλετε να ενεργοποιηθούν όλα τα kill switches ταυτόχρονα και να ρίξουν μαζί τη μηχανή προτάσεων, την αναζήτηση και τις εργασίες billing.
• Τα permission flags έχουν από προεπιλογή το πιο περιοριστικό πακέτο. Αν τα δικαιώματα αποτυγχάνουν προς την ανοιχτή πλευρά, χαρίζετε επί πληρωμή λειτουργίες. Καλύτερα ενοχλημένοι πελάτες παρά λάθος αποτέλεσμα.
• Τα ops flags που απορρίπτουν φορτίο έχουν από προεπιλογή την κανονική λειτουργία, για τον ίδιο λόγο με τα kill switches.

Μετά δοκιμάστε το. Στρέψτε ένα περιβάλλον staging σε ένα μη προσβάσιμο endpoint flags και ελέγξτε ότι η εφαρμογή ξεκινά, εξυπηρετεί κίνηση και συμπεριφέρεται όπως ορίζουν οι προεπιλογές σας. Είναι σύντομη άσκηση και εντοπίζει τις περιπτώσεις όπου ένα SDK μπλοκάρει την εκκίνηση περιμένοντας το πρώτο του ruleset.

Βήμα 4: Αντιμετωπίστε κάθε αλλαγή flag ως deploy στην παραγωγή

Μια αλλαγή flag μπορεί να αλλάξει τη συμπεριφορά στην παραγωγή όσο και ένα deploy, χωρίς pull request, χωρίς review και χωρίς εκτέλεση CI. Το audit trail σας πρέπει να καλύψει αυτό το κενό.

Κατ' ελάχιστο, καταγράφετε για κάθε αλλαγή:

1. Ποιος την έκανε (συγκεκριμένο πρόσωπο, ποτέ κοινόχρηστος λογαριασμός)
2. Τι άλλαξε, ως diff των κανόνων πριν και μετά, όχι απλώς «ενημερώθηκε»
3. Πότε, με χρονοσημάνσεις που μπορείτε να αντιστοιχίσετε στο χρονολόγιο του περιστατικού
4. Γιατί, ως υποχρεωτικό πεδίο ελεύθερου κειμένου, ιδανικά με σύνδεσμο σε ticket

Στη συνέχεια στείλτε αυτά τα συμβάντα εκεί όπου ήδη κοιτάζει η ομάδα on-call. Μια αλλαγή flag που εμφανίζεται στο ίδιο κανάλι Slack ή στο ίδιο χρονολόγιο observability με τα deploys εντοπίζεται πολύ πιο εύκολα. Το «τι άλλαξε λίγο πριν αρχίσει αυτό;» είναι από τις πρώτες ερωτήσεις σε κάθε περιστατικό και ανήκει στο runbook απόκρισης σε περιστατικά σας. Αν η απάντηση είναι μοιρασμένη σε δύο εργαλεία, θα τη βρείτε αργά.

Για περιβάλλοντα παραγωγής, προσθέστε εγκρίσεις στα flags υψηλού κινδύνου (οτιδήποτε αγγίζει billing, auth ή διαγραφή δεδομένων). Τα περισσότερα hosted εργαλεία το υποστηρίζουν. Αν φτιάξετε δικό σας σύστημα, προβλέψτε το ρητά στον προγραμματισμό. Είναι εύκολο να αναβάλλεται.

Βήμα 5: Μην επαναχρησιμοποιείτε ποτέ ένα flag

Η Knight Capital είναι το σαφέστερο παράδειγμα του γιατί υπάρχει αυτός ο κανόνας. Από τις 27 Ιουλίου 2012, η Knight έκανε rollout νέου κώδικα για το Retail Liquidity Program (RLP). Σύμφωνα με την SEC, «ο νέος κώδικας RLP επαναχρησιμοποίησε επίσης ένα flag που παλαιότερα ενεργοποιούσε τον κώδικα Power Peg». Το Power Peg ήταν λειτουργικότητα που η Knight είχε σταματήσει να χρησιμοποιεί το 2003, αλλά «παρέμενε στον κώδικα και μπορούσε να κληθεί» (SEC Release No. 34-70694, 2013).

Ένας τεχνικός δεν αντέγραψε τον νέο κώδικα σε έναν από τους οκτώ servers, και κανένα δεύτερο πρόσωπο δεν έλεγξε το deployment. Όταν άνοιξαν οι συναλλαγές την 1 Αυγούστου, εντολές που έφεραν το επαναχρησιμοποιημένο flag έφτασαν σε εκείνον τον όγδοο server, ο οποίος εκτέλεσε αντί γι' αυτό τη νεκρή λογική του Power Peg. Μέσα σε διάστημα 45 λεπτών, «δρομολόγησε εκατομμύρια εντολές στην αγορά» και «πέτυχε πάνω από 4 εκατομμύρια εκτελέσεις σε 154 μετοχές, για περισσότερους από 397 εκατομμύρια τίτλους». Τελικά, «η Knight έχασε πάνω από $460 εκατομμύρια από αυτές τις ανεπιθύμητες θέσεις» (SEC, 2013).

Από αυτό προκύπτουν δύο διδάγματα, και ισχύουν και τα δύο για μια μικρή ομάδα:

• Τα κλειδιά flags είναι μίας χρήσης. Όταν ένα flag αποσύρεται, αποσύρεται και το όνομά του. Επιβάλετέ το μέσω εργαλείων, κρατώντας τα αρχειοθετημένα κλειδιά και απορρίπτοντας τη δημιουργία νέου flag με παλιό κλειδί.
• Η απόσυρση ενός flag σημαίνει διαγραφή του κώδικα πίσω από αυτό. Το flag δεν ήταν το μόνο πρόβλημα στην Knight. Νεκρός κώδικας εννέα ετών μπορούσε ακόμη να κληθεί. Η απενεργοποίηση ενός flag δεν είναι καθαρισμός.

Βήμα 6: Κάντε τον καθαρισμό μέρος του definition of done

Ο καθαρισμός flags γίνεται μόνο όταν συνδέεται με κάτι που ήδη συμβαίνει. Ως ξεχωριστό «sprint τεχνικού χρέους», δεν θα γίνει. Ο Hodgson περιγράφει τις πρακτικές που λειτουργούν: ορισμένες ομάδες προσθέτουν «μια εργασία αφαίρεσης toggle στο backlog της ομάδας κάθε φορά που εισάγεται για πρώτη φορά ένα Release Toggle», άλλες ορίζουν ημερομηνίες λήξης, και κάποιες φτάνουν μέχρι τις «“ωρολογιακές βόμβες” που κάνουν ένα test να αποτύχει (ή ακόμη και αρνούνται να εκκινήσουν την εφαρμογή!) αν ένα feature flag υπάρχει ακόμη μετά την ημερομηνία λήξης του» (martinfowler.com, 2017).

Μια εφαρμόσιμη εκδοχή για μικρή ομάδα:

1. Δημιουργήστε το ticket αφαίρεσης μαζί με το flag. Ίδιο PR, ίδιο πρόσωπο, με σύνδεσμο από την περιγραφή του flag.
2. Ορίστε λήξη με βάση τον τύπο του flag. Τα release flags παίρνουν από προεπιλογή 30 έως 40 ημέρες. Για μεγαλύτερο διάστημα χρειάζεται γραπτή αιτιολόγηση.
3. Κάντε το CI να αποτυγχάνει για ληγμένα release flags. Πρώτα μια ήπια προειδοποίηση, και μετά από μια περίοδο χάριτος, κανονική αποτυχία. Αρκεί ένας κανόνας lint ή ένα μικρό script που συγκρίνει τα κλειδιά flags στον κώδικα με τις ημερομηνίες λήξης στο εργαλείο flags. Αν δουλεύετε σε monorepo, κάντε το cached task δίπλα σε lint και tests.
4. Αναφέρετε τα παρωχημένα flags κάθε εβδομάδα στην ομάδα που είναι υπεύθυνη γι' αυτά, όχι σε μια κεντρική ομάδα platform που δεν μπορεί να κρίνει αν ένα flag χρειάζεται ακόμη.

Ο αυτοματισμός βοηθά σε μεγάλη κλίμακα. Το εργαλείο Piranha της Uber παράγει κώδικα που αφαιρεί αυτόματα τα παρωχημένα flags. Μεταξύ Δεκεμβρίου 2017 και Μαΐου 2019 «παρήγαγε diffs καθαρισμού κώδικα για 1381 flags (το 17% του συνόλου)», και το 65% αυτών των diffs «ενσωματώθηκε χωρίς καμία αλλαγή» (Ramanathan et al., ICSE-SEIP 2020). Σύμφωνα με τη δημοσίευση της Uber, το εργαλείο αφαίρεσε «περίπου δύο χιλιάδες παρωχημένα feature flags μαζί με τον σχετικό κώδικα» (Uber Engineering, 2020). Μια μικρή ομάδα δεν χρειάζεται το Piranha. Το δίδαγμα είναι ότι ακόμη και μια εταιρεία με αφοσιωμένες ομάδες εργαλείων διαπίστωσε ότι ο καθαρισμός των flags παραλειπόταν τόσο συχνά ώστε άξιζε να αυτοματοποιηθεί.

Να φτιάξετε ή να αγοράσετε σύστημα feature flags;

Για τις περισσότερες μικρές και μεσαίες ομάδες, αγοράστε ή κάντε self-host ένα open-source εργαλείο, και βάλτε μπροστά του το OpenFeature. Φτιάξτε δικό σας μόνο όταν τα flags είναι μέρος του ίδιου του προϊόντος σας, για παράδειγμα όταν οι πελάτες σας ρυθμίζουν rollouts μέσα στην πλατφόρμα σας.

Ένα βασικό αποθετήριο flags μοιάζει με project ενός Σαββατοκύριακου: ένας πίνακας, μια σελίδα διαχείρισης, μια συνάρτηση isEnabled(). Το κόστος βρίσκεται σε όσα ακολουθούν:

• Streaming ενημερώσεων σε κάθε διεργασία, με λογική επανασύνδεσης
• Ποσοστιαία rollouts με σταθερό hashing, ώστε ένας χρήστης να μην αλλάζει variant σε κάθε αίτημα
• Κανόνες στόχευσης, segments και ρυθμίσεις ανά περιβάλλον
• Audit trails, εγκρίσεις και αναφορές για παρωχημένα flags
• SDKs για κάθε γλώσσα και runtime που χρησιμοποιείτε, μαζί με τα κινητά

Αυτό είναι προϊόν, και κάποιος πρέπει να είναι υπεύθυνος γι' αυτό. Είναι το ίδιο δίλημμα που αναλύουμε στο πλαίσιο απόφασης build ή buy για CTOs. Αν το flagging δεν σας διαφοροποιεί από τους ανταγωνιστές, βαθμολογείται χαμηλά σε στρατηγική σημασία, και το πενταετές κόστος λειτουργίας ενός ιδιόκτητου συστήματος συνήθως ξεπερνά τη συνδρομή που προσπαθούσατε να γλιτώσετε.

Το OpenFeature μειώνει το κόστος μιας λάθος επιλογής. Είναι project του CNCF, έγινε δεκτό τον Ιούνιο του 2022 και βρίσκεται σε incubation από τον Νοέμβριο του 2023 (CNCF). Ο κώδικάς σας καλεί ένα API αξιολόγησης ανεξάρτητο από προμηθευτή. Ένας provider, δηλαδή «μια υλοποίηση συμβατή με το SDK που επιλύει τιμές flags από ένα συγκεκριμένο σύστημα διαχείρισης flags», συνδέεται από κάτω (γλωσσάριο OpenFeature). Τα hooks λειτουργούν «παρόμοια με το middleware σε πολλά web frameworks» (προδιαγραφή OpenFeature), οπότε το audit logging, οι μετρικές και η επικύρωση βρίσκονται σε ένα σημείο αντί για κάθε σημείο κλήσης. Αν ξεπεράσετε έναν προμηθευτή ή αν εκείνος αυξήσει τις τιμές του, αλλάζετε τον provider αντί να ξαναγράψετε κάθε έλεγχο flag.

Τρία μοτίβα συστημάτων flags που αξίζει να αναθεωρήσετε

Τρεις ρυθμίσεις που αξίζει να αλλάξετε νωρίς:

Λογική δικαιωμάτων μέσα στο εργαλείο flags. Στην αρχή είναι βολικό. Μετά το billing και το εργαλείο flags διαφωνούν για το τι έχει πληρώσει ένας πελάτης, και κανείς δεν ξέρει ποιο από τα δύο έχει δίκιο. Κρατήστε τα δικαιώματα των πακέτων στο δικό σας μοντέλο δεδομένων της εφαρμογής. Τα flags χειρίζονται το rollout αυτών των δικαιωμάτων, όχι τα ίδια τα δικαιώματα.

Η ίδια προεπιλογή για κάθε flag. Το «off» μοιάζει με ασφαλή επιλογή παντού, μέχρι να σκεφτείτε μια διακοπή της υπηρεσίας flags: κάθε kill switch ενεργοποιείται ταυτόχρονα. Επιλέξτε προεπιλογές ανά τύπο flag: release flags απενεργοποιημένα, kill switches ενεργά, δικαιώματα περιοριστικά.

Ο καθαρισμός ως νοικοκύρεμα. Το νοικοκύρεμα σπάνια χωρά σε ένα sprint. Αν συνδέσετε το ticket αφαίρεσης με το PR που προσθέτει το flag, είναι πολύ πιο πιθανό να τηρηθεί.

Συχνές ερωτήσεις

Ποια είναι η διαφορά ανάμεσα σε ένα feature flag και μια τιμή ρύθμισης;

Μια τιμή ρύθμισης συνήθως αλλάζει τον τρόπο λειτουργίας του συστήματος, όπως ένα timeout ή το μέγεθος ενός pool, και ακολουθεί το deploy. Ένα feature flag αλλάζει την εμπειρία των χρηστών. Μπορεί να στοχεύει συγκεκριμένους χρήστες ή segments και αλλάζει κατά την εκτέλεση χωρίς deploy. Η διάκριση θολώνει με τα ops flags, και γι' αυτό χρειάζονται το ίδιο audit trail με κάθε άλλο flag.

Πόσα feature flags είναι πάρα πολλά;

Δεν υπάρχει καθολικός αριθμός. Καλύτερο μέτρο είναι το ποσοστό των release flags που έχουν ξεπεράσει την ημερομηνία λήξης τους, και το αν αυτό το ποσοστό αυξάνεται. Αν δεν κάνετε τίποτα, ο αριθμός των flags μεγαλώνει: οι Rahman et al. διαπίστωσαν ότι μόνο το 20% των release toggles του Chrome είχε πράγματι αφαιρεθεί κατά την περίοδο της μελέτης (MSR 2016).

Πρέπει τα feature flags να αξιολογούνται στον client ή στον server;

Αξιολογείτε στον server όπου μπορείτε, μέσα στη διεργασία και πάνω σε ένα ruleset στην cache. Χρησιμοποιήστε client-side αξιολόγηση για browsers και εφαρμογές κινητών, όπου δεν μπορείτε να στείλετε όλους τους κανόνες στόχευσης στη συσκευή. Σε αυτή την περίπτωση, ο προμηθευτής αξιολογεί για έναν χρήστη και επιστρέφει μόνο τα αποτελέσματα.

Χρειαζόμαστε το OpenFeature αν χρησιμοποιούμε μόνο έναν προμηθευτή;

Δεν είναι απολύτως απαραίτητο, αλλά είναι φθηνή ασφάλεια. Σας δίνει ένα ενιαίο API αξιολόγησης σε όλες τις γλώσσες και ένα τυποποιημένο σημείο για hooks, όπως το audit logging. Η αλλαγή προμηθευτή αργότερα γίνεται απλή αντικατάσταση provider αντί για επανεγγραφή σε όλο τον κώδικα.

Τα flags που θα μετανιώσετε είναι αυτά που δεν έχουν υπεύθυνο

Ο σχεδιασμός ενός συστήματος feature flags αφορά κυρίως την ευθύνη. Δώστε σε κάθε flag τύπο, υπεύθυνο, προεπιλογή και ημερομηνία λήξης. Αξιολογείτε μέσα στη διεργασία. Καταγράφετε κάθε αλλαγή σαν deploy. Μην επαναχρησιμοποιείτε ποτέ ένα κλειδί, και διαγράφετε τον κώδικα όταν αποσύρετε ένα flag. Αν κάνετε αυτά, το εργαλείο που θα επιλέξετε μετράει πολύ λιγότερο.

Αν σχεδιάζετε ένα σύστημα flags ή καθαρίζετε ένα που έχει ξεφύγει από ό,τι μπορεί να παρακολουθήσει η ομάδα σας, μιλήστε μαζί μας. Βοηθάμε ομάδες B2B να στήνουν πρακτικές παράδοσης που λειτουργούν ακόμη και δεκαοκτώ μήνες αργότερα.