Przełączanie funkcji vs gałęzie funkcji

Co to są "przełączniki funkcji" i "gałęzie funkcji" i jaka jest różnica między nimi?

Jakie są plusy i minusy? Dlaczego jeden jest lepszy od drugiego?

Znalazłem kilka artykułów na temat tego w Google i zazwyczaj jestem w obozie "przełączanie funkcji", ale nie jestem przekonany, że "przełączanie funkcji" jest lepszym wyborem we wszystkich przypadkach.

Author: Ian Ringrose, 2013-10-17
Source

3 answers

Przełączniki funkcji są metodologią stosowaną w łańcuchu ciągłej integracji / ciągłej dostawy (CI / CD) (Metodologia projektu Agile/Kanban). Zasadniczo wysyłasz nowe funkcje do produkcji w stanie wyłączonym, a następnie w konsoli administratora włączasz tę funkcję (lub wyłączasz ją, jeśli odkryjesz, że jest zepsuta).

Gałęzie funkcji mogą być częścią metodologii wydania i zintegrowane w łańcuch ciągłej integracji. Możesz rozwinąć w gałęzi feature, wdrożyć gałąź do DEV/QA, uzyskać certyfikacja, połącz gałąź funkcji z trunk, a następnie popchnij trunk do środowisk SIT / UAT / PROD.

Istnieją plusy i minusy związane z tym podejściem. Przełączanie funkcji wymaga bardzo ścisłej dyscypliny, ponieważ zepsuty / ciemny kod trafia do produkcji. Jest to idealne rozwiązanie dla startupów i sklepów, w których kierownictwo wie, jak to zrobić i ma Narzędzia automatyzacji systemu (Chef/Puppet/cfengine itp.) Google, Facebook, LinkedIn, WordPress wszystkie wdrażają się w środowiskach produkcyjnych za pomocą przełączanie funkcji i automatyzacja systemu.

Istnieją pewne wymagane "techniki", aby poprawnie przełączać funkcje: ciągłe dostarczanie/wdrażanie, ciągła Integracja, zautomatyzowane testy jednostkowe, zautomatyzowane testy integracyjne, zautomatyzowane testy stresu / wydajności, automatyzacja systemu. Jeśli ich nie masz, rozważ prostszą strategię wydania (np. rozgałęzianie funkcji.)

 37
Author: Electrawn,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-09-22 18:30:03

Omawiam to dogłębnie na moim blogu: http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx

Krótko mówiąc, gałęzie funkcji dadzą ci lepszą izolację, ale wymagają radzenia sobie z bólem odroczonej integracji i łączenia. Przełączniki zapewniają ciągłą integrację, ale wymagają zaprojektowania/wdrożenia kodu w taki sposób, aby obsługiwał przełączniki, i wprowadzają ryzyko, że niedokończony kod funkcji może negatywnie wpłynąć na produkcję.

Możesz użyć obie gałęzie i przełączniki razem (nie wykluczają się wzajemnie). Jeśli chodzi o decydowanie, którego z nich użyć w każdym scenariuszu, moje myśli są takie, że przełączniki powinny być domyślnym wyborem, chyba że następujące są prawdziwe: {]}

  • trudno ukryć funkcjonalność za przełącznikiem
  • ma potencjalny wpływ na obszar aplikacji, który nie ma dokładnych testów

Jeśli którykolwiek z tych warunków jest prawdziwy, prawdopodobnie użyłbym gałęzi funkcji zamiast toggle.

 17
Author: Dylan Smith,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-07-15 20:23:00

Przełączanie funkcji wymaga bardzo ścisłej dyscypliny, ponieważ broke/dark code jest do produkcji.

Zgadzam się z Electrawn, używam feature od 6 lat, bo w naszym przypadku nie mamy wymagań pre.

Ważne jest również, aby zrozumieć, że "strategia Toogle" przenosi wysiłek spędzony w strategii Feature Branch( Scalanie) na inny moment.

Http://martinfowler.com/bliki/FeatureToggle.html

Jest bardzo ważne, aby wycofać przełączniki, gdy oczekujące funkcje zostaną wprowadzone do produkcji. Polega to na usunięciu definicji z pliku konfiguracyjnego i całego kodu, który ich używa. W przeciwnym razie otrzymasz stos przełączników, których nikt nie pamięta, jak używać. W jednym pamiętnym przykładzie usłyszałem o, wymagało to specjalnej rekompilacji jądra Linuksa, aby obsłużyć wystarczającą liczbę przełączników linii poleceń.

Uwaga: przestrzeganie zasad SCM jeśli ktoś otworzy i edytować plik może to być uszkodzony kod.

Więc z mojej perspektywy nie wierzę w "lepszy wybór we wszystkich przypadkach", ponieważ to zależy od kultury Twojego zespołu i czy masz okładkę testową.

To bardzo polemiczne pytanie.

W moim przypadku nadal preferuję strategię Feature Branches. Zachowując najlepsze praktyki SCM i planując mapę drogową, proces scalania wydaje się być łatwym sposobem. W tym roku słyszałem, że wiele osób narzeka na proces scalania, ale w w wielu przypadkach problem scalania jest taki sam z mojego doświadczenia, "komunikacja zawodzi":)

Przepraszam za niedokładną odpowiedź, ale wydaje mi się, że w SCM są jakieś ludzkie aspekty związane z tym tematem.

 4
Author: Eduardo Fabricio,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-17 19:33:07