Przeglądaj dostarczenie Taiga na podstawie dowodów

Zacznij od wyniku inicjatywy

Fikcyjna usługa sprzętowa pozwala teraz pracownikom przeglądać własne wnioski. Rozpocznij review od wyniku i zakresu inicjatywy. Wskaż, co musi być prawdą i co zmiana musi pozostawić bez naruszenia.

W tym dostarczeniu pracownik nie może odczytać wniosku innego pracownika. Menedżerowie muszą zachować określony dostęp. Test jedynie otwierający stronę nie potwierdza żadnego warunku.

Powiąż zapisy

Strona Runs zapisuje próby, także nieudane. Każde wykonanie wskazuje realizowany plan. Strona wykonania służy inspekcji; decyzje zmieniające pracę należą do inicjatywy.

Przeczytaj dowody kroków dotyczących testów i formatowania. Taiga uwidacznia kontrole nieudane lub niewykonane. Nie zmieniaj „nie uruchomiono” na „przeszło” w podsumowaniu review.

Sprawdź założenia i granice

Szukaj założeń o modelu dostępu, schemacie, środowisku i usługach zewnętrznych. Porównaj je z opublikowaną intencją i rzeczywistym kodem.

Dla usługi sprzętowej sprawdź miejsce kontroli właściciela wniosku. Przetestuj uprawniony wniosek, wniosek innego pracownika i brakujący wniosek. Sprawdź, czy logi nie ujawniają poufnej treści wniosków.

Przejrzyj też zmiany testów. Przechodzący wynik ma ograniczoną wartość, jeśli zmiana usunęła asercję wykrywającą defekt. Uwzględnij zmiany procesów i konfiguracji testów w zakresie review.

Przekaż informacje pozwalające działać

Wskaż zachowanie, oczekiwany wynik i potrzebne dowody. Na przykład: „Endpoint sprawdza logowanie, ale nie własność wniosku. Dodaj kontrolę dostępu po stronie serwera i test z wnioskiem innego pracownika”.

Taiga może odpowiadać na uwagi review pull requesta i nieudane kontrole zmianami na tym samym branchu. Po aktualizacji sprawdź nowy commit i jego kontrole. Wcześniejsze dowody mogą nie obejmować zmienionego artefaktu.

Jeśli wykonanie zatrzymało się z powodu niepełnego planu lub osłabionej kontroli, przeczytaj podany powód. Nie usuwaj statusu szkicu tylko dlatego, że widoczne podsumowanie kontroli jest zielone.

Podejmij właściwą decyzję o akceptacji

Zapisz zweryfikowane kryteria i te nadal nierozwiązane. Pozwól wymaganym review i kontrolom repozytorium egzekwować granicę merge’a. Zachowaj osobną decyzję o wydaniu, jeśli istnieje.

Taiga obserwuje wdrożenia wykonywane przez pipeline. Sprawdź środowisko i artefakt przed poinformowaniem użytkowników o dostępności zmiany. Nieudane wdrożenie może pozostawić poprzednią udaną wersję obsługującą ruch.

Zamknij wynik kontrolą na poziomie usługi: pracownik może użyć funkcji, nieuprawniony dostęp jest odrzucany, a właściciel operacyjny może obserwować awarie. Przejdź do obsługi przerwania.