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