Wskazówki dotyczące osiągnięcia ciągłej dostawy

Zespół ma trudności z częstym wypuszczaniem oprogramowania (raz w tygodniu). Poniżej przedstawiono typową oś czasu wydania:

Podczas iteracji:

• Programiści pracują nad historiami zaległości w krótkotrwałych (jest to entuzjastycznie egzekwowane) gałęziach funkcji opartych na gałęzi master.
• Programiści często wciągają swoje gałęzie funkcji do gałęzi integracji, która jest stale budowana i testowana (w miarę zasięgu testu) automatycznie.
• Testerzy mają możliwość automatycznego wdrażania integracji w środowisku testowym, co odbywa się wiele razy w tygodniu, co umożliwia ciągłe uruchamianie ich zestawów testowych.

Każdy poniedziałek:

• odbywa się spotkanie poświęcone planowaniu wydania w celu ustalenia, które historie są „dobrze znane” (na podstawie pracy testerów), a zatem będą w wydaniu. Jeśli występuje znany problem z historią, gałąź źródłowa jest wycofywana z integracji.
• żaden nowy kod (tylko poprawki błędów wymagane przez testerów) nie może zostać włączony do integracji w ten poniedziałek, aby zapewnić testerom stabilną bazę kodu, z której można wyciąć wydanie.

Każdego wtorku:

• Testerzy przetestowali gałąź integracji tak długo, jak to możliwe, i poświęcili dostępny czas. Nie ma znanych błędów, więc wydanie jest wycinane i powoli wypychane do węzłów produkcyjnych.

W praktyce brzmi to OK, ale stwierdziliśmy, że jest to niezwykle trudne do osiągnięcia. Zespół widzi następujące objawy

• „subtelne” błędy występują podczas produkcji, które nie zostały zidentyfikowane w środowisku testowym.
• poprawki w ostatniej chwili trwają do wtorku.
• problemy w środowisku produkcyjnym wymagają wycofania, które blokuje dalszy rozwój, aż do pomyślnego wdrożenia na żywo, a gałąź główna może zostać zaktualizowana (a więc rozgałęziona).

Wydaje mi się, że w grę wchodzą testy, jakość kodu, możliwość szybkiego testowania regresji, zmiany w ostatniej chwili i różnice środowiskowe. Czy ktoś może zaoferować jakąkolwiek radę dotyczącą tego, jak najlepiej osiągnąć „ciągłą” dostawę?

• „subtelne” błędy występują podczas produkcji, które nie zostały zidentyfikowane w środowisku testowym - w jednym z projektów z takimi problemami, które widziałem, całkiem skutecznie rozwiązano taktyką, którą nazwałbym podwójnymi problemami. Mam na myśli takie błędy, faceci stworzyli dwa zgłoszenia w module do śledzenia problemów: jeden został przydzielony programistom do naprawy kodu, drugi do testerów w celu zaprojektowania i ustanowienia testu regresji lub zmiany środowiska testowego, które uniemożliwiłyby powtórzenie go w przyszłości. To pomogło utrzymać scenę na tyle blisko, by ją szturchać.

• problemy w środowisku produkcyjnym wymagają wycofania - jeśli są one częste, to twoje cotygodniowe wydania są w rzeczywistości fałszywe - rozważ dostosowanie częstotliwości do poziomu, który naprawdę działa. Przez fałszywe rozumiem, że powiedzmy, że jeden z dwóch wycofywanych co tydzień wydań oznacza, że ​​użytkownicy spotykają się z nowym (działającym) wydaniem raz na dwa tygodnie - to wszystko się liczy, a nie liczba wdrożeń.

• entuzjastycznie egzekwowane gałęzie funkcji - czy to oznacza, że ​​jakiś czas temu próbowałeś również pracować nad jednym oddziałem i uważałeś go za gorszy? Jeśli tak, pomiń resztę. W przeciwnym razie spróbuj pracować nad pojedynczym oddziałem (w razie potrzeby przejdź do Google dla strategii rozgałęziania „gałąź rozwoju” lub strategii rozgałęziania „niestabilny pień”, aby uzyskać szczegółowe informacje). Lub, jeśli korzystasz z Perforce, poszukaj w Internecie wskazówek Microsoft dotyczących rozgałęziania i łączenia. Próbowałem to powiedzieć? przepraszam, należy przetestować odpowiednie słowo : 1) zaplanuj, kiedy i jak zmierzyć, czy pojedyncza gałąź jest lepsza, czy nie niż ta, którą masz teraz, i 2) zaplanuj, kiedy i jak wrócisz do gałęzi funkcji w przypadku, gdy to testowanie kończy się niepowodzeniem .

PS.

Prawdopodobnie możesz znaleźć więcej takich sztuczek, przeszukując sieć w poszukiwaniu zarządzania ryzykiem związanym z projektami

aktualizacja

<skopiuj z komentarzy>

Uważam, że częste poprawki są objawem zepsutego rurociągu testowego - czy tak nie jest? Tak czy inaczej, wymagają powtarzających się wydań, aby wydać poprawki, dzięki czemu zespół operacyjny będzie miał więcej pracy. Ponadto poprawki są zwykle kodowane pod ekstremalną presją czasu, co oznacza, że ​​będą prawdopodobnie gorszej jakości niż normalna praca.

</ kopiuj z komentarzy>

• poprawki w ostatniej chwili - powyższe obawy wydają mi się uzasadnione, podobnie jak odniesienie do zepsutego potoku testowego. Dzięki tej aktualizacji, twoja wcześniejsza notatka, że ​​nowa integracja kodu jest blokowana w poniedziałek, brzmi jak jeszcze jeden symptom zepsutego (myślę, że bardziej precyzyjne słowo byłoby sprzeczne ) potoku. Przez niezgodę rozumiem, co następuje: używasz jednego oddziału, aby jednocześnie służyć dwóm celom: integracji i wydaniu. Kiedy zbliża się wersja, te dwa cele zaczynają się ze sobą kolidować, dążąc do spełnienia sprzecznych wymagań: cel integracji najlepiej realizuje się przy stale otwartym odgałęzieniu ( Scalanie wcześnie i często ), podczas gdy stabilność zwolnienia przynosi korzyści z uszczelnienia oddziału(izolowany) tak długo, jak to możliwe. A-ha wygląda na to, że elementy układanki zaczynają się dopasowywać ...

.. Spójrz, że poniedziałkowe zamrożenie wygląda teraz na kompromis zawarty w celu realizacji sprzecznych celów: programiści cierpią z powodu bloku integracji nowego kodu, podczas gdy testerzy cierpią z powodu tego, że ten blok jest zbyt krótki, wszyscy są nieco niezadowoleni, ale oba cele są w mniejszym lub większym stopniu spełniane.

Wiesz, biorąc pod uwagę powyższe, myślę, że najlepszym rozwiązaniem byłoby wypuszczenie z dedykowanego oddziału (innego niż integracja) . Niezależnie od tego, czy gałąź ta byłaby długowieczna jak integracja, czy krótkotrwała jak gałęzie fabularne (przy czym „funkcja” jest, no cóż, wydanie) - to zależy od ciebie, musi być tylko osobna.

Pomyśl o tym. Obecnie okazuje się, że jeden dzień to za mało, aby wygodnie ustabilizować wydanie, prawda? dzięki nowej strategii rozgałęziania możesz po prostu rozwidlić 2 dni przed wydaniem zamiast jednego, bez problemu. Jeśli okaże się, że nawet dwa dni to za mało, spróbuj rozwidlić 3 dni wcześniej itd. Rzecz w tym, że możesz izolować gałąź wydania tak wcześnie, jak chcesz, ponieważ nie będzie to już blokować scalania nowego kodu z gałęzią integracji. Zauważ, że w tym modelu nie ma potrzeby zamrażania gałęzi integracji - programiści mogą z niego stale korzystać, w każdy poniedziałek, wtorek, piątek.

Cena, którą płacisz za to szczęście, jest komplikacją poprawek. Musiałyby to być fuzje w dwóch gałęziach zamiast w jednym (wydanie + integracja). Na tym powinieneś się skupić podczas testowania nowego modelu. Śledź wszystko, co jest powiązane - dodatkowy wysiłek, który poświęcasz na połączenie z drugim oddziałem, wysiłek związany z ryzykiem, że zapomnisz o połączeniu z drugim oddziałem - wszystko związane.

Pod koniec testów po prostu zsumuj to, co śledziłeś, i dowiedz się, czy ilość tego dodatkowego wysiłku jest do zaakceptowania, czy nie. Jeśli jest to do zaakceptowania, gotowe. W przeciwnym razie powróć do obecnego modelu, przeanalizuj, co poszło nie tak i zacznij myśleć o tym, jak jeszcze możesz to poprawić.

aktualizacja 2

<skopiuj z komentarzy>

Moim celem jest przetestowanie i dostarczenie historii (za lub za ścianą konfiguracji) w ramach iteracji, można to osiągnąć tylko wtedy, gdy testerzy testują pracę wykonaną w iteracji (i nie stabilizują kodu z poprzedniej iteracji).

</ kopiuj z komentarzy>

Widzę. Cóż, nie mam bezpośredniego doświadczenia z tym sposobem, ale widziałem testy w rodzaju iteracji przeprowadzone z powodzeniem w projekcie związanym z naszym. Ponieważ nasz projekt postępował w odwrotny sposób, miałem również luksus bezpośredniego porównania dla tych przeciwnych podejść.

Z mojego punktu widzenia podejście do testowania poza iteracją wyglądało lepiej w tym wyścigu. Tak, ich projekt poszedł dobrze, a testerzy wykryli błędy szybciej niż nasz, ale jakoś to nie pomogło. Nasz projekt również poszedł dobrze i w jakiś sposób mogliśmy sobie pozwolić na krótsze iteracje od nich, i mieliśmy mniej (znacznie mniej) poślizgnięć niż oni, i było mniej napięcia między deweloperem a testerami po naszej stronie.

BTW pomimo szybszego wykrywania po ich stronie, udało nam się mieć mniej więcej taką samą średnią żywotność błędów (żywotność to czas między wprowadzeniem a naprawą , a nie między wprowadzeniem a wykryciem). Prawdopodobnie mieliśmy tu nawet niewielką przewagę, ponieważ dzięki krótszym wersjom i mniejszym opóźnieniom możemy stwierdzić, że średnio nasze poprawki docierają do użytkowników szybciej niż ich.

Podsumowując, nadal uważam, że izolacja kodu dystrybucji ma większe szanse na poprawę wydajności zespołu.

na dalszą myśl ...

• izolacja kodu wersji ma większe szanse - po ponownym przeczytaniu wydaje mi się, że może to sprawiać wrażenie, że zniechęcam cię do testowania iteracji . Chciałbym jasno powiedzieć, że nie.

W twoim przypadku metoda testowania iteracyjnego wydaje się bezpieczna do wypróbowania (er ... test ), ponieważ wydaje się, że dobrze rozumiesz, jak to osiągnąć (płynny test ) i jakie są główne przeszkody. I w końcu zawsze masz możliwość powrotu do alternatywnego podejścia, jeśli uznasz, że zbyt trudno jest prawidłowo przygotować ten rurociąg.

BTW dotyczące przeszkód, dodatkowe, które warto śledzić w tym przypadku, będą takie problemy, jak brak reprodukcji błędu po stronie deweloperów i spóźnienie w znalezieniu / spóźnienie w celu zweryfikowania poprawki po stronie testerów. Mogą one również utknąć w potoku , tak jak dzieje się to teraz z poprawkami.

Nie znając charakteru historii użytkowników i ich liczby, muszę powiedzieć, że tygodniowy cykl wydawania wydaje się ekstremalny. Powyższy scenariusz, który opisałeś, jest misternie zaplanowany i obejmuje szereg różnych gałęzi, punktów scalania, przekazań, środowisk i zestawów testowych, mniej więcej tworząc system ludzki, w którym pojedynczy błąd w złożoności planu może spowodować opóźnione wydanie lub zła jakość. Może to mieć efekt domina w kolejnych wydaniach.

IMHO harmonogram jest po prostu zbyt napięty.

Możesz zwiększyć zasięg kodu, pisząc bardziej efektywne testy jednostkowe, a także testy integracji specyficzne dla środowiska.

Możesz poprawić jakość kodu, wprowadzając programowanie par i / lub przegląd kodu, chociaż zjada to w jeszcze cenniejszym czasie.

Lepsze oszacowanie punktów historii użytkownika może również pomóc poprzez pośrednie ograniczenie historii użytkownika, które trafiają do jednego wydania, tym samym obniżając mianownik współczynnika ryzyka.

Ogólnie rzecz biorąc, wygląda na to, że masz dobre praktyki i masz dobry system do obsługi ekstremalnego cyklu wydawania. Wygląda na to, że podążasz właściwą ścieżką.

Dlaczego nie zastosować rzeczywistego ciągłego wdrażania, w którym zatwierdzenie (lub wypychanie) powoduje uruchomienie testów, a jeśli testy przejdą, wdrożenie nastąpi?

Następnie, jeśli nie masz pewności co do zmiany, wykonaj ją w oddzielnej gałęzi, co nadal powoduje uruchomienie testów, ale nie ma wdrożenia.

Wydaje mi się, że próba doprowadzenia zepsutego pnia / mistrza do stabilności wymaga większego stresu niż, wiesz, utrzymywanie go w stałym stanie.