Jak możemy dołączać funkcje gotowe do wydania w naszych wydaniach produkcyjnych co drugi tydzień?

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ń?

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.

Rola pakowania jest często mylona z kumulacją lub, częściej, z rolami głównymi. Po wykonaniu zamierzonego rozwoju i konserwacji oraz dokonaniu akumulacji nadszedł czas na przygotowanie kodu do wydania. Taki wysiłek może nie być trywialny, wymagając zespołu inżynierów wydania i dodatkowych poprawek poza tymi już wykonanymi. Polityka w branży opakowań znacznie różni się od polityki w branży konserwacji, jak sugeruje rola pakowania, należy uwzględnić tylko zmiany niezbędne do udostępnienia produktu.

• Rozgałęzienie od punktu rozwoju do gałęzi wydania. Gałąź wydania, z której buduje QA, otrzymuje jeden oddział i nie łączy się z programowaniem.
  • Jeśli chcesz iść tą drogą, ze spójnymi nazwami i hakami, możesz zapobiec scaleniu z gałęzią wydania.
• Napraw wszystko, co należy naprawić w gałęzi wydania i połącz te zmiany z powrotem do głównej linii.
• Pod koniec procesu wydawania scal scal gałąź wydania z gałęzią „releases go here” i oznacz ją jako taką.
  • Niektóre witryny nie mają gałęzi „releases go here” i pozostawiają koniec gałęzi wydania zwisający z tagiem.

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.

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.

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:

• Twoi deweloperzy muszą często integrować (FI) (FI = łączenie z MAIN) często (2-3 razy w tygodniu) w swoich oddziałach DEV, aby ich najnowsze zmiany zawsze uwzględniały najnowsze zmiany.
• Twoi deweloperzy muszą dokonać odwrotnej integracji (RI) (RI = scalanie w kierunku GŁÓWNEJ) w gałęzi TEST tylko wtedy, gdy osiągną kamień milowy ukończenia funkcji, który chcą wystawić na kontrolę jakości i dla których są gotowi dostarczyć natychmiastowe poprawki odpowiedź na informacje zwrotne dotyczące kontroli jakości. Poprawki zostaną wykonane w gałęzi TEST i natychmiast FI w ich gałęzi DEV.
• Nigdy nie RI z żadnego oddziału DEV do MAIN
• Zawsze RI z gałęzi TEST do GŁÓWNEJ, wyłącznie gdy twój QA uzna, że ​​jakość TESTU jest OK. Utrzymuj wysoki próg jakości dla połączenia w MAIN. Przynajmniej menedżer produktu musi być w stanie zawsze demonstrować działającą wersję produktu z najnowszego zatwierdzenia w MAIN.
• Utwórz oddziały w obszarze produkcyjnym tylko w razie potrzeby. Serwer kompilacji powinien zawsze oznaczać wszystkie gałęzie, w tym te z obszaru programowania, a źródło każdej kompilacji / wydania powinno być możliwe do zidentyfikowania przez cały czas, niezależnie od gałęzi, z której pochodzi.
• Wydawaj materiały do ​​produkcji tylko z GŁÓWNEJ lub z obszaru produkcyjnego. Jeśli później musisz podać poprawkę dla dokładnie wydanej wersji (tzn. Nie możesz po prostu podać najnowszej wersji z GŁÓWNEJ), utwórz gałąź w obszarze produkcyjnym na podstawie znacznika GŁÓWNEGO wadliwego wydania, kiedy taka poprawka jest potrzebna. Zawsze napraw problem w gałęzi HotFix, a następnie natychmiast RI w MAIN i FI w TEST.

Podejrzewam, że masz problemy, ponieważ:

• Twój deweloper RI do kodu TEST, który nie jest ukończony kamień milowy funkcji
• Twoi twórcy RI w TEST bez uzyskania zielonego światła z QA (tzn. QA nie kontroluje tego, co zostanie wstrzyknięte do TESTU)
• Kiedy QA zgłasza błąd w TESTIE, twoi deweloperzy naprawiają go w swoim oddziale DEV, a następnie RI do TESTU. Jest to poważna zła praktyka, ponieważ połączenie zawsze przyniesie inne niekompletne badziewia. Powinni zawsze naprawić to na TESTIE, a następnie FI w swoim oddziale DEV. Jeśli nie da się tego naprawić w TESTIE, to przede wszystkim dostarczyły bzdury i masz większe problemy.
• Twoi deweloperzy nie często FI z TESTU, więc destabilizują TEST, ilekroć tam dostarczą. Równie dobrze jest balansować sztuką, jak często FI do DEV. Odłóż to zbyt długo, a będzie to bardzo kosztowne i ryzykowne tuż przed dostawą, czego nigdy nie chcesz. Rób to zbyt często, a nie wykonasz żadnej pracy deweloperskiej, jeśli w międzyczasie zbytnio nakładasz się z pracą dostarczoną przez inne osoby w TESTIE.

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:

1. Przypisz zasób kontroli jakości do każdego zespołu funkcji. Poproś, aby przeprowadzili pewne testy funkcji dla kompilacji z gałęzi funkcji i dali im uprawnienia do decydowania, kiedy funkcja jest wystarczająco dobra do scalenia. Idealnie byłoby, gdyby współpracowali z resztą zespołu, więc rzeczy są testowane wkrótce po napisaniu. (Uwaga: nie oznacza to, że muszą przeprowadzić wszystkie testy samodzielnie).
2. Użyj przełączników funkcji, zamiast gałęzi funkcji lub oprócz nich. Wykonane w prawo, przełączniki funkcji pozwalają wyłączyć zepsutą funkcję bez próby odłączenia jej od kodu, dzięki czemu można przetestować i zwolnić inne funkcje. Tego rodzaju przełączniki, o których mówię, nie są dostępne dla klientów; nie chcesz testować wykładniczo rosnącej liczby kombinacji. Ustawiasz przełączniki w gałęzi kontroli jakości, aby pasowały do ​​funkcji, które planujesz wydać, a jeśli plan zmieni się, ponieważ funkcja nie jest gotowa, zmienisz to przełączenie.

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ą.

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.