Kompleksowa możliwość śledzenia

Azure DevOps Services

Usługa Azure DevOps obsługuje kompleksową możliwość śledzenia, umożliwiając łączenie różnych obiektów, które są zaangażowane w proces programowania. Te obiekty obejmują elementy robocze, gałęzie, zatwierdzenia, żądania ściągnięcia, kompilacje i wydania. Wbudowane raporty i analiza umożliwiają monitorowanie możliwości śledzenia obiektów w czasie rzeczywistym.

Ten artykuł zawiera omówienie sposobu włączania i obsługi funkcji śledzenia przez usługę Azure DevOps bez przechodzenia do szczegółów konfigurowania i używania go. Możesz znaleźć linki do dodatkowych informacji.

Możliwość śledzenia i łączenie

Możesz śledzić zmiany kodu, kompilacje i wydania połączone z elementem roboczym w całym cyklu projektowania. Dzięki temu twój zespół może zobaczyć dziennik inspekcji sposobu wykonania pracy lub sposobu naprawienia usterki przez przyjrzenie się zmianom w bazie kodu.

Typy linków używane dla repozytoriów Git , jak pokazano na poniższej ilustracji, to Build, Found in build, Integrated in build, Branch, Commit, Pull Request i Integrated in release stage (Kompilacja, Znalezione w kompilacji, Zintegrowane w kompilacji, Branch, Commit, Pull Request i Integrated in release stage).

Conceptual image of code, build, and release links to work items.

Tworzenie gałęzi na podstawie wymagania

Wiele zadań można wykonać za pomocą pojedynczego wyboru z tablicy Kanban produktu. Pokazany na poniższej ilustracji, można utworzyć gałąź na podstawie wymagania, otwierając menu karty elementu roboczego. Podczas tworzenia gałęzi z domyślnej gałęzi głównej można nadać jej nazwę i etykietę. Gałąź jest automatycznie połączona z elementem roboczym z typem linku Gałąź .

Screenshot of Kanban board card, menu, choose New branch option.

Możesz też wybrać pozycję Utwórz gałąź w formularzu elementu roboczego.

Screenshot of Work item form, Create a branch link.

Tworzenie żądania ściągnięcia na podstawie wymagania

Po wprowadzeniu zmian w kodzie w nowej gałęzi deweloperzy mogą utworzyć żądanie ściągnięcia z elementu roboczego.

Screenshot of Work item form, Create a pull request.

Korzystanie z tablicy Kanban i elementu roboczego w celu napędzania tworzenia oprogramowania ma również kolejną korzyść. Zachęca deweloperów do dodawania komentarzy podczas pracy, co ułatwia dokumentowanie wprowadzanych przez nich zmian i przyczyn ich wprowadzania. Dzięki temu element roboczy staje się bogatym źródłem informacji i historii zmian kodu.

Dodawanie i uruchamianie testów z wymagań

Połącz test z zestawem wymagań i sprawdź, czy aplikacja działa zgodnie z oczekiwaniami. Z tablicy Kanban można dodawać testy do elementu roboczego. Następnie możesz uruchomić nowe testy z tablicy Kanban i ustawić stan testu.

Screenshot of Kanban board card, menu, choose Add test option.

Integracja testów z tablicą Kanban ułatwia zespołom rozpoczęcie testowania ręcznego, a następnie korzystanie z pełnych możliwości testowania udostępnianych przez plany testów platformy Azure. Tablica Kanban pokazuje test dodany do obsługi wymagania, gdy przypadki testowe są tworzone na podstawie tablicy Kanban lub gdy zestawy testów oparte na wymaganiach są tworzone w obszarze Plany testów.

Testowanie ręczne i automatyczne

Testy automatyczne można uruchamiać w potoku lub na żądanie. Można je również połączyć z przypadkami testowym w planie testów i uruchomić je z planów testów. Dzięki temu można śledzić jakość wymagań za pomocą testów automatycznych, które są nazywane zaplanowanymi testami.

Wdrażanie zmian w środowisku produkcyjnym

Po zdefiniowaniu potoku w celu skompilowania i wydania zmian kodu można śledzić wdrożenie wymagania dla każdego etapu wydania. W formularzu elementu roboczego można szybko otworzyć linki do kompilacji i wydań z sekcji Kontrolka Wdrażanie i programowanie .

Kontrolki wdrażania i programowania

Po otwarciu formularza elementu roboczego możesz zobaczyć etapy, w których zostało wdrożone wymaganie, i przejść do szczegółów, wybierając linki. W sekcji Programowanie możesz otworzyć gałąź, zatwierdzenie lub żądania ściągnięcia, które zostały połączone z wymaganiem.

Work item form, Deployment control, Release Settings Stages.

Kontrolka Wdrażanie zawiera informacje o wersji dla tych elementów roboczych, które zostały skojarzone z zatwierdzeniem usługi Git, które jest częścią wydanej kompilacji.

Widok wydania

Na poniższej ilustracji przedstawiono wiele środowisk przeznaczonych dla wydania, z którym jest skojarzony wybrany element roboczy.

Example showing multiple environments that the release is targeting.

Ustawienia wydania

Zarządzaj opcjami wyświetlania z poziomu ustawień wydania. Kontrolka wdrażania elementu roboczego pokazuje postęp wydań połączonych z elementami roboczymi. Możesz zobaczyć stan wydania elementów roboczych, które mają zatwierdzenia w kompilacji i dla potoków wydania skonfigurowanych do wysyłania informacji o wdrożeniu do usługi Azure Boards.

Screenshot of Release pipeline Options>Integrations settings.

Macierz śledzenia wymagań

Możliwość śledzenia wymagań zapewnia zespołom wgląd w wskaźniki, takie jak jakość wymagań lub gotowość do wysłania wymagań. Podstawowym aspektem śledzenia wymagań jest skojarzenie wymagań dotyczących przypadków testowych, usterek i zmian kodu.

Macierz śledzenia wymagań (RTM) gwarantuje, że wszystkie wymagania zdefiniowane dla systemu są testowane w protokołach testowych.

Raporty dotyczące możliwości śledzenia wymagań

Raporty dotyczące możliwości śledzenia wymagań to sposób pokazywania, jak różne fazy procesu programowania są powiązane i udokumentowane. Pomagają zespołom mierzyć jakość i kompletność swoich wymagań oraz ocenić gotowość do dostarczenia. Ułatwiają one również śledzenie zmian kodu, testów, usterek i wdrożeń powiązanych z wymaganiami.

Screenshot of the Requirements quality widget.

Możliwość śledzenia błędów

Usterka i wynik testu są widoczne razem na karcie Testy w tym samym kontekście. Karta Elementy robocze zawiera również wszelkie wymagania połączone z wynikiem testu.

Aby uzyskać informacje o błędach i możliwościach śledzenia źródła, zobacz Wymagania dotyczące możliwości śledzenia.

Możliwość śledzenia źródła

Na podstawie potoku kompilacji lub wydania można wybrać oś czasu lub widok potoku, aby zobaczyć, jakie zmiany kodu zostały zatwierdzone. Możesz przeanalizować zmiany kodu, aby zidentyfikować potencjalną główną przyczynę niepowodzenia testu.

Screenshot of source traceability.

Analiza testów

Aby uzyskać informacje na temat usługi Test Analytics dla kompilacji i wydań, śledzenia jakości wymagań i niepowodzeń testów, zobacz Test Analytics.