Η ανάπτυξη είναι όταν ο κώδικας φτάνει στην παραγωγή. Η κυκλοφορία είναι όταν κάποιος μπορεί πραγματικά να το χρησιμοποιήσει. Η σύγχυση των δύο είναι ένας από τους πιο γρήγορους τρόπους για να κάνετε κάθε ανάπτυξη λίγο τεταμένη στιγμή.
Τα feature flag χρησιμεύουν για να βάλουν χώρο ανάμεσα σε αυτές τις δύο στιγμές. Μπορείτε να αναπτύξετε σήμερα, να ενεργοποιήσετε αύριο για την εσωτερική ομάδα, μετά για έναν πιλοτικό πελάτη και μετά για το 10% των χρηστών. Εάν κάτι πάει στραβά, απενεργοποιήστε τη σημαία. Δεν χρειάζεται απαραίτητα να επαναφέρετε ολόκληρη την κυκλοφορία.
Η σημαία δεν είναι απλώς ένα αν
Τεχνικά είναι συχνά ένα if. Πολιτιστικά είναι πολύ περισσότερα.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Αυτό το μικρό if μπορεί να αντιπροσωπεύει μια σταδιακή διάθεση, ένα πείραμα, μια μετεγκατάσταση, μια άδεια επιχείρησης ή ένα λειτουργικό kill switch. Το πρόβλημα είναι ότι αν δεν το διαχειριστείς καλά, μπορεί να γίνει και τεχνικό χρέος που μένει στον κωδικό για δύο χρόνια.
Πού μπαίνει το OpenFeature
Το OpenFeature είναι μια ανοιχτή προδιαγραφή για την αξιολόγηση του feature flag με ένα κοινό API. Η ιδέα είναι απλή: ο κωδικός της εφαρμογής σας δεν πρέπει να εξαρτάται άμεσα από τον προμηθευτή ή το εσωτερικό σύστημα που χρησιμοποιείτε για σημαίες.
Η εφαρμογή ρωτά:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Ο πάροχος αποφασίζει από πού προέρχονται οι κανόνες: SaaS, αρχείο, εσωτερική υπηρεσία, σημαία, διαμόρφωση GitOps. Εάν κάποια μέρα αλλάξετε το backend επισήμανσης χαρακτηριστικών, η εφαρμογή δεν χρειάζεται να ξαναγραφτεί παντού.
Αυτός ο διαχωρισμός φαίνεται σαν μια αρχιτεκτονική λεπτομέρεια, αλλά γίνεται αισθητός καθώς το έργο μεγαλώνει.
Το πλαίσιο είναι η μισή μάχη
Μια σημαία ενεργοποίησης ή απενεργοποίησης για όλους είναι χρήσιμη, αλλά περιορισμένη. Η προοδευτική παράδοση ζει στο πλαίσιο:
- εσωτερικός ή εξωτερικός χρήστης.
- δωρεάν ή επιχειρηματικό σχέδιο
- χωριό
- οργάνωση·
- έκδοση εφαρμογής.
- σταθερό ποσοστό κίνησης.
Το σημαντικό κλειδί είναι targetingKey: πρέπει να είναι σταθερό. Αν αλλάζει με κάθε αίτημα, ένας χρήστης μπορεί να καταλήξει μία φορά στην παραλλαγή Α και μία στην παραλλαγή Β. Για ένα πείραμα είναι τρομερό, για ένα ταμείο μπορεί να είναι καταστροφικό.
Μια λογική διάθεση
Μια ροή που μου αρέσει είναι η εξής:
- Αναπτύξτε με σημαία σβηστή.
- ανάφλεξη για προγραμματιστές και QA.
- Ενεργοποίηση για πιλότο πελάτη ή ενοικιαστή.
- 5% διάθεση.
- διάθεση στο 25%.
- 100% διάθεση.
- αφαίρεση παλιού κωδικού και σημαίας.
Το συχνά ξεχασμένο σημείο είναι το τελευταίο. Μια προσωρινή σημαία πρέπει να έχει ημερομηνία θανάτου. Αν μείνει για πάντα, κάθε μελλοντικός ανασχηματιστής θα πρέπει να ρωτήσει: «μα είναι ακόμα χρήσιμο αυτός ο κλάδος;».
Kill switch: ετοιμάστε τα πρώτα
Το kill switch είναι η σημαία που σας σώζει όταν μια εξωτερική εξάρτηση αρχίζει να σας ενοχλεί, μια εργασία καταναλώνει πάρα πολλούς πόρους ή η νέα λογική δημιουργεί περίεργα σφάλματα.
Ένα καλό kill switch πρέπει να είναι:
- εύκολο να βρεθεί?
- τεκμηριωμένη στο runbook.
- δοκιμάζεται περιστασιακά.
- παρατηρήσιμο όταν ενεργοποιείται.
- ανεξάρτητο, όσο το δυνατόν περισσότερο, από το τμήμα που θα μπορούσε να σπάσει.
Το χειρότερο είναι να ανακαλύψεις κατά τη διάρκεια του ατυχήματος ότι η σημαία υπάρχει, αλλά κανείς δεν ξέρει αν εξακολουθεί να λειτουργεί.
Παρατηρησιμότητα ή όχι προοδευτική παράδοση
Η ενεργοποίηση μιας λειτουργίας στο 10% χωρίς να εξετάζετε μετρήσεις είναι απλώς αισιοδοξία με πολλά βήματα.
Κάθε κυκλοφορία θα πρέπει να απαντά σε απλές ερωτήσεις:
- έχουν αυξηθεί τα σφάλματα;
- έχει αλλάξει η καθυστέρηση;
- ολοκληρώνουν οι χρήστες τη ροή;
- υπάρχουν περισσότερα εισιτήρια ή επαναλήψεις;
- επηρεάζει μια παραλλαγή μόνο ένα τμήμα;
OpenFeature υποστηρίζει αγκίστρια γύρω από την αξιολόγηση σημαίας. Είναι χρήσιμα για την καταγραφή σφαλμάτων, την προσθήκη μετρήσεων ή τη σύνδεση της βαθμολογίας με ένα trace.
Ονομασία και ιδιοκτησία
Τα ονόματα έχουν σημασία. new_ui δεν λέει τίποτα. Το checkout.v2.enabled λέει πολλά περισσότερα.
Για κάθε σημαία θα σημείωνα τουλάχιστον:
- όνομα
- περιγραφή
- ιδιοκτήτης
- ασφαλής προεπιλογή
- ο λόγος για τον οποίο υπάρχει.
- ημερομηνία ή προϋπόθεση απομάκρυνσης.
Μια σημαία χωρίς ιδιοκτήτη είναι σχεδόν πάντα μια σημαία που κανείς δεν θα καθαρίσει.
Πού να τα αξιολογήσετε
Frontend, backend ή edge; Εξαρτάται.
Εάν η σημαία είναι για διάταξη, αντιγραφή ή ενσωμάτωση, η διεπαφή είναι εντάξει. Εάν αφορά δικαιώματα, χρέωση, όρια ή ευαίσθητα δεδομένα, πρέπει να βρίσκεται στο backend. Εάν περιλαμβάνει πειράματα δρομολόγησης ή υψηλής επισκεψιμότητας, η άκρη μπορεί να έχει νόημα.
Ο απλός κανόνας: το frontend μπορεί να βελτιώσει την εμπειρία, αλλά δεν πρέπει να είναι το μόνο εμπόδιο ασφαλείας.
Συμπέρασμα
Το feature flag που έγινε καλά αλλάζει τη σχέση με την παραγωγή. Δεν εξαλείφουν τον κίνδυνο, αλλά τον κάνουν μικρότερο και πιο διαχειρίσιμο. Μπορείτε να απελευθερώσετε σε φέτες, να παρατηρήσετε, να σταματήσετε, να επιστρέψετε, να μάθετε.
Το OpenFeature προσθέτει μια καθαρή βάση: ένα κοινό API, εναλλάξιμους παρόχους και έναν πιο τακτοποιημένο τρόπο ανάπτυξης του συστήματος. Αλλά η πειθαρχία παραμένει δική σας: ασφαλείς προεπιλογές, ξεκάθαρα ονόματα, μετρήσεις, ιδιοκτήτες και καθαριότητα.
Η καλύτερη σημαία είναι αυτή που σε βοηθά να απελευθερωθείς ήρεμα και μετά εξαφανίζεται όταν δεν χρειάζεται πλέον.