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.
Odpowiedzi:
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.
źródło
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.
źródło
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)
źródło
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.
źródło