Obecność kodu nie musi oznaczać dostępności funkcji
Nowy ekran może już znajdować się na serwerze, a mimo to pozostawać niewidoczny dla większości użytkowników. Flaga funkcji pozwala rozdzielić publikację kodu od udostępnienia zachowania. W przykładzie nowej listy spraw najpierw korzysta z niej zespół pilotażowy, a dopiero później reszta organizacji. Dzięki temu można zebrać informacje o prawdziwej pracy bez zmieniania doświadczenia wszystkich jednocześnie. Flaga nie zastępuje jednak testów wykonanych przed wdrożeniem.
Zacznij od określenia, co dokładnie przełączasz: układ widoku, sposób obliczenia wyniku czy zapis danych. Pierwszy przypadek zwykle łatwiej odwrócić niż zmianę modelu informacji. Nie łącz pod jednym przełącznikiem kilku niezależnych funkcji tylko dlatego, że trafiły do wspólnego wydania. Gdy pojawi się problem, zespół powinien móc wyłączyć konkretną zmianę, a nie cały zestaw udanych ulepszeń wraz z jednym wadliwym elementem.
Grupa odbiorców musi być stabilna i zrozumiała
Użytkownik nie powinien widzieć starego ekranu po odświeżeniu i nowego po kolejnym kliknięciu, jeżeli nie taki jest cel projektu. Przydział do grupy oprzyj na stabilnym identyfikatorze i jawnej regule. W systemie zespołowym często właściwszą jednostką jest cała organizacja niż pojedyncza osoba. W przeciwnym razie współpracownicy mogą operować na niezgodnych widokach i udzielać sobie instrukcji, które nie pasują do ich ekranów.
Kontekst oceny flagi może zawierać środowisko, identyfikator grupy i dozwolone cechy konta. Przekazuj wyłącznie potrzebne dane; adres e-mail lub pełna historia klienta zazwyczaj nie są konieczne do stabilnego podziału. Zapisz regułę wyboru i jej właściciela. Nie nazywaj pilotażu eksperymentem losowym, jeśli grupę dobrano ręcznie spośród najbardziej zaawansowanych pracowników. Taki test nadal jest użyteczny, ale odpowiada na inne pytania niż reprezentatywne porównanie zachowań.
Domyślne zachowanie jest częścią projektu bezpieczeństwa
Usługa flag lub konfiguracja może być chwilowo niedostępna. Ustal, co wtedy zrobi aplikacja. Dla zwykłego nowego widoku bezpieczny może być powrót do starego rozwiązania. Dla kontroli uprawnień takie uproszczenie byłoby niewystarczające: flaga funkcji nie jest autoryzacją. Użytkownik bez prawa do danych nadal nie może ich uzyskać, nawet gdy ręcznie wywoła ukryty adres. Ochrona musi działać niezależnie od widoczności przycisku.
Sprawdź zgodność decyzji między frontendem a backendem. Jeżeli klient pokazuje nowy formularz, a serwer oczekuje starego kontraktu, otrzymasz błędy trudne do odtworzenia. Przy długiej sesji reguła może zmienić się w połowie zadania. Zdecyduj, czy rozpoczęta operacja kończy się według pierwotnego wariantu, czy wymaga ponownego otwarcia. Odbiorca nie powinien stracić wpisanej pracy tylko dlatego, że administrator zwiększył procent wdrożenia.
Wyłączenie funkcji nie cofa już zapisanych skutków
Przełącznik awaryjny może zatrzymać nowe użycia, lecz nie usuwa zapisów wykonanych wcześniej. Jeśli nowa funkcja utworzyła inny typ rekordu, stary kod musi go rozumieć albo bezpiecznie odizolować. Zanim uruchomisz pilotaż, sprawdź drogę powrotu. Nie obiecuj natychmiastowego cofnięcia całej zmiany, gdy wyłączenie dotyczy wyłącznie interfejsu. Zapisane dokumenty, wysłane wiadomości i decyzje użytkowników istnieją nadal.
Dla operacji zależnych od schematu bazy potrzebny jest plan kompatybilności. Flaga może pomóc przełączyć odczyt, ale nie zastępuje migracji danych. W dzienniku wydania zapisz, po którym etapie powrót wymaga dodatkowej korekty. Dobrze sprawdza się krótka próba: utworzyć obiekt nową funkcją, wyłączyć ją i wykonać na tym obiekcie podstawowe zadania. Taki test ujawnia ograniczenia, których nie pokaże samo sprawdzenie, czy zniknął przycisk.
Obserwacja powinna mieć próg zatrzymania
Przed uruchomieniem określ miary: błędy, czas ukończenia zadania, liczbę porzuceń i zgłoszenia użytkowników. Porównuj podobne zadania i uwzględniaj wielkość grupy. Kilka udanych kliknięć nie dowodzi gotowości do pełnego wdrożenia, a pojedyncza reklamacja nie zawsze oznacza błąd nowego kodu. Potrzebny jest kontekst: wersja, wariant flagi, rodzaj operacji i moment wystąpienia. Nie zapisuj przy tym w telemetryce zbędnych treści klientów.
Ustal, kto może zwiększać zakres i kto ma prawo zatrzymać rollout. Zapisuj zmiany konfiguracji tak samo starannie jak wdrożenia kodu. Bez tej historii nagły wzrost błędów może wyglądać tajemniczo, choć nastąpił dokładnie po udostępnieniu funkcji większej grupie. Zaplanuj także kanał informacji dla uczestników pilotażu. Pracownik powinien wiedzieć, gdzie zgłosić problem i czy powrót do starego widoku jest jeszcze możliwy.
Flaga tymczasowa potrzebuje daty usunięcia
Każdy dodatkowy przełącznik zwiększa liczbę możliwych kombinacji zachowania. Po udanym wdrożeniu usuń niepotrzebną gałąź starego kodu, reguły i testy przejściowe. Pozostawienie kilkudziesięciu zapomnianych flag utrudnia diagnozę oraz rozwój. W rejestrze przełączników zapisz właściciela, cel, domyślną wartość i warunek zakończenia. Nie każda flaga musi być krótka, ale każda powinna mieć świadomie określony cykl życia.
Próba odbiorowa obejmuje obie wartości flagi, awarię konfiguracji, zmianę w trakcie sesji i konto nieuprawnione. Sprawdź również wykonawców zadań w tle, które mogą działać dłużej niż żądanie WWW. Stopniowe wdrażanie daje możliwość uczenia się na ograniczonej skali, pod warunkiem że potrafisz rozpoznać wariant i zatrzymać problem. Bez obserwacji i sprzątania staje się tylko dodatkową warstwą ukrytych ustawień, zamiast narzędziem kontrolowanego rozwoju.