Jak nauczyć się właściwego podejścia do wdrożenia połowy funkcji? [Zamknięte]

12

Kieruję zespołem programistów i chcę wypuszczać nasz produkt tak często, jak to możliwe (Continuous Delivery).

W wielu przypadkach musimy wdrożyć funkcję, której wdrożenie zajmuje więcej czasu niż czas między wydaniami. Nadal chcę, aby ludzie codziennie zatwierdzali swój kod (ciągła integracja).

Wiele razy implementacja nowej funkcji wymaga zmiany istniejącej funkcji, a istniejące funkcje oczywiście nadal muszą działać, nawet jeśli nowa funkcja nie jest jeszcze ukończona.

Jeśli programista zastosuje właściwe podejście , może ostrożnie dostosować istniejące funkcje, a wszystkie powyższe nie stanowią problemu.

Jakie jednak właściwe jest właściwe podejście? Mój własny dostrojony umysł programistyczny mówi mi, co robić w każdym indywidualnym przypadku, ale muszę się więcej nauczyć i potrzebuję materiałów do czytania, które mogę przeczytać i polecić członkom zespołu do przeczytania. Lub zrobi to każda inna metoda uczenia się właściwego sposobu uczenia się tego podejścia.

Więc to jest pytanie. Jak upewnić się, że członkowie zespołu nauczą się właściwego podejścia do wdrożenia połowy funkcji?

Szukałem osób twierdzących, że mają strategie w tym zakresie, ale jeszcze ich nie znalazłem, z wyjątkiem osób piszących kilka przypadkowych przemyśleń na ten temat. Być może nie używam odpowiednich słów wyszukiwania lub być może nikt nie podał w tej sprawie żadnych miarodajnych wskazówek.

Niels Brinch
źródło
„istniejące funkcje oczywiście nadal muszą działać” - zależnie od kontekstu, terminem takim wymaganiem może być zgodność wsteczna lub brak błędów regresji
gnat
1
Różne typy testów automatycznych mogą zmniejszyć ryzyko błędów w zmianach kodu. Czek. Szukam podejścia do zastosowania jako programista, który musi wdrożyć dużą funkcję, która może obejmować 75% zmian w istniejącym kodzie i 26% nowego kodu (dodatkowy procent to dodatkowa tajemnica).
Niels Brinch,
1
@Niels: Musisz mieć niesamowitych programistów, aby mogli mieć działający kod na koniec każdego dnia, który można sprawdzić w głównej gałęzi i przejść wszystkie testy. Albo to, albo zrobią to minimum, więc są w stanie sprawdzić swój kod do końca dnia.
Dunk
nie nazwaliby tego „Oddziałem funkcji”. Dokonujesz zmian w gałęzi, a następnie scalasz gałąź z powrotem w master po zakończeniu operacji. Nie powinieneś prezentować w połowie zaimplementowanych funkcji w demach, więc nie rozumiem, dlaczego to nie zadziałałoby.
deltree,

Odpowiedzi:

14

Mam już inne zdanie na temat innych odpowiedzi tutaj. Zgadzam się z tobą, że chcesz jak najszybciej zintegrować zmiany od programistów i nadal testować kombinację kodu.

Nie zgadzam się jednak z tym, że jego prawo do wysyłania kodu zostało opracowane dziś rano, tylko dlatego, że wypuszczamy je dziś po południu. To przepis na rozczarowanych klientów.

Rozwiązaniem jest posiadanie gałęzi w drzewie kontroli wersji oraz oddzielny proces promowania zweryfikowanych delt z gałęzi developerskiej do gałęzi wydania.

W ten sposób uzyskasz to, co najlepsze z obu światów. Deweloperzy wykonują ciągłą integrację, a korzyści, które z tego wynikają, zapewniają stabilną wysyłkę kodu do klienta regularnie, a także nowy proces testowania ukończonych funkcji w branży deweloperskiej, a jeśli przejdą testy, czynią je częścią wydanego produktu .

Są dwa znane mi narzędzia, które dobrze obsługują tego rodzaju procesy. Jeśli twoja struktura programistyczna jest prosta, to git z git-flow implementuje dobrą strukturę rozgałęziającą, która działa dobrze w małych i średnich zespołach (być może 20 programistów).

W przypadku większych zespołów programistycznych lub tam, gdzie potrzebna jest bardziej złożona strategia rozgałęziania w celu obsługi wielu „obrotów” Twojego produktu, dokładność jest najlepsza na rynku. Programiści niezaangażowani w zarządzanie zmianami będą narzekać, że jest to trudniejsze niż pod-wersja itp. ... ale obsługuje złożone środowiska programistyczne.

Michael Shaw
źródło
Byłbym bardzo zainteresowany, aby dowiedzieć się więcej o strategii rozgałęziania, o której mówisz. Czy masz link do artykułu lub czegoś innego, co bardziej szczegółowo wyjaśnia pojęcie, o którym mówisz?
Niels Brinch,
2
tutaj jest nvie.com/posts/a-successful-git-branching-model dla git flow
Michael Shaw
Kluczową cechą git flow jest jasno określona strategia rozgałęziania, co czyni go dobrym wyborem dla produktu, który ma tylko jedno wydanie do wyprodukowania. Accurrev nie wymusza strategii rozgałęziania, ale ma elastyczność i zapewnia narzędzia do skutecznego zarządzania znacznie bardziej złożonym drzewem gałęzi.
Michael Shaw,
6

Występują tutaj dwa problemy: jeden wdraża połowę funkcji; drugim jest utrzymanie produktu wysyłkowego w ciągłym rozwoju.

Wdrażanie połowy funkcji

Pomoże w tym silny nadrzędny projekt. Pozwala to na implementację funkcji z jasno określonymi granicami - np. Interfejsy API do sąsiednich bitów kodu, oczekiwania dotyczące struktur danych oraz zrozumienie, w jaki sposób i kiedy zostanie wywołany zaimplementowany kod.

Testy mogą obejmować wymyślone wersje kodu dla innych części funkcji; Pomaga to wygładzić przejście, gdy idziesz do wdrożenia drugiej połowy.

Utrzymanie produktu wysyłkowego w działaniu

Istnieje tutaj kilka opcji:

  1. Wyłącz funkcję w wysyłanym produkcie. To, że kod znajduje się w produkcie, nie oznacza, że ​​należy go wykonać lub przedstawić użytkownikom. Minusem jest to, że nie zapewnisz użytkownikom dodatkowej wartości i nie otrzymasz opinii.
  2. Ujawnij użytkownikom krawędzie funkcji. Pokaż, co masz, i podaj wskazówki, co ma nadejść.
  3. Pozwól użytkownikom przełączać się między nową i starą funkcjonalnością. Czasami wymaga to utrzymania dwóch ścieżek kodu, które są gotowe dla użytkownika końcowego.

Na koniec, jeśli masz problemy z którymkolwiek z tych rozwiązań, zastanów się, czy podzieliłeś funkcję wzdłuż właściwych granic. Gdyby pokroić rzeczy w inny sposób, czy łatwiej byłoby je rozdzielić?

Alex Feinman
źródło
Łatwo jest wyłączyć nową funkcję, która nie jest całkowicie gotowa. To dobra rada. Zatem głównym problemem w dostarczanym produkcie jest to, że ISTNIEJĄCE funkcje mogą ulec awarii, jeśli ludzie nie zastosują właściwego podejścia, gdy zmieniają istniejący kod.
Niels Brinch,
2
W tym momencie pojawia się dobre testowanie. Jeśli nie masz wystarczającego zasięgu dla swojej bazy kodu, być może może to być wyzwaniem dla tego wysiłku?
Alex Feinman,
Ale czy odpowiedzią na moje pytanie może być po prostu „wykonaj dobrą praktykę kodu i wykonaj testy jednostkowe” itp.?
Niels Brinch,
1

Jak upewnić się, że członkowie zespołu nauczą się właściwego podejścia do wdrożenia połowy funkcji?

Ucząc ich. (duh)

Uczenie się będzie obejmować iterację: próbowanie czegoś, zobaczenie, jak to działa, a następnie modyfikowanie ich podejścia, aby osiągnąć lepsze wyniki. W przypadku tego rodzaju rzeczy zalecałbym recenzowanie projektu / kodu. Zobaczysz, w jaki sposób zaprojektowano / wdrożono półfunkcję i masz okazję wyrazić opinię. „To i to nie zadziała, bo zepsują nasz CI; co powiesz na XYZ?”, „Dobra robota tutaj, to naprawdę czyste”.

Robienie recenzji jako zespołu pomoże wszystkim dowiedzieć się, co już intuicyjnie wiesz.

Telastyn
źródło
Jestem z tym całkowicie związany. Ale tak jak mogę kogoś nauczyć, jak przeprowadzać testy jednostkowe LUB odnieść je do książki „Sztuka testowania jednostkowego” - czy istnieje podobny zasób, do którego mogę się odwołać w tym temacie?
Niels Brinch,
1

Najważniejszą rzeczą, która pomoże ci tutaj, jest dobry podział problemów, aby w miarę możliwości jeden obszar kodu nie kolidował z innym.

Jest to miejsce, w którym bardzo pomocne jest zastosowanie wstrzykiwania zależności i programowania interfejsu, dzięki czemu można mieć bieżącą implementację ISupportingFeature na stronie, a następnie, gdy trzeba utworzyć INewFeature, która zależy od innej implementacji, można po prostu rozwinąć za pomocą nowe wdrożenie i utrzymywanie istniejącego w produkcji, dopóki nie zostanie dobrze przetestowane i gotowe do uruchomienia. Zakładając, że Twój DI pracuje nad jakimś systemem konfiguracyjnym, pozwoli ci to na równoległe używanie tego samego kodu w systemie i używanie stabilnego kodu przez cały czas.

W rzeczywistości takie podejście do konfiguracji jest opisane przez Martina Fowlera jako przełączanie funkcji.

Oczywiście, problem pojawia się tylko wtedy, gdy wdrażają wszystkie kodu wszystkim czasu. Jest to dokładnie taki scenariusz, dla którego zaprojektowano gałęzie funkcji i chociaż przyznam, że pan Fowler marszczy brwi, nie wiem, czy są one takie złe, szczególnie jeśli są tworzone i wykorzystywane w sposób zaplanowany i przemyślany. po drodze.

glenatron
źródło
Mam wrażenie, że przekazanie całego kodu do tego samego oddziału i wdrażanie całego kodu przez cały czas jest częścią dobrej strategii ciągłej integracji?
Niels Brinch,
Czytając więcej o ciągłej dostawie, z pewnością jest to częścią tego. Trochę się skrzywię na samą myśl o tym - czy chcesz wdrożyć częściowo napisany kod, nawet jeśli powinien zostać dezaktywowany? Może działa dobrze w scenariuszu, w którym bezpieczeństwo nie jest ważne, ale wydaje się, że jest to podejście wysokiego ryzyka dla wielu obszarów aplikacji. Prawdopodobnie oznacza to mnie jednak jako staromodnego, przytulałego, zboczonego faceta.
glenatron
Wydaje się, że istnieją dwie konkurencyjne strategie, w których jedna ma jedną gałąź główną, a druga gałąź dla każdego zadania i wiele połączeń ... Nie jestem pewien, co jest najlepsze, czy słuszne - ani czy trafia w sedno moich pytań.
Niels Brinch,
Myślę, że to zależy w dużej mierze od rodzaju rzeczy, które robisz - byłbym bardziej skłonny do odgałęzień, gdybym miał jakikolwiek priorytet w zakresie bezpieczeństwa i nie chciałbym ryzykować faktycznego wdrożenia nieprzetestowanego kodu w miejscu, w którym ktoś mógłby go znaleźć lub mógłby to być przypadek włączone. Więc gdybym prowadził witrynę bankową, nie sądzę, że CD byłaby czymś takim, ale może gdybym prowadził witrynę o wysokich obrotach dla zwykłych / okazjonalnych gości, może być idealna.
glenatron,