Programiści zablokowani przez czekanie na kod do połączenia z innego oddziału za pomocą GitFlow


17

Nasz zespół właśnie przeszedł z FogBugz & Kiln / Mercurial na Jira & Stash / Git. Do rozgałęziania używamy modelu Git Flow, dodając gałęzie podzadania z gałęzi elementów (odnoszące się do podzadań Jira elementów Jira). Używamy Skrytki do przypisania recenzenta, gdy tworzymy żądanie ściągnięcia, aby ponownie połączyć się z gałęzią nadrzędną (zwykle programuje, ale podzadania z powrotem do gałęzi funkcji).

Problem, który znajdujemy, polega na tym, że nawet przy najlepszym planowaniu i rozbiciu przypadków funkcji, gdy wielu programistów pracuje razem nad tą samą funkcją, powiedzmy na front-end i back-end, jeśli pracują na współzależnym kodzie, który jest w oddzielnych gałęziach jeden programista blokuje drugi.

W miarę rozwoju próbowaliśmy się przenosić między gałęziami. Próbowaliśmy także utworzyć lokalne oddziały integracji, z których każdy programista może pobrać wiele oddziałów, aby przetestować integrację podczas ich rozwoju. Wreszcie, i wydaje się, że do tej pory działało to najlepiej dla nas, chociaż przy nieco większym obciążeniu, próbowaliśmy utworzyć gałąź integracji z gałęzi funkcji od samego początku. Gdy gałąź podzadania (poza gałęzią funkcji) jest gotowa na żądanie ściągnięcia i przegląd kodu, również ręcznie scalamy te zestawy zmian w tej gałęzi integracji funkcji. Wówczas wszyscy zainteresowani programiści mogą przenieść się z tej gałęzi integracji do innych zależnych gałęzi podzadań. Zapobiega to oczekiwaniu na oddział, od którego zależy przejście przeglądu kodu.

Wiem, że niekoniecznie jest to problem z Gitem - dotyczy pracy nad współzależnym kodem w wielu gałęziach, w połączeniu z naszym własnym procesem pracy i kulturą. Gdybyśmy nie mieli ścisłych zasad sprawdzania kodu dla developerów (prawdziwa gałąź integracji), wówczas programista 1 mógłby połączyć się z programistą, aby programista 2 mógł z niego skorzystać. Inną komplikacją jest to, że musimy również przeprowadzić wstępne testy w ramach procesu przeglądu kodu przed przekazaniem funkcji do QA. Oznacza to, że nawet jeśli programista front-end 1 pobiera bezpośrednio z gałęzi programisty back-end 2, ponieważ idź, jeśli programista zaplecza 2 zakończy pracę i jego żądanie ściągnięcia siedzi przez tydzień na sprawdzaniu kodu, wówczas programista frontonu 2 technicznie nie może utworzyć swojego żądania ściągnięcia / recenzji kodu, ponieważ jego / jej recenzent kodu nie może test, ponieważ back-end developer 2 '

Najważniejsze jest to, że w tym przypadku znajdujemy się w dużo bardziej szeregowym niż równoległym podejściu, w zależności od tego, którą drogą wybieramy, i chcielibyśmy znaleźć proces, którego można by tego uniknąć.

Ostatnią rzeczą, o której wspomnę, jest to, że zdajemy sobie sprawę z dzielenia się kodem między gałęziami, które nie zostały jeszcze sprawdzone i sfinalizowane, ale w zasadzie używamy kodu beta innych. Do pewnego stopnia nie sądzę, że możemy tego uniknąć i jesteśmy skłonni zaakceptować to do pewnego stopnia.


Tylko weryfikacja - przegląd kodu jest wykonywany podczas scalania zadania z funkcją? i nie ma recenzji kodu do scalania funkcji do opracowania?

To zależy. Mamy ogólną zasadę, że żaden przypadek Jira, który odpowiada gałęzi, w której bezpośrednio sprawdzamy kod, i który nie działa jako przypadek „parasolowy” w sensie hierarchicznym, nie trwa dłużej niż 2 dni. Jeśli więc przypadek funkcji zajmie <= 2 dni, nastąpi przegląd kodu w celu scalenia funkcji do opracowania. Jeśli są podzadania, gdy wszystkie zostaną scalone w bilet funkcji, ktoś śpieszy z prośbą o ściągnięcie w celu scalenia gałęzi funkcji w celu opracowania, ale nie na tym samym poziomie przeglądu kodu, ponieważ wszystkie podzadania przeszły już ten proces.
fogwolf

Odpowiedzi:


11

Problem może również polegać na zbyt sztywnym rozdzieleniu zadań między rozwojem zaplecza a frontonu.

Jeśli programista front-end potrzebuje nowego interfejsu API, czy nie jest możliwe zezwolenie mu na utworzenie fałszywego interfejsu API na zapleczu (zwracając zawsze tę samą wartość), aby sprawdzić poprawność układu? Następnie zatwierdź tę częściową implementację za pomocą kodu pośredniczącego, a po raz drugi programista back-end zaimplementuje prawdziwą funkcję.

Przełamując zależność, uzyskasz lepszy przepływ i nie będziesz musiał zatrzymywać wszystkiego, czekając na jedno zadanie, które działa jak wąskie gardło.


Zastanawiałem się nad tym, ale nie jest to część naszego obecnego procesu rozwoju i wiąże się z dodatkowymi kosztami. Nie sądzę jednak, aby problem polegał na tym, że programista front-end nie był w stanie uzyskać dostępu do kodu programisty back-end w celu przetestowania podczas programowania. Chodzi raczej o to, aby recenzenci kodu przeprowadzili test dymny całej integracji (nic nie wyszydzali ani nie zgubili) przed wysłaniem go do kontroli jakości.
fogwolf

6
Chociaż nie jest to częścią twojego procesu programistycznego, czy jest to dodatkowy narzut niż na to, że dwóch programistów kręci kciukami przez trzy dni, czekając na kogoś innego, aby zatwierdzić swój kod? Masz 8 godzin zmarnowanego czasu programisty na kciuk twiddler. Porównaj to do czasu, jaki zajmuje wytarcie zależności zaplecza.
Greg Burghardt

5

Twój problem: Deweloper A oddziału Master, deweloper B oddziału Master, oba działają na ściśle powiązanych funkcjach, a nieunikniony jest fakt, że połączenia z gałęzią Master są trudne z powodu nieuniknionych konfliktów, co powstrzymuje wszystkich.

Jeśli jest to do przewidzenia, to A i B mogą najpierw utworzyć wspólny oddział, a następnie każdy oddział dla swojej oddzielnej pracy od tego wspólnego działu, scalić każdą swoją oddzielną pracę we wspólną gałąź, a teraz masz gałąź wolną od konfliktów, która jest znacznie łatwiejsze do zintegrowania.


0

Jeśli programista 1 pracuje nad funkcją A, a programista 2 zakończył pracę nad funkcją B, która zależy od funkcji A, nie ma możliwości obejścia tego - scalanie funkcji B jest wstrzymane. Nie można go przetestować bez funkcji A, a przeglądanie go nie ma sensu, ponieważ dalszy postęp w funkcji A może prowadzić do zmian w funkcji B.

Nie oznacza to jednak, że deweloper 2 jest wstrzymany! Deweloper 2 może rozpocząć pracę nad funkcją C i powrócić do cyklu poprawiania funkcji B po zakończeniu funkcji A. Wiem, że przełączanie kontekstu nie jest optymalne, ale ponieważ czas potrzebny na ukończenie funkcji A jest prawdopodobnie mierzony w dniach, nie jest tak źle (nie wyciągasz ich z „Strefy” na 15 minutowe zadanie poboczne)


Jasne, ale to nie jest problem. W przypadku pojedynczej funkcji chodzi bardziej o proces serializacji, niż musi być. Jeśli planujemy wydać funkcję w dniu x, a biletów nie będziemy mogli przejrzeć równolegle, powoduje to, że nasze prognozy są wyłączone i potencjalnie wypychamy tę wersję.
fogwolf

0

Jedną z rzeczy, które możesz zrobić, aby pomóc w tej sytuacji, jest przyjrzenie się sposobom skrócenia cyklu rozwoju.

Czy w przypadku, gdy programista czeka na funkcję od innego programisty, czy część pierwszych prac programistów może przejść przegląd i integrację przed całą funkcją, aby zwolnić blok?

Czy istnieją sposoby na podzielenie funkcji na mniejsze jednostki pracy, aby utrzymać cykl integracji?

Jak długo trwa integracja? Długa zmiana kompilacji lub integracji może spowolnić całą kolejkę. Sprawdź, czy jest coś, co możesz zrobić, aby przyspieszyć czas kompilacji, aby kolejki były zwalniane szybciej.


Oto moje główne nadzieje. Nie sądzę, że możemy rozwiązać ten problem, ale dzięki poprawie komfortu pracy z nowym przepływem pracy mam nadzieję, że będziemy w stanie lepiej planować i dzielić pracę w ramach tego nowego systemu, aby zminimalizować problem. Sprawdzałem tylko, czy ktoś wpadł na coś podobnego i czy miał coś procesowego lub związanego z modelem rozgałęziającym, którego używamy, co mogłoby pomóc. Dzięki.
fogwolf
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.