Zaczynamy napotykać problem, gdy stajemy się coraz więksi, gdy funkcje przechodzą do testowania, ale zanim wszystko zostanie przetestowane i zatwierdzone nowe funkcje będą testowane.

Tworzy to środowisko, w którym prawie nigdy nie możemy naciskać na produkcję, ponieważ mamy połączenie przetestowanych i niesprawdzonych funkcji. Jestem pewien, że jest to częsty problem, ale nie znalazłem jeszcze żadnych dobrych zasobów dla nas.

Niektóre szczegóły:

• GIT na BitBucket
• Jenkins do wdrożenia skryptowego na platformie Azure

Mam nadzieję na sposób na wyodrębnienie funkcji, gdy poruszają się one w różnych środowiskach i wypychają tylko to, co jest gotowe.

Wygląda na to, że masz tutaj kilka problemów:

1. Identyfikowanie funkcji dla konkretnego wydania

Jest to kwestia zarządzania projektem i kwestia koordynacji. Czy ta funkcja zostanie wydana przed, w tym samym czasie lub po tej innej funkcji? Jeśli wydania mają się pojawiać po jednej funkcji na raz, należy to zidentyfikować. Jeśli funkcje będą grupowane w wydaniach, a następnie dowiedzieć się, jakie grupy są i egzekwować je deweloperów i decydentów. Użyj systemu śledzenia problemów lub systemu biletowego, aby oznaczyć wydania. Wyjaśnij, że jeśli jedna funkcja określonego wydania jest nie do przyjęcia, to wszystkie są.

2. Strategie rozgałęziania

Git-flow jest łatwą odpowiedzią na takie problemy i często ludzie używają wariantu git-flow, nawet jeśli nie wiedzą, co to jest. Nie powiem, że to wszystko dla wszystkich problemów, ale bardzo pomaga.

Wygląda na to, że napotykasz problem z niedeterministycznymi strategiami wydawania, w których funkcje są zatwierdzone jako rozproszone, a coś, co zaczęło się rozwijać dawno temu, może zostać wydane po czymś, co zaczęło się ostatnio - funkcjach skokowych.

Długotrwałe gałęzie funkcji lub gałęzie z jednoczesnym wydaniem są prawdopodobnie najlepszą odpowiedzią na tego rodzaju problemy. Scal (lub rebase, jeśli czujesz się z tym komfortowo) najnowsze od mistrza do długoterminowych oddziałów. Uważaj, aby scalić tylko funkcje, które są już aktywne, w przeciwnym razie napotkasz problemy, które masz teraz (zbyt wiele pomieszanych funkcji w jednym oddziale).

Istotną częścią tego procesu są gałęzie „poprawki” lub „poprawki błędów”; używaj ich do małych jednorazowych poprawek, które mają krótki cykl kontroli jakości.

Z twojego opisu może być nawet lepiej nie utrzymywać oficjalnej gałęzi „rozwoju”. Zamiast tego należy rozgałęzić wszystkie funkcje z poziomu głównego i utworzyć połączone wersje wydań po zidentyfikowaniu wydania.

3. Środowiska

Nie dopasowuj gałęzi git do swoich środowisk, z wyjątkiem produkcji == master. Oddział „rozwoju” należy uznać za zepsuty. Rozgałęzienia wersji są wypychane w celu przetestowania środowisk, niezależnie od tego, czy jest to środowisko kontroli jakości czy środowisko przejściowe. W razie potrzeby wypchnij określoną gałąź funkcji do środowiska.

Jeśli masz więcej niż jedną gałąź funkcji, które muszą zostać wydane osobno, ale są testowane w tym samym czasie ..... ¯ \ _ (¯) _ / ¯ .... podkręcić inny serwer? Być może połączymy je razem w gałąź odrzucania ... zatwierdzaj poprawki / zmiany w oryginalnych gałęziach i ponownie scalaj w gałąź odrzucania; dokonać ostatecznego zatwierdzenia i UAT w poszczególnych oddziałach wydania.

4. Usuwanie niezatwierdzonych funkcji z oddziału

Właśnie tego starają się unikać powyższe myśli, ponieważ jest to bez wątpienia najbardziej bolesna rzecz do zrobienia. Jeśli masz szczęście, funkcje zostały scalone z Twoimi programistami lub przetestuj gałęzie atomowo za pomocą zatwierdzeń scalania. Jeśli masz pecha, deweloperzy zaangażowali się bezpośrednio w dział rozwoju / testowania.

Tak czy inaczej, jeśli przygotowujesz się do wydania i masz niezatwierdzone zmiany, musisz użyć Git, aby wycofać te niezatwierdzone zatwierdzenia z gałęzi wydania; najlepszym pomysłem jest zrobienie tego przed przetestowaniem wydania.

Powodzenia.

Oto pomysł: Przestań używać gałęzi wydania. Zamiast tego zacznij budować przełączniki funkcji i zarządzaj nimi poprzez konfigurację. W ten sposób zawsze łączysz gałęzie funkcji w master i nigdy nie powinno być pytania o to, która wersja jest testowana lub produkowana. Jeśli masz pytanie o to, jakie funkcje / implementacje są aktywne w środowisku, po prostu sprawdź plik konfiguracyjny.

Powinna to być prosta kwestia koordynacji między testem a produkcją. Jeśli używasz gałęzi funkcji w Git, po prostu przestań wypychać ukończone gałęzie funkcji do Testowania podczas cyklu testowania i wznawiaj po zakończeniu testowania.

Jeśli potrzebujesz lepszej kontroli, rozdziel Test na serwer programistyczny i serwer Testów Akceptacyjnych i koordynuj te gałęzie, które zostaną przekazane na serwer Testów Akceptacyjnych z zespołem testującym. Ktoś może wtedy być odpowiedzialny za rozpoczęcie ostatecznego wdrożenia od testu akceptacyjnego do produkcji.

Praca się piętrzy

Jest to uniwersalny problem z mojego doświadczenia. Adresuję to za pomocą:

• Silne zarządzanie wydaniami funkcji przez właściciela produktu
• Upewnij się, że gałęzie są usuwane po scaleniu
• Ogranicz prace w toku (z limitami kolumn w Jira)
• Kwartalna recenzja starych, marnych biletów, zarówno błędów, jak i funkcji
• Retrospektywy w celu omówienia składników problemu
• Stała zachęta do recenzji kodu przez wszystkich
• Możliwości parowania w celu rozwiązania problemu długotrwałych biletów i problemów
• Kwartalne spotkania w celu przeglądu i czyszczenia starych biletów
• Podejście zespołowe do ścisłej współpracy deweloperów, produktów i kontroli jakości / kontroli jakości
• Dobre raportowanie i narzędzia, dzięki którym nowe funkcje produktu i zaległości będą oczywiste
• Przejrzyj sesje, aby przejrzeć stare gałęzie i je usunąć

Gałęzie

Potrzebujesz kilku oddziałów, aby kontrolować ten proces:

• cecha : te gałęzie rodzą się z mistrza. Użyj aplikacji do zarządzania projektami, aby zidentyfikować każdą gałąź funkcji z jakimś zadaniem. Na przykład, jeśli używasz TRAC, skończy czy branże takie jak: 1234-user-crud, 1235-bug-delete-catalogitp Zidentyfikuj swoje rewizje z liczbą zadań zbyt, to będzie Ci dużo, gdy masz problemy w scala (trzeba będzie).
• test : wszystkie wykonane gałęzie funkcji zostaną scalone z gałęzią testową. Nigdy nie łączysz gałęzi testowej z jakąś gałęzią funkcji , ponieważ nie chcesz kodu z innych funkcji, których nie ma w produkcji (master). To samo dotyczy releaseoddziału.
• wydanie : kiedy decydujesz, jakie testowane funkcje mogą znajdować się w produkcji, scalasz te gałęzie (ponownie ...) w tej gałęzi. Musisz ponownie przetestować wszystkie funkcje, ponieważ to scalenie może przynieść nowe problemy. Po przetestowaniu i zakończeniu wydania scalasz tę gałąź w master i tworzysz tag w master dla wersji.
• master : zawiera tylko kod produkcyjny.

Zobacz przepływ git:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

Środowiska

Bardzo prosty:

• test : to środowisko używa gałęzi testowej.
• release : to środowisko używa rzeczywistej gałęzi wydania.

Programiści pracują na jego komputerze, każdy korzysta z własnej bazy danych. Jeśli nie jest to możliwe, każdy programista ma indywidualną bazę danych (z powodu licencji, wielkości bazy danych itp.), Będziesz mieć wiele problemów z udostępnianiem bazy danych między programistami: kiedy ktoś usunie kolumnę lub tabelę w swojej gałęzi, inni gałęzie nadal liczą się z tą kolumną / tabelą w bazie danych.

Problemy

Największym problemem w tym procesie są fuzje.

Musisz przerobić te same połączenia w testi release. Będzie to bolesne, jeśli w kodzie zostaną wykonane pewne dobre refaktory, takie jak usunięcie klasy, przeniesienie / zmiana nazwy itp. Ponieważ nie można uzyskać kodu z gałęzi test(lub release) do gałęzi funkcji, zatwierdzenia scalania można rozwiązać tylko w test(a release). W rezultacie rozwiązujesz te same konflikty w dwóch różnych gałęziach, prawdopodobnie produkując inny kod w każdym połączeniu, a w przyszłości odkryjesz, że zespół testowy będzie musiał przetestować funkcje dwa razy: w oddziałach testi release, ponieważ każde połączenie może powodować różne błędy.

Kolejnym problemem jest testoddział. masterOd czasu do czasu trzeba będzie „poddać recyklingowi” tę gałąź (usuwać i tworzyć nową ), ponieważ niektóre stare gałęzie (lub stare scalenia, scalone gałęzie, które zostały usunięte) mogą powodować wiele problemów dla nowego kodu, znacznie odbiegając od tego, co jest w środku master. W tym momencie potrzebujesz kontroli nad tym, jakie gałęzie chcesz scalić ponownie w test.

Naprawdę najlepszym rozwiązaniem jest to, że zespół biznesowy wie, co należy dostarczyć w następnej wersji, a wszyscy pracują w unikalnym oddziale (rozwój oddziału). To dla nich dobra możliwość wyboru funkcji „zrobione”, którą chcieliby być w następnej wersji, kiedy tylko chcą (myślę, że to twój scenariusz), ale jest to koszmar dla programistów i (uważam) dla zespół testowy.

Wygląda na to są scalanie zmian z oddziału integracyjnego w swoim oddziale produkcyjnym, które IMHO nie jest to dobra praktyka, właśnie z powodów można wymienić. Gdy tylko gałąź produkcyjna dla określonej wersji zostanie pobrana z głównej gałęzi integracji, gałąź integracji może w dowolnym momencie się rozejść (w końcu ma ewoluować do następnej wersji). Scalenie z gałęzi integracji do gałęzi bieżącej wersji może spowodować zmiany niezgodne z tą wersją.

IMHO właściwym procesem byłoby:

• ściągnij gałąź produkcyjną z gałęzi integracji tylko wtedy, gdy zostanie ona uznana za wystarczająco zbliżoną do pożądanego poziomu jakości, tak że do końca wydania można oczekiwać jedynie garstki zmian. Innymi słowy, ukończenie funkcji powinno być oceniane (w sposób ciągły) w gałęzi integracji, przed odciągnięciem gałęzi produkcji.
• po wyciągnięciu gałęzi produkcyjnej są do niej wprowadzane tylko wybrane zmiany, traktowane jako samodzielne / punktowe - tzn. sprawdzone, czy faktycznie działają zgodnie z oczekiwaniami (tylko dlatego, że zmiana działa w jednej gałęzi, niekoniecznie oznacza, że ​​ona również działa w innym oddziale).

Osobiście wydaje się, że może to być bardziej problem z procesem niż problem z narzędziami. Kilka rzeczy, które zasugeruję tutaj:

• Nie jestem pewien, czy masz oddzielne grupy deweloperów i QA. Jeśli to zrobisz, upewnij się, że zarówno Dev, jak i QA uczestniczą w spotkaniach planowania i szacowania sprintu. W jednej z moich poprzednich firm upewniliśmy się, że liczba punktów opowieści, które przypisaliśmy, stanowiła zarówno wysiłek rozwojowy, jak i testowy. (Teoretycznie możesz również mieć dwa osobne szacunki dotyczące wysiłków deweloperów i kontroli jakości, ale w obu przypadkach musisz uwzględnić oba te szacunki; czas potrzebny na opowieść to czas potrzebny na jej dostarczenie). Nawet jeśli nie masz osobnej grupy ds. Kontroli jakości, upewnij się, że uwzględnisz wysiłki związane z testowaniem w swoich szacunkach.
• W podobny sposób jak powyżej, z góry uzgodnij, ile historii zamierzasz uwzględnić w danym sprincie. Liczba punktów fabularnych, które akceptujesz, zależy od ilości, którą twoi programiści mogą ukończyć w sprincie i liczby przedmiotów, które QA może przetestować w sprincie. (Zakładam oczywiście, że sprinty kontroli jakości są za sprintami deweloperów, ale możesz to dostosować do swojego procesu). Jeśli twoi programiści mogą ukończyć 200 punktów opowieści, ale twoja kontrola jakości może ukończyć tylko 150 punktów opowieści, oczywiście możesz zrobić tylko 150 punktów opowieści, zanim praca zacznie się „gromadzić” i skończysz z przypadkiem podobnym do tego, co opisujesz. (W takim przypadku możesz sprawdzić przyczynę blokady, aby spróbować ją złagodzić).
• Nikt nie wypycha niczego do kontroli jakości, dopóki wszystko, co jest obecnie w kontroli jakości, nie zostanie przetestowane i dostarczone .
• Kompletna funkcja to jedna z rzeczy, które zostały przetestowane i dostarczone. Jeśli nie zostanie dostarczony, nie zostanie zrobiony.
• Oczywiście chcesz to zrobić zgodnie z ustalonym harmonogramem. Jednym z pomysłów ciągłej integracji i zwinności jest iteracja. Z definicji iteracja wymaga częstej dostawy. Częste integracje i dostarczanie minimalizują ryzyko każdego z nich.

Szczerze mówiąc, myślę, że największą rzeczą będzie dyscyplina podczas dostarczania i liczby zadań, które możesz faktycznie ukończyć w danym czasie.

Podsumowując: dostarczaj do kontroli jakości dopiero po zakończeniu testowania i dostarczania starych funkcji.

Kiedy „wszystko jest testowane i zatwierdzane”, wdrażaj to, co zostało przetestowane i zatwierdzone do produkcji. To może być konkretny zatwierdzenie lub konkretny artefakt kompilacji wygenerowany przez Jenkinsa.

Nie powinno mieć znaczenia, że ​​później zatwierdzenia dla tej samej gałęzi nie są jeszcze testowane.