Odpowiedzi:
Flagi cech to inżynierskie urządzenie, którego można użyć, aby uniknąć długotrwałej gałęzi i konfliktów w rozwoju produktu. Oto, w jaki sposób można go użyć w kontekście języka zorientowanego obiektowo, aby pomóc programistom w pracy nad konkretną funkcją produktu, a jednocześnie obsługiwać nową wersję. To rozwiązanie może być również stosowane w kontekstach nie zorientowanych obiektowo, pod warunkiem istnienia pojęcia „interfejs”. ( porównaj system modułowy OCaml.)
Dla celów ilustracji zakładamy narzędzie prezentujące raporty o danych przechowywanych w bazie danych. Kod implementuje klasę DatabaseClient używaną do wykonywania żądań. Wraz ze wzrostem zbioru danych staje się jasne, że jakiś alternatywny układ danych poprawiłby wydajność aplikacji. Dlatego Alice opracuje nową wersję DatabaseClient, która będzie mogła pobierać dane ze struktur o ulepszonym układzie, podczas gdy Bob utrzyma historyczny DatabaseClient .
Wykonując następujące kroki, Alice i Bob mogą współpracować w krótkotrwałych oddziałach, minimalizując ich konflikty.
Alice zmienia nazwę DatabaseClient na DatabaseClient_v1 i tworzy klasę delegowaną o nazwie DatabaseClient, która używa obiektu DatabaseClient_v1 i implementuje interfejs o nazwie DatabaseClientInterface. (Jeśli to możliwe, ten interfejs DatabaseClientInterface powinien być artefaktem kodu, ale języki typu kaczego nie zawsze to obsługują).
Bob sprawdza zmiany wprowadzone przez Alicję w 1 i jest świadomy, że jego zadanie konserwacyjne powinno nastąpić na DatabaseClient_v1 .
Alice wprowadza w aplikacji nową flagę konfiguracji, która zarządza zachowaniem delegata DatabaseClient i implementuje symbol zastępczy DatabaseClient_v2 , klasę implementującą interfejs DatabaseClientInterface, którego metody wszystkie generują wyjątek „Nie zaimplementowano”.
Następnie Alice i Bob mogą współpracować bez wyraźnej synchronizacji, ponieważ kod napisany w odpowiednich iteracjach podlega obiektowi DatabaseClientInterface . Minimalizuje to ryzyko konfliktu wynikające z ich jednoczesnej pracy.
Iteracje z Alicji mogą być bardzo krótkie, takie jak implementacja testu, implementacja metody, a nawet częściowe wykonanie tej czynności, ponieważ podczas produkcji kod nie jest wybierany do użycia i nie musi być w pełni funkcjonalny. Zautomatyzowane testsuite powinno być skonfigurowane tak, aby interfejs DatabaseClientInterface zawsze używał DatabaseClient_v1, podczas gdy Alice może łatwo przełączać się na DatabaseClient_v2 podczas uruchamiania testsuite lokalnie - lub w niestandardowej konfiguracji CI. Gdy wszystko będzie gotowe, pojedyncze zatwierdzenie może wykonać zmianę, aktualizując wartość konfiguracji rządzącą delegatem DatabaseClient .
Kroki są dość „łatwe”, aby przejść do aplikacji z flagą funkcji, potrzebujesz w zasadzie dwóch rzeczy:
Podstawową flagą funkcji jest ich włączanie / wyłączanie, ale szybko będziesz chciał wydać nową funkcję w sposób przyspieszony, na przykład: 1 serwer na 5 hostujący aplikację ma funkcję „włączony”, aby rozpocząć, następnie włączasz tę funkcję na innym serwerze, dopóki wszystkie serwery nie będą „włączone”.
Oznacza to, że musisz uważać, aby Twoja funkcja była kompatybilna z aplikacją bez niej (na przykład dodatkowa kolumna w DB).
Szkielety istnieją w różnych językach, aby uniknąć ponownego wynalezienia koła, obecnie nieobsługiwany jeden z Etsy ma ciekawy plik Readme wyjaśniający, jak to działa.
Świat oprogramowania wbudowanego często używa flag czasu kompilacji, w samym kodzie aplikacji ( na przykład instrukcje #define/ #ifdef) i / lub w plikach konfiguracyjnych narzędzi kompilacji ( makefilena przykład).
Flagi kompilacji mogą być używane w podobny sposób nie tylko do funkcji, ale także do wszelkiego rodzaju refaktoryzacji kodu, migracji, obsługi debugowania itp.). Pozwalają na dokonywanie częściowych lub niezweryfikowanych zmian w gałęzi integracji bez przerywania kompilacji lub powodowania regresji funkcji / projektów już działających w gałęzi. Doskonały do obsługi poprawek punktów wraz z dużymi / ryzykownymi / powolnymi zmianami postępu (które w innym przypadku wymagałyby długotrwałej gałęzi) w sposób ciągłej integracji.
Ale oprócz weryfikacji już istniejącego kodu oddziału pod kątem regresji, możliwe jest również przeprowadzenie weryfikacji postępu / stabilności nowego kodu. W tym celu należy przełączyć flagi czasu kompilacji.
Jednym ze sposobów przełączania flag byłoby użycie, w osobnym potoku weryfikacji systemu CI tego samego oddziału (jeśli obsługuje taką funkcjonalność), pliku łaty przełączającego flagę - do zastosowania w osobnym obszarze roboczym przed budować. W tym obszarze roboczym zostanie zbudowany inny zestaw artefaktów, a następnie zweryfikowany.
Alternatywnie można pobrać długą gałąź funkcji z głównej gałęzi integracji, ale jedyną zmianą w tej gałęzi funkcji byłoby przełączenie flagi. Z powodu tej drobnej zmiany gałąź funkcji może zostać automatycznie zsynchronizowana bardzo szybko - praktycznie bardzo ściśle zacieniając główną gałąź integracji. Oddzielne wykonanie CI w tej gałęzi nie wymagałoby już wstępnego pliku łatek. Przenoszenie takiej gałęzi funkcji byłoby trywialne nawet przez dłuższy czas.
Możliwe jest również utworzenie w głównej gałęzi integracji nowych artefaktów kompilacji, które tak naprawdę byłyby tylko klonami istniejących artefaktów kompilacji, ale z przełączonymi flagami. W ten sposób ani wstępny plik łaty, ani gałąź funkcji nie byłyby konieczne do zweryfikowania nowego kodu, bezpośrednio w głównej gałęzi.