Jestem programistą w dość dużym, zwinnym zespole (mamy ośmiu programistów aktywnie wprowadzających zmiany w jednym repozytorium kodu). Co dwa tygodnie wprowadzamy nową wersję naszego oprogramowania do produkcji. Oto nasz obecny obieg pracy:
- Rozpoczynając nowe zadanie, programiści tworzą „gałąź funkcji” z głównej gałęzi programowania (korzystamy z git ) i pracujemy nad tą nową gałęzią
- Po zakończeniu pracy nad zadaniem programista ponownie łączy gałąź funkcji z gałęzią programowania
- Deweloper łączy gałąź programistyczną z gałąź kontroli jakości.
- Kompilacja jest uruchamiana z gałęzi kontroli jakości. Dane wyjściowe tej kompilacji są wdrażane w naszym środowisku kontroli jakości, aby umożliwić testerom rozpoczęcie testów.
Nasi testerzy często spotykają się z problemami związanymi z tymi nowymi funkcjami, które zostały włączone do działu kontroli jakości. Oznacza to, że w dowolnym momencie środowisko kontroli jakości prawdopodobnie zawiera kilka nowych funkcji - niektóre przetestowane i wolne od błędów, a niektóre uszkodzone. Utrudnia to wydanie, ponieważ rzadko zdarza się, że kompilacja kontroli jakości jest w stanie gotowym do produkcji.
Aby temu zaradzić, próbowaliśmy zainicjować „zamrożenie kontroli jakości”, co oznacza, że programiści nie łączą naszej gałęzi rozwoju z gałęzią kontroli jakości na kilka dni przed wydaniem. Poprawki błędów w środowisku kontroli jakości są wprowadzane bezpośrednio w gałęzi kontroli jakości i łączone z gałęzią programowania. Teoretycznie utrzymuje to nowe, zepsute funkcje poza QA, a jednocześnie pozwala nam naprawić problemy już w QA.
Chociaż ta koncepcja „zamrożenia kontroli jakości” okazała się częściowo skuteczna, trudno ją koordynować, a ludzie często są zdezorientowani, czy wolno im połączyć się z kontrolą jakości. Trudno było również ustalić termin „zamrożenia kontroli jakości” - wszystkim podoba się pomysł, aby między chwilą zawieszenia a wydaniem nieco odetchnąć, ale w praktyce wolą mieć swoją funkcję w następnym wydaniu niż dotrzymać terminu.
Czy istnieje lepszy sposób, aby zapewnić czystą wersję naszych wydań co drugi tydzień?
źródło
Odpowiedzi:
Jest w tym kilka problemów, które powodują problemy, które występują.
Pierwszym z nich jest długo działająca gałąź kontroli jakości. Posiadanie długo działającej gałęzi równoległej do głównej linii programistycznej może być źródłem zamieszania, ponieważ istnieją różne wysiłki, które należy powtórzyć zarówno w gałęzi QA, jak i głównej. Oznacza to, że albo sprawdzasz poprawki do gałęzi kontroli jakości, które muszą zostać scalone z linią główną (nie jest to zła rzecz), albo logujesz się do linii głównej, która zostaje scalona z gałęzią kontroli jakości (źródło możliwych błędów) .
Innym problemem związanym z długo działającą gałęzią równoległą jest to, że pliki mogą być wiecznie niezsynchronizowane. Poprawka kodu, która nigdy nie zostaje ponownie scalona, lub konfiguracja wymagana dla wersji produkcyjnych, która nigdy nie jest testowana i stanowi część głównej linii programistycznej.
Następnie masz role, które są utrudniane. Oznacza to, że rola pakowania (więcej na ten temat później) nie jest wystarczająco izolowana.
W modelu git-flow gałąź wydania jest rozgałęziona od fazy rozwoju ( nie rozwój scalony z kontrolą jakości), a wszystkie poprawki są sprawdzane w gałęzi wydania, a następnie ponownie łączone z odgałęzieniem rozwoju.
Część filozofii rozgałęziania można znaleźć w Zaawansowanych strategiach rozgałęziania SCM (uważam to za doskonałą lekturę). Koncentruje się na rolach, które może przyjąć każdy oddział. Gałąź wydania pełni rolę pakowania.
Należy poważnie rozważyć zastosowanie całości git-flow na miejscu. Nie jest to zbyt daleko od tego, co obecnie się robi i wprowadza dyscyplinę i spójność w to, co oznacza każda gałąź i jak każda gałąź współdziała z innymi.
źródło
Problem wydaje mi się, że masz jeden oddział kontroli jakości.
Dla każdej wersji utwórz oddzielną gałąź kontroli jakości od głównego magistrali programistycznej / głównej. Następnie łącz tylko poprawki dla funkcji w tej gałęzi - nigdy nowych funkcji. Niech QA przetestuje tę gałąź.
W ten sposób „zamrożenie” jest dość oczywiste - ma nazwę oddziału. Można użyć coś takiego, nie wiem,
release/26/10/2015
. To oczywiste, że po tym nikt nie powinien się łączyć z nowymi funkcjami.Jest to szczególnie pomocne, jeśli nie rozwidlisz gałęzi aż do zamrożenia. Ludzie mogą połączyć się w celu opanowania w dowolnym momencie, to po prostu nie będzie częścią tego wydania, jeśli nie zostanie zrobione na czas, aby go przetestować.
Nie posiadaj jednego oddziału QA działającego od dawna, który tylko prosi o kłopoty. Odejdź od głównego działu rozwoju dla każdego wydania i kontroli jakości tego oddziału.
źródło
Jesteś nieco odwzorowany na model rozgałęzienia Rozwój-GŁÓWNY-Produkcja przedstawiony poniżej. Obszar powyżej GŁÓWNY jest uważany za obszar rozwoju. Obszar poniżej GŁÓWNEJ to obszar produkcji.
Najważniejsze cechy tego modelu, który uważam za odpowiedni dla Ciebie:
Podejrzewam, że masz problemy, ponieważ:
źródło
Jak rozumiem pytanie, masz dwa problemy. (a) uszkodzone funkcje są łączone z dobrymi funkcjami, które chcesz wydać; (b) chcesz móc wypuszczać dobre funkcje, powstrzymując te uszkodzone. Jako ograniczenie możliwych rozwiązań zakładam, że chcesz, aby twoje ostateczne / oficjalne testy kontroli jakości odbywały się w zintegrowanym oddziale, który zawiera wszystkie funkcje przewidziane na następne wydanie.
Niezależnie od modelu rozgałęzienia SCM, sugeruję wypróbowanie jednego lub obu z poniższych:
źródło
Jednym z bardzo prostych rozwiązań, które widziałem w pracy w zespole nieco większym niż twój, jest umożliwienie wszystkim pracy i wdrażania z jednego oddziału.
Mówisz, że zespół jest zwinny, ale nie jest jasne, czy pracujesz w sprintach (np. Scrum), czy w podejściu bardziej ciągłym (np. Kanban). Zakładając, że wykonujesz sprinty, celem zespołu jest udostępnienie kodu na końcu każdego sprintu w celu wydania go co dwa tygodnie. Nie ma wątpliwości, czy jedna cecha złamie inną, ponieważ wszystkie zostały opracowane razem. Testerzy mogą uzyskać dostęp do funkcji w mniejszych porcjach, ponieważ obciążenie programistów związane z dostarczaniem do nich jest niższe. I tak naprawdę nie potrzebujesz Zamrożenia QA, zamiast tego wszyscy wiedzą, kiedy koniec sprintu jest i nie powinni podejmować pracy, której nie mogą ukończyć lub pozostawić w stanie możliwym do wdrożenia (tzn. Wyłączonym).
Oczywiście w każdym podejściu są zalety i wady, przedstawiam to jako opcję niekoniecznie najlepszą.
źródło
Powodem, dla którego występują te problemy, jest to, że kod wydany do kontroli jakości nie jest wystarczająco dobrej jakości (i czy są jakieś ?!), więc musisz zacząć otrzymywać lepszą wersję kontroli jakości, aby nie musieli tak często otrzymywać poprawek. najprostszym sposobem na to jest wprowadzenie gałęzi pośredniczącej, do której zwalniasz (nazwijmy to testem). Nadal jest to w gestii programistów, ale pozwala programistom naciskać na to, aby kontynuować pracę, a jednocześnie ma zintegrowaną gałąź, która powinna być wystarczająco dobrej jakości, aby mogła zostać wysłana do kontroli jakości.
Testy integracyjne mogą odbywać się w tej gałęzi w celu znalezienia błędów, które QA aktualnie znajdują, błędy można naprawić w oryginalnej gałęzi, a następnie scalić ponownie, i jeszcze raz, aż do momentu usunięcia błędów bezpośrednio w tej gałęzi (polecam były). Po przejściu wielu podstawowych testów można go wysłać do działu kontroli jakości w celu „zablokowania palców użytkownika i zrobienia co?” testowanie.
To podejście ma na celu ochronę gałęzi kontroli jakości przed uszkodzonymi funkcjami programistycznymi - niezależnie od tego, czy funkcja nie była wystarczająco dobrze zakodowana, czy też nieoczekiwane problemy z integracją. Tylko oddziały deweloperów, które przejdą testy integracyjne, zostaną awansowane do kontroli jakości.
źródło