Sytuacja kobiet w IT w 2024 roku
11.12.20194 min
Matt Eland

Matt ElandSoftware Development ManagerMoveHQ

Do czego przydaje się technika Feature Flag

Dowiedz się, czym jest technika Feature Flag, jak można ją łatwo wdrożyć, poznaj typy flag oraz sposoby ich wywoływania.

Do czego przydaje się technika Feature Flag

Feature Flag (nazwijmy to w tekście flagą), to prosta technika, która pozwala przełączać, czy w oprogramowaniu dostępna jest nowa funkcja lub jakiś jej element.

W tym artykule omówię, dlaczego to całkiem przydatny pomysł, jak można wdrożyć prostą flagę, różne jej typy i różne sposoby ich wywoływania.

Dlaczego warto korzystać z opcji flagi?

Na pierwszy rzut oka pomysł z używaniem flagi brzmi nieco dziwnie - w końcu jeśli nie chcesz, aby funkcja była dostępna, dlaczego umieszczać ją w kodzie?

Po pierwsze, to, co działa dobrze dla jednego przypadku, może nie działać poprawnie z szerszymi zestawami danych lub interakcjami w środowisku produkcyjnym. Możesz zdefiniować flagę tylko dla użytkowników wersji beta, w której funkcja jest włączona tylko dla podzbioru użytkowników, dopóki nie upewnisz się, że działa bez błędów.


Po drugie, wiele produktów ma dokładnie skoordynowaną datę „uruchomienia”. Możesz chcieć z wyprzedzeniem wprowadzić nowy kod na produkcję, aby zmniejszyć dodatkowe ryzyko, a następnie aktywować funkcję, gdy nadejdzie określona data.

Jest jeszcze takie uzasadnienie, że jeśli często robisz release’y na produkcji, zarządzanie gałęziami może być trudne, jeśli ukończenie dużych funkcji zajmuje sporo czasu. Spędzasz więcej czasu na zarządzaniu różnymi gałęziami, tracisz produktywność i możliwości znalezienia błędów na wcześniejszym etapie cyklu. Flagi pozwalają wypuszczać częściowe funkcje w trybie offline na produkcji, ale z możliwością przetestowania ich na środowisku testowym, zanim pełna funkcja będzie gotowa, przy okazji testów wersji produkcyjnej.

Implementacja Feature flag

Więc jak faktycznie wygląda implementacja takich flag?

private static IResumeAnalyzer GetResumeAnalyzer()
{
    // Check whatever configuration management this application uses
    if (ConfigHelper.GetBoolean("UseNewAnalyzer"))
    {
        return new RewrittenAnalyzer();
    }
    else
    {
        return new ResumeAnalyzer();
    }
}


W powyższym przykładzie pobieramy ustawienie z dowolnego pliku konfiguracyjnego, z którego korzysta framework naszej aplikacji. Jeśli wartość UseNewAnalyzer ma wartość true, wówczas zostanie użyty RewrittenAnalyzer, w przeciwnym razie zostanie użyta starsza wersja.

Niezwykle prosty kod, ale pozwala nam to zmienić jeden plik, a aplikacja zaczyna się zachowywać zupełnie inaczej. W zależności od języka i środowiska, na które wgrywamy kod, aplikacja może nawet nie wymagać ponownego uruchomienia.

Sposoby konfigurowania Feature Flags

Flagi nie muszą być ustawiane w pliku konfiguracyjnym. Istnieje wiele innych opcji, które mogą mieć sens w różnych przypadkach.

Typowe wyzwalacze flag bazują na:

  • Wartościach w plikach konfiguracyjnych (patrz powyższy przykład)
  • Wartościach z tabeli bazy danych
  • Aktywnych i nieaktywnych w określonym dniu (lub w zakresie dat)
  • Aktywnych tylko dla użytkowników wersji beta
  • Aktywnych tylko przez określony procent czasu lub dla losowej części użytkowników (zwykle używany w testach A/B)
  • Na podstawie wartości zwróconych przez zewnętrzne usługi webowe
  • Zarządzane przez zewnętrzną usługę, taką jak LaunchDarkly

Wady Feature Flags

Okej, więc flagi ułatwiają wgrywanie kodu, który ma pozostać offline lub dla określonego podzbioru użytkowników. Brzmi dobrze, ale gdzie jest haczyk?

Nic nie jest za darmo, a za flagi płacisz w kilku kluczowych obszarach:

Testowanie

Testowanie staje się trudniejsze i zajmuje więcej czasu, ponieważ musisz teraz upewnić się, że testujesz aktywację i dezaktywację funkcji. Widziałem zespoły próbujące zastosować flagi i testować je tylko w stanie aktywnym, a następnie patrzące, jak środowisko się sypie, bo alternatywna ścieżka nie działa.

Ponadto, jeśli różne funkcje oddziaływują na siebie i każda z nich ma przełącznik, należy przetestować wszystkie kombinacje różnych stanów funkcji. Jest to kluczowy powód, dla którego zdecydowanie zalecam usunięcie starych flag, które są obecnie zawsze włączone lub zawsze wyłączone.

Schemat bazy danych

Jeśli masz nową funkcję wymagającą migracji w bazie danych, który wpływa na istniejącą tabelę, musisz pomyśleć o tym, jak stare dane będą działać, jeśli funkcja jest w trybie offline. Co się stanie, jeśli funkcja będzie musiała przejść z trybu online do trybu offline (lub vice versa) i rozważyć inne związane z tym problemy.

Zwykle najlepszym rozwiązaniem jest migracja danych w momencie wgrania nowej flagi - nawet jeśli miałoby to być w trybie offline. Ale może nie być to możliwe we wszystkich przypadkach.

Alternatywnie można przechować wersję określonego feature'a w kolumnie modyfikowanej tabeli - by można było rozróżnić, które wiersze są powiązane z nowym sposobem działania, a które ze starym. Pomaga to kontrolować migracje do oraz z nowego stanu funkcji, ale koszt związany ze złożonością takiego rozwiązania jest wysoki.

Zarządzanie konfiguracją

Narzut związany z większą ilością konfigurowania oznacza, że teraz nieco trudniej jest administrować każdym środowiskiem i śledzić stan każdej funkcji w każdym środowisku, co może prowadzić do zamieszania i innych problemów.

Następne kroki

Ostatecznie flagi są dobrą opcją do rozważenia w przypadku głównych, długofalowych funkcji beta, które muszą wyjść wcześniej lub w przypadku nieco ryzykownych zmian, które mogą wymagać opcji szybkiego wycofania bez zmiany lub wgrania kodu.

Chociaż w niektórych przypadkach używam flag, wolę używać biblioteki Scientist do testowania efektów nowego kodu w środowisku produkcyjnym bez ryzyka popsucia czegoś dla użytkownika.

<p>Loading...</p>