Szablon danych cyklu życia tworzenia oprogramowania

GitHub
Szablon danych cyklu życia tworzenia oprogramowania

Szablon danych cyklu życia tworzenia oprogramowania

Ten szablon zawiera wskazówki dotyczące zbierania i przygotowania danych o cyklu życia tworzenia oprogramowania z GitHub. Znajdą w nim Państwo zalecane atrybuty, działania do śledzenia oraz praktyczne informacje o ekstrakcji danych. Skorzystajcie Państwo z tych wskazówek, aby przygotować dokładny dziennik zdarzeń do analizy i optymalizacji procesu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące ekstrakcji
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty cyklu życia tworzenia oprogramowania

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby analizować cykl życia tworzenia oprogramowania i odkrywać przebieg procesu.
3 Wymagane 5 Zalecane 15 Opcjonalne
Nazwa Opis
Czas rozpoczęcia
EventTimestamp
Dokładna data i godzina wystąpienia konkretnej czynności lub zdarzenia w procesie wytwarzania oprogramowania.
Opis

Ten znacznik czasu wskazuje początek czynności. Jest niezbędny do uporządkowania zdarzeń chronologicznie i odtworzenia przebiegu procesu dla każdego elementu prac rozwojowych. Kolejność i różnice czasu między znacznikami służą do analizy wydajności procesu.

W analizie ten atrybut jest potrzebny do obliczania wszystkich miar opartych na czasie, w tym czasu cyklu, czasu przetwarzania i czasu oczekiwania. Pozwala wykrywać opóźnienia między krokami oraz dostarcza danych do analizy wąskich gardeł i monitorowania wyników na dashboardach.

Dlaczego to ważne

Ten znacznik czasu jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczania miar wydajności, takich jak czas cyklu i czas trwania wąskich gardeł.

Skąd pobrać

Zwykle znajduje się w polach 'created_at' lub 'updated_at' danych JSON z GitHub API i webhooków dla różnych obiektów, takich jak zgłoszenia, pull request i commity.

Przykłady
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Czynność
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w cyklu wytwarzania oprogramowania.
Opis

Nazwa czynności opisuje pojedynczy krok procesu wytwarzania, np. 'Utworzenie zgłoszenia', 'Przesłanie kodu do PR', 'Zatwierdzenie pull request' lub 'Pomyślne wdrożenie'. Zdarzenia te tworzą sekwencję kroków składających się na cały proces dotyczący elementu prac rozwojowych.

Ten atrybut jest podstawą process mining, ponieważ służy do budowy mapy procesu. Analiza kolejności, częstotliwości i czasu trwania czynności pokazuje rzeczywisty przebieg procesu, typowe ścieżki i odstępstwa oraz pozwala wskazać wąskie gardła.

Dlaczego to ważne

Ten atrybut stanowi podstawę mapy procesu. Pozwala przedstawić i analizować kolejność zdarzeń w cyklu wytwarzania oprogramowania.

Skąd pobrać

Wartość pochodzi z pola 'action' w danych zdarzeń webhooka, np. 'opened' lub 'closed' dla zgłoszenia, albo z typu samego zdarzenia, np. 'PushEvent' lub 'PullRequestReviewEvent'.

Przykłady
Utworzenie zgłoszeniaOtwarcie pull requestPrzesłanie kodu do PRProśba o przegląd koduScalenie pull request
Element prac rozwojowych
DevelopmentItemId
Unikalny identyfikator pojedynczego elementu pracy rozwojowej, takiego jak funkcja, poprawka błędu lub zadanie. Służy jako główny identyfikator case.
Opis

Identyfikator elementu prac rozwojowych śledzi zadanie od utworzenia aż do wdrożenia. Łączy wszystkie powiązane czynności, takie jak tworzenie gałęzi, commity, pull request, przeglądy i wdrożenia, w jeden spójny przebieg procesu.

W analizie ten identyfikator służy do obliczania całkowitego czasu cyklu zadania rozwojowego. Pozwala odtworzyć pełny przebieg prac nad funkcją lub poprawką błędu, a następnie szczegółowo analizować wąskie gardła, powroty do wcześniejszych etapów i różnice w przebiegu procesu dla poszczególnych zadań.

Dlaczego to ważne

To niezbędny identyfikator w process mining. Łączy wszystkie powiązane zdarzenia prac rozwojowych w jeden case, dzięki czemu można dokładnie przedstawić i analizować cały cykl wytwarzania oprogramowania.

Skąd pobrać

Zwykle jest to numer zgłoszenia lub pull request z GitHub. Można go pobrać z pola 'number' w danych webhooka lub odpowiedzi API dotyczących zgłoszenia albo pull request.

Przykłady
101PR-2345TASK-812
Czas zakończenia
EndTimestamp
Dokładna data i godzina zakończenia konkretnej czynności lub zdarzenia w procesie wytwarzania oprogramowania.
Opis

Końcowy znacznik czasu wskazuje zakończenie czynności. Wiele zdarzeń w GitHub jest chwilowych, np. 'Utworzenie zgłoszenia', ale niektóre czynności trwają określony czas, np. kontrola CI. Różnica między czasem zakończenia a czasem rozpoczęcia daje czas przetwarzania czynności.

Ten atrybut służy do obliczania miary 'ProcessingTime', która pomaga ustalić, ile aktywnej pracy wymagają poszczególne zadania, takie jak przegląd kodu lub kontrole automatyczne. Analiza czasu przetwarzania pozwala wykryć czynności, które niepotrzebnie zajmują dużo czasu.

Dlaczego to ważne

Pozwala dokładnie obliczyć czas przetwarzania czynności i odróżnić czas aktywnej pracy od bezczynnego oczekiwania.

Skąd pobrać

Można go znaleźć w polu 'completed_at' obiektów check run lub wyznaczyć na podstawie znacznika czasu kolejnego zdarzenia, które logicznie kończy daną czynność.

Przykłady
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorytet
Priority
Poziom priorytetu przypisany do elementu prac rozwojowych, np. 'High', 'Medium' lub 'Low'.
Opis

Priorytet określa pilność lub znaczenie danego elementu pracy dla firmy. GitHub nie ma wbudowanego pola priorytetu, dlatego zwykle oznacza się go etykietami, np. „P1-High” lub „P2-Medium”. Aby wiarygodnie odczytywać priorytety, potrzebna jest spójna konwencja nazewnictwa etykiet.

Ten atrybut jest niezbędny do analizy przepływu pracy według priorytetu. Pozwala sprawdzić, czy elementy o wysokim priorytecie są rzeczywiście przetwarzane szybciej niż te o niskim, oraz zmierzyć różnice w czasie cyklu zależnie od priorytetu. Ułatwia też ocenę skuteczności ustalania priorytetów.

Dlaczego to ważne

Pozwala sprawdzić, czy elementy o wysokim priorytecie są przetwarzane szybciej niż te o niższym, a tym samym ocenić skuteczność strategii ustalania priorytetów.

Skąd pobrać

Atrybut jest wyznaczany na podstawie etykiet GitHub przypisanych do zgłoszeń lub pull requestów. Wymaga ujednoliconego nazewnictwa etykiet priorytetu.

Przykłady
WysokiŚredniNiskiKrytyczny
Przypisany użytkownik
Assignee
Użytkownik lub programista przypisany do obsługi elementu prac rozwojowych albo konkretnego zadania, np. przeglądu pull request.
Opis

Ten atrybut wskazuje osobę odpowiedzialną za pracę na danym etapie. Może to być osoba przypisana do zgłoszenia, autor pull request lub recenzent wskazany do przeglądu kodu. Śledzenie przypisań pomaga zrozumieć podział zasobów i obciążenie pracą.

W analizie atrybut służy do monitorowania obciążenia programistów, wykrywania wąskich gardeł związanych z zasobami i oceny sprawności przekazywania pracy między członkami zespołu. Dashboardy można filtrować według przypisanej osoby, aby ocenić wyniki poszczególnych osób lub zespołów i zadbać o równomierny podział pracy.

Dlaczego to ważne

Niezbędny do analizy obciążenia programistów, wyników zespołu i sprawności przekazywania pracy między jego członkami.

Skąd pobrać

Dostępny w obiekcie 'assignee' lub 'user' w danych JSON dotyczących zgłoszeń, pull request i przeglądów, zwracanych przez GitHub API.

Przykłady
john.doejane.smithdev-team-lead
Repozytorium
RepositoryName
Nazwa repozytorium kodu, w którym odbywają się prace rozwojowe.
Opis

Repozytorium pełni funkcję identyfikatora projektu lub produktu. Zawiera cały kod, zgłoszenia i pull request dotyczące konkretnej aplikacji lub komponentu. Umożliwia podział i porównywanie procesów wytwarzania oprogramowania dla różnych produktów lub zespołów.

W analizie ten atrybut pozwala filtrować i porównywać wyniki procesu w różnych projektach. Pomaga odpowiedzieć na pytania takie jak: „W którym projekcie cykl trwa najdłużej?” lub „Jak przebiega naprawa błędów w projekcie A w porównaniu z projektem B?”. Jest niezbędny na dashboardzie „Przepustowość według projektu i typu”.

Dlaczego to ważne

Pozwala podzielić i porównać procesy wytwarzania oprogramowania w różnych projektach, produktach i zespołach, a następnie przeprowadzić bardziej ukierunkowaną analizę.

Skąd pobrać

Dostępny w obiekcie 'repository' w niemal wszystkich danych webhooków i API GitHub. Konkretne pole to zwykle 'repository.full_name' lub 'repository.name'.

Przykłady
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Typ elementu prac rozwojowych
DevelopmentItemType
Klasyfikacja elementu pracy rozwojowej, np. funkcja, błąd, zadanie lub epik.
Opis

Ten atrybut określa rodzaj wykonywanej pracy. Informacje te są zwykle zarządzane za pomocą etykiet lub specjalnych szablonów zgłoszeń w GitHub. Znajomość typu pracy pozwala ustalić odpowiednie oczekiwania dotyczące wydajności, ponieważ naprawa błędu może trwać znacznie krócej niż opracowanie nowej funkcji.

Atrybut umożliwia porównywanie różnych typów pracy. Pomaga sprawdzić, czy błędy są naprawiane szybciej niż powstają nowe funkcje, oraz przeanalizować podział zasobów między dług techniczny a nowe prace rozwojowe. Jest ważnym wymiarem na dashboardzie „Przepustowość według projektu i typu”.

Dlaczego to ważne

Klasyfikuje elementy pracy, umożliwiając porównywanie wyników i analizę przebiegu różnych rodzajów pracy, np. obsługi błędów i tworzenia funkcji.

Skąd pobrać

Zwykle określa się go na podstawie etykiet GitHub przypisanych do zgłoszeń lub pull request. Wymaga to stosowania spójnej konwencji etykiet, np. 'type:bug' lub 'type:feature'.

Przykłady
BłądFunkcjaZadanieDług techniczny
Autor
Author
Użytkownik, który utworzył zgłoszenie, pull request lub commit.
Opis

Autor to osoba, która utworzyła dany element w procesie wytwarzania oprogramowania. Na przykład autorem zgłoszenia jest osoba, która zgłosiła błąd lub poprosiła o nową funkcję. Autorem pull requestu jest programista, który napisał kod.

Analiza autorów pomaga ustalić, skąd pochodzi praca. Analiza autorów zgłoszeń błędów może na przykład ujawnić wzorce związane z konkretnymi zespołami lub funkcjami. Zestawienie autora z osobą przypisaną do zadania pozwala również analizować przekazywanie pracy.

Dlaczego to ważne

Wskazuje osobę, która utworzyła element pracy lub wprowadziła zmianę w kodzie. Może to pomóc w analizie źródeł poprawek, zgłoszeń błędów i próśb o nowe funkcje.

Skąd pobrać

Dostępny w obiekcie „user” w głównym obiekcie odpowiedzi API dotyczących zgłoszeń, pull requestów i commitów. Pole to zwykle ma nazwę „user.login”.

Przykłady
sara.jonesmike.leeautomation-bot
Czas cyklu wytwarzania oprogramowania
DevelopmentCycleTime
Łączny czas od utworzenia elementu pracy w procesie wytwarzania oprogramowania do jego wdrożenia lub zamknięcia.
Opis

To miara na poziomie sprawy, obliczana jako różnica czasu między pierwszym zdarzeniem (np. „Utworzono zgłoszenie”) a ostatnim (np. „Wdrożenie zakończone powodzeniem” lub „Zamknięto zgłoszenie”) dla pojedynczego elementu pracy.

Jest to jeden z najważniejszych KPI służących do pomiaru ogólnej sprawności procesu wytwarzania oprogramowania. Miara ta bezpośrednio wspiera dashboard „Całkowity czas cyklu wytwarzania oprogramowania” oraz KPI „Średni czas cyklu wytwarzania oprogramowania”. Skrócenie tego czasu jest częstym celem inicjatyw związanych z ulepszaniem procesów.

Dlaczego to ważne

Pokazuje całkowity czas od rozpoczęcia prac nad elementem do jego dostarczenia, dlatego jest ważnym KPI służącym do pomiaru tempa i sprawności procesu.

Skąd pobrać

Obliczany na poziomie sprawy przez odjęcie znacznika czasu pierwszego działania od znacznika czasu ostatniego działania.

Przykłady
P5DT6H30MP14DT12HP1DT2H
Czas oczekiwania przy przekazaniu pracy
HandoffWaitingTime
Obliczony czas, przez który element pracy pozostaje bezczynny między działaniami wykonywanymi przez różne osoby.
Opis

Ta miara określa czas między zakończeniem jednego działania a rozpoczęciem kolejnego, ale tylko wtedy, gdy zmienia się osoba odpowiedzialna. Przykładem jest czas między zdarzeniem „Poproszono o przegląd” a zdarzeniem „Zażądano zmian podczas przeglądu”, wykonanym przez innego użytkownika.

Miara pomaga wykrywać problemy z komunikacją i koordynacją. Wspiera dashboard „Sprawność przekazywania pracy” oraz KPI „Średni czas oczekiwania przy przekazaniu pracy”. Długie oczekiwanie przy przekazaniu często wskazuje na ograniczoną dostępność zasobów lub nieskuteczny system powiadomień.

Dlaczego to ważne

Pomaga wykrywać opóźnienia wynikające ze słabej koordynacji lub braku dostępnych zasobów podczas przekazywania pracy między zespołami albo rolami. Takie opóźnienia często są istotnym źródłem nieefektywności.

Skąd pobrać

Obliczany przez wyszukanie kolejnych działań, w których zmienia się atrybut „Assignee” lub „User”, a następnie zmierzenie przerwy między nimi.

Przykłady
PT1H15MP2DT4HPT25M
Czy wymaga poprawek
IsRework
Wartość logiczna ustawiona na true, jeśli działanie oznacza powrót do wcześniejszego etapu procesu.
Opis

Flaga przyjmuje wartość true, gdy element pracy cofa się w procesie, na przykład gdy osoba przeglądająca pull request prosi o zmiany lub gdy ponownie otwierane jest zamknięte zgłoszenie. Wartość wyznacza się na podstawie analizy sekwencji działań.

Atrybut ten pozwala określić skalę strat i nieefektywności. Bezpośrednio wspiera dashboard „Pętle poprawek i regresji” oraz KPI „Odsetek poprawek”. Filtrowanie według „IsRework = true” pozwala wyodrębnić przypadki wymagające poprawek i zbadać ich przyczyny.

Dlaczego to ważne

Jednoznacznie oznacza działania wymagające poprawek, ułatwiając określenie ich skali, wizualizację i analizę przyczyn nieefektywności procesu.

Skąd pobrać

Jest to atrybut pochodny. Najpierw definiuje się standardowy przebieg procesu, a następnie oznacza działania, które odbiegają od niego przez powrót do wcześniejszego etapu.

Przykłady
truefalse
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych. Dostarcza metadanych o aktualności analizowanych danych. Różni się od znacznika czasu zdarzenia, który wskazuje, kiedy nastąpiło zdarzenie biznesowe.

W analizie to pole pomaga ocenić aktualność obrazu procesu. Informuje, czy analizowane są bieżące dane, czy migawka z określonego momentu. Ma to znaczenie w przypadku dashboardów operacyjnych i monitorowania.

Dlaczego to ważne

Wskazuje aktualność danych, co pozwala upewnić się, że analizy i dashboardy opierają się na najnowszych informacjach.

Skąd pobrać

Ten znacznik czasu jest generowany i dodawany podczas procesu pobierania, przekształcania i ładowania danych (ETL).

Przykłady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Etykiety
Labels
Lista tagów lub etykiet przypisanych do zgłoszenia albo pull requestu w celu jego kategoryzacji.
Opis

Etykiety w GitHub to elastyczny sposób dodawania metadanych do zgłoszeń i pull requestów. Mogą określać priorytet, rodzaj pracy, komponenty, zespoły lub status. Pełna lista etykiet dostarcza wielu nieustrukturyzowanych informacji kontekstowych.

Konkretne atrybuty, takie jak priorytet i typ, można wyznaczyć na podstawie etykiet, ale warto zachować ich pełną listę do analiz doraźnych i wykrywania innych wzorców w procesie. Umożliwia to elastyczne filtrowanie i segmentowanie spraw według dowolnego zestawu etykiet.

Dlaczego to ważne

Dostarcza elastycznych i bogatych metadanych do kategoryzowania elementów pracy, co pozwala analizować je z wielu perspektyw.

Skąd pobrać

Dostępne jako tablica „labels” w danych JSON dotyczących zgłoszeń i pull requestów z GitHub API. Każdy element tablicy jest obiektem zawierającym pole „name”.

Przykłady
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Hash commitu
CommitHash
Unikalny identyfikator (SHA) konkretnego commitu z kodem.
Opis

Hash commitu to 40-znakowy skrót SHA-1, który jednoznacznie identyfikuje commit w Git. Jest trwałym identyfikatorem konkretnej wersji kodu. Commity są najmniejszymi jednostkami zmian w procesie wytwarzania oprogramowania.

Hash commitu zapewnia bardzo szczegółową identyfikowalność. Pozwala powiązać zdarzenie w procesie bezpośrednio z konkretną zmianą w kodzie. Może to być szczególnie przydatne podczas audytów, weryfikacji zgodności lub szczegółowej analizy przyczyn incydentów produkcyjnych.

Dlaczego to ważne

Pozwala powiązać krok procesu z konkretną zmianą w kodzie z największą dokładnością, zapewniając pełną identyfikowalność na potrzeby audytów i debugowania.

Skąd pobrać

Dostępny w danych zdarzeń push („head_commit.id”) lub przez Commits API dla pull requestu albo gałęzi.

Przykłady
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nazwa gałęzi
BranchName
Nazwa gałęzi Git, w której wprowadzono zmiany w kodzie dotyczące danego elementu pracy.
Opis

Gałąź to niezależna linia rozwoju, tworzona po to, by pracować nad nową funkcją lub poprawką błędu bez ingerowania w główną bazę kodu. Jej nazwa często zawiera przydatne informacje, takie jak numer zgłoszenia lub krótki opis pracy.

Analiza nazw gałęzi pomaga zrozumieć przyjętą strategię pracy z gałęziami i sprawdzić, czy jest ona zgodna z konwencjami zespołu. Ułatwia też powiązanie konkretnych commitów z elementem pracy, dając pełniejszy obraz działań związanych z kodowaniem.

Dlaczego to ważne

Dostarcza kontekstu dotyczącego danej linii rozwoju oraz pomaga stosować i analizować strategie pracy z gałęziami i konwencje ich nazewnictwa.

Skąd pobrać

Dostępna w polu „ref” dla zdarzeń push lub w obiektach „head” i „base” w odpowiedzi API dotyczącej pull requestu.

Przykłady
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Numer pull requestu
PullRequestNumber
Unikalny identyfikator pull requestu powiązanego z elementem pracy w procesie wytwarzania oprogramowania.
Opis

Pull request (PR) to propozycja scalenia zestawu zmian w kodzie z określoną gałęzią. Numer pull requestu łączy działania związane z wytwarzaniem oprogramowania, takie jak wysyłanie zmian w kodzie i przeglądy, z głównym elementem pracy lub zgłoszeniem.

Ten identyfikator jest niezbędny do śledzenia integracji kodu i przeglądu w ramach całego cyklu wytwarzania oprogramowania. Umożliwia szczegółową analizę przeglądu kodu, w tym czasu przeglądu, poprawek wymaganych podczas przeglądu i odsetka scalonych zmian. Łączy etap planowania (zgłoszenie) z etapem wdrożenia zmian w kodzie (PR).

Dlaczego to ważne

Łączy zgłoszenia z konkretnymi zmianami w kodzie i procesem ich przeglądu. Umożliwia szczegółową analizę cyklu przeglądu kodu i jego wpływu na całkowity czas dostarczenia zmian.

Skąd pobrać

Dostępny jako pole „number” w obiekcie „pull_request” w wielu odpowiedziach GitHub API lub jako główny identyfikator w Pull Requests API.

Przykłady
12345678910
Osoba przeglądająca kod
Reviewer
Użytkownik poprosił o przeprowadzenie przeglądu kodu w pull requeście.
Opis

Osoba przeglądająca kod to programista lub członek zespołu wyznaczony do sprawdzenia zmian w pull requeście pod kątem jakości, poprawności i zgodności ze standardami. Pull request może mieć kilka osób przeglądających.

Ten atrybut jest niezbędny do analizy procesu przeglądu kodu. Pomaga wykrywać wąskie gardła związane z konkretnymi osobami, oceniać rozkład obciążenia pracą i mierzyć czas odpowiedzi na prośby o przegląd. Jest też potrzebny do obliczenia KPI „Średni czas cyklu przeglądu kodu”.

Dlaczego to ważne

Wskazuje osoby uczestniczące w kontroli jakości. Umożliwia analizę obciążenia pracą związanego z przeglądami, opóźnień i ogólnej sprawności przeglądu kodu.

Skąd pobrać

Dostępna w tablicy „requested_reviewers” lub w obiekcie „user” zdarzenia przeglądu pull requestu w GitHub API.

Przykłady
alex.chenmaria.garciasenior-dev-team
Środowisko wdrożeniowe
DeploymentEnvironment
Środowisko docelowe wdrożenia, np. „Staging” lub „Production”.
Opis

Ten atrybut określa, gdzie wdrażany jest kod. Śledzenie wdrożeń w różnych środowiskach pomaga zrozumieć cały cykl, od prac programistycznych po wydanie produkcyjne.

Pozwala analizować etap wdrożenia. Można go użyć do zmierzenia czasu potrzebnego na przeniesienie kodu ze środowiska staging do produkcji oraz do śledzenia skuteczności wdrożeń w poszczególnych środowiskach. Pomaga ustalić, kiedy element pracy jest rzeczywiście ukończony i udostępniony użytkownikom.

Dlaczego to ważne

Pozwala odróżnić wydania przedprodukcyjne od produkcyjnych. Jest to niezbędne do pomiaru rzeczywistego czasu wprowadzenia produktu na rynek i analizy wzorców wdrożeń.

Skąd pobrać

Informacje te pochodzą z GitHub Deployments API, które często jest wywoływane przez pipeline CI/CD lub inne mechanizmy automatyzacji.

Przykłady
developmentstagingproduction
Stan elementu
State
Bieżący status zgłoszenia lub pull request, np. 'open', 'closed' lub 'merged'.
Opis

Ten atrybut wskazuje ogólny status elementu prac rozwojowych. Zgłoszenia mają zwykle stany 'open' i 'closed'. Pull request mogą mieć stany 'open', 'closed' i 'merged'. Dzięki temu można sprawdzić postęp prac nad danym elementem.

W analizie stan służy do rozróżniania pracy w toku od pracy zakończonej. Jest niezbędny na dashboardach takich jak „Postęp aktywnych prac rozwojowych”, które monitorują bieżące zadania. Pomaga też określić koniec procesu. Na przykład stan 'merged' lub 'closed' może oznaczać zakończenie danego case.

Dlaczego to ważne

Jasno wskazuje, czy prace nad danym elementem trwają, czy zostały zakończone. To podstawa analizy cyklu życia i monitorowania bieżących zadań.

Skąd pobrać

Dostępny bezpośrednio w polu 'state' danych JSON zgłoszeń i pull request z GitHub API.

Przykłady
openclosedmerged
Status kontroli CI
CiCheckStatus
Status automatycznej kontroli Continuous Integration (CI), np. „passed” lub „failed”.
Opis

Ten atrybut pokazuje wynik automatycznych kompilacji, testów i skanów uruchamianych dla zmian w kodzie w pull requeście. Kontrole CI są ważnym punktem kontroli jakości we współczesnych workflow wytwarzania oprogramowania.

Analiza tego atrybutu pomaga ocenić skuteczność testów automatycznych. Wysoki odsetek niepowodzeń może wskazywać na problemy ze stabilnością kodu, zestawem testów lub środowiskiem programistycznym. Atrybut obsługuje działania „Kontrole CI zakończone powodzeniem” i „Kontrole CI zakończone niepowodzeniem”, a także pomaga analizować opóźnienia spowodowane nieudanymi kompilacjami.

Dlaczego to ważne

Pokazuje, czy automatyczne kontrole jakości zakończyły się powodzeniem, czy niepowodzeniem. Dostarcza informacji o jakości kodu i skuteczności pipeline CI.

Skąd pobrać

Pobierany z pola „state” lub „conclusion” obiektów check run albo status za pośrednictwem GitHub Checks API lub Statuses API.

Przykłady
successfailurependingerror
System źródłowy
SourceSystem
System, z którego pobrano dane o procesie wytwarzania oprogramowania.
Opis

Ten atrybut wskazuje źródło danych o zdarzeniach. W tym procesie jego wartością będzie zawsze 'GitHub'. W bardziej złożonym środowisku, w którym prace rozwojowe obejmują kilka systemów, np. Jira do planowania, GitHub do kodu i Jenkins do wdrożeń, pole to pozwala rozróżnić źródła poszczególnych zdarzeń.

W analizie ułatwia sprawdzenie pochodzenia danych na potrzeby walidacji i rozwiązywania problemów. Pozwala też analizować procesy obejmujące różne platformy i zachować kontekst każdej czynności.

Dlaczego to ważne

Wskazuje źródło danych, co jest niezbędne do ich walidacji i analizy procesów obejmujących kilka zintegrowanych systemów.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas procesu pobierania, przekształcania i ładowania danych (ETL), aby oznaczyć źródło rekordów.

Przykłady
GitHubGitHub Enterprise
Wynik przeglądu kodu
ReviewState
Wynik przeglądu kodu w pull requeście, np. „Approved” lub „Changes Requested”.
Opis

Ten atrybut zapisuje decyzję osoby przeglądającej kod. Typowe stany to „APPROVED”, czyli zgoda na scalenie kodu, oraz „CHANGES_REQUESTED”, czyli konieczność wprowadzenia poprawek. Inne stany to między innymi „COMMENTED” i „PENDING”.

Atrybut ten ma duże znaczenie przy analizie poprawek i jakości. Częste zdarzenia „CHANGES_REQUESTED” mogą wskazywać na niską jakość początkowego kodu lub niejasne wymagania. Atrybut wspiera dashboard „Pętle poprawek i regresji”, pokazując, kiedy element pracy wraca do modyfikacji.

Dlaczego to ważne

Bezpośrednio wskazuje pętle poprawek i punkty kontroli jakości w procesie przeglądu kodu, pomagając ustalić źródła nieefektywności i problemów z jakością.

Skąd pobrać

Dostępny jako pole „state” w obiekcie przeglądu pull requestu z GitHub API, na przykład w danych zdarzenia „PullRequestReviewEvent”.

Przykłady
APPROVEDCHANGES_REQUESTEDCOMMENTED
Wymagane Zalecane Opcjonalne

Działania w cyklu życia tworzenia oprogramowania

Poniżej przedstawiono najważniejsze kroki procesu i kamienie milowe, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie odtworzyć przebieg procesu i wykryć wąskie gardła.
6 Zalecane 7 Opcjonalne
Działanie Opis
Otwarcie pull request
Oznacza, że pierwsza wersja kodu jest gotowa do przeglądu i włączenia do głównej gałęzi. Programista tworzy pull request (PR), aby zaproponować zmiany z gałęzi funkcji do gałęzi głównej. To jawne zdarzenie w GitHub.
Dlaczego to ważne

To ważny etap, który kończy początkową fazę programowania i rozpoczyna przegląd oraz integrację kodu. Pozwala osobno analizować czas programowania i czas przeglądu.

Skąd pobrać

Zdarzenie jest rejestrowane w strumieniu zdarzeń GitHub Pull Request API lub przez webhooki. Wartość akcji zdarzenia to 'opened'.

Rejestrowanie

Nasłuchuj akcji 'opened' dla pull request za pomocą webhooków lub cyklicznego odpytywania API.

Typ zdarzenia explicit
Scalenie pull request
Zatwierdzone zmiany z pull request zostają oficjalnie włączone do gałęzi docelowej, np. main lub develop. To jawna, końcowa czynność dotycząca pull request, która włącza nowy kod.
Dlaczego to ważne

To ważny etap oznaczający zakończenie programowania i przeglądu kodu. W wielu zespołach jest to ostatni krok przed automatycznym wdrożeniem.

Skąd pobrać

Zdarzenie jest rejestrowane w strumieniu zdarzeń GitHub Pull Request API lub przez webhooki. Akcja zdarzenia to 'closed', a atrybut 'merged' w danych pull request ma wartość true.

Rejestrowanie

Nasłuchuj akcji 'closed' dla pull request i sprawdzaj, czy flaga 'merged' ma wartość true.

Typ zdarzenia explicit
Utworzenie zgłoszenia
To początek cyklu życia elementu prac rozwojowych, czyli formalne utworzenie zadania, zgłoszenia błędu lub propozycji funkcji. Zdarzenie jest rejestrowane, gdy użytkownik tworzy nowe zgłoszenie w repozytorium GitHub.
Dlaczego to ważne

To główna czynność rozpoczynająca proces. Jest niezbędna do pomiaru całkowitego czasu cyklu wytwarzania i ustalenia, skąd początkowo napływają prace.

Skąd pobrać

To jawne zdarzenie rejestrowane w strumieniu zdarzeń GitHub Issues API. Typ zdarzenia dla danego numeru zgłoszenia to zwykle 'opened'.

Rejestrowanie

Nasłuchuj zdarzenia 'opened' dla zgłoszenia za pomocą webhooków lub cyklicznego odpytywania API.

Typ zdarzenia explicit
Zaliczenie kontroli CI
Oznacza pomyślne zakończenie automatycznych kontroli, takich jak kompilacja, testy jednostkowe lub analiza statyczna kodu w pull request. Zdarzenie jest wnioskowane na podstawie statusu kontroli zgłaszanego przez systemy takie jak GitHub Actions.
Dlaczego to ważne

Ta automatyczna kontrola jakości pomaga zapewnić stabilność kodu. Błędy lub długi czas działania kontroli mogą tworzyć istotne wąskie gardła w procesie dostarczania.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie GitHub Checks API lub Statuses API. Wynik kontroli lub aktualizacja statusu zgłasza 'success' albo 'completed' z wynikiem 'success'.

Rejestrowanie

Monitoruj Checks API pod kątem wyniku 'success' dla odpowiednich zestawów kontroli.

Typ zdarzenia inferred
Zamknięcie zgłoszenia
Element prac rozwojowych uznaje się za ukończony, a powiązane zgłoszenie zostaje formalnie zamknięte. Może to nastąpić automatycznie po scaleniu powiązanego pull request lub ręcznie, przez członka zespołu.
Dlaczego to ważne

Ta czynność oznacza koniec procesu dla danego elementu prac rozwojowych. Jest niezbędna do obliczenia całkowitego czasu cyklu.

Skąd pobrać

To jawne zdarzenie rejestrowane w strumieniu zdarzeń GitHub Issues API. Typ zdarzenia to 'closed'.

Rejestrowanie

Nasłuchuj zdarzenia 'closed' dla zgłoszenia za pomocą webhooków lub cyklicznego odpytywania API.

Typ zdarzenia explicit
Zatwierdzenie pull request
Recenzent formalnie zatwierdził zmiany w pull request, potwierdzając, że spełniają wymagania jakościowe i funkcjonalne. Zdarzenie jest rejestrowane, gdy recenzent przesyła recenzję ze statusem 'approve'.
Dlaczego to ważne

To ważny etap kontroli jakości i istotny punkt przed scaleniem zmian. Czas od utworzenia PR do zatwierdzenia jest ważnym KPI efektywności przeglądu kodu.

Skąd pobrać

Zdarzenie jest rejestrowane w GitHub Pull Request API lub przez webhooki, gdy recenzja zostaje przesłana ze stanem 'APPROVED'.

Rejestrowanie

Filtruj zdarzenia przesłania recenzji pull request według stanu 'APPROVED'.

Typ zdarzenia explicit
Niepowodzenie kontroli CI
Oznacza niepowodzenie automatycznej kontroli, takiej jak błąd kompilacji lub niezaliczony test jednostkowy kodu w pull request. Zdarzenie jest wnioskowane na podstawie statusu błędu zgłoszonego przez system taki jak GitHub Actions.
Dlaczego to ważne

Ta czynność wskazuje problemy techniczne z jakością, które wymagają interwencji programisty i powodują powrót do wcześniejszego etapu. Analiza częstotliwości błędów może pomóc usprawnić testowanie lokalne lub poprawić jakość kodu.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie GitHub Checks API lub Statuses API. Wynik kontroli lub aktualizacja statusu zgłasza 'failure' albo 'completed' z wynikiem 'failure'.

Rejestrowanie

Monitoruj Checks API pod kątem wyniku 'failure' dla odpowiednich zestawów kontroli.

Typ zdarzenia inferred
Pomyślne wdrożenie
Zmiany w kodzie zostały pomyślnie wdrożone w określonym środowisku, np. testowym lub produkcyjnym. Zdarzenie jest zwykle rejestrowane przez GitHub Deployments API, często po uruchomieniu GitHub Action po scaleniu zmian.
Dlaczego to ważne

Oznacza przeniesienie kodu z repozytorium do działającego środowiska. Śledzenie tego zdarzenia jest niezbędne do pomiaru całkowitego czasu od pomysłu do wdrożenia na produkcję.

Skąd pobrać

Zdarzenie jest rejestrowane przez Deployments API. Usługa zewnętrzna lub GitHub Action tworzy wdrożenie, a następnie aktualizuje jego status na 'success'.

Rejestrowanie

Monitoruj zdarzenia statusu wdrożenia przez webhooki i wyszukuj stan 'success'.

Typ zdarzenia inferred
Ponowne otwarcie zgłoszenia
Wcześniej zamknięte zgłoszenie zostaje ponownie aktywowane, zwykle dlatego, że poprawka okazała się niewystarczająca lub wykryto regresję. To jawne zdarzenie rozpoczyna cykl życia elementu prac rozwojowych od nowa.
Dlaczego to ważne

To sygnał istotnego powrotu do wcześniejszego etapu, który może oznaczać, że błąd przedostał się do produkcji lub poprawka była niepełna. Częstotliwość takich przypadków jest ważnym miernikiem ogólnej jakości oprogramowania.

Skąd pobrać

To jawne zdarzenie rejestrowane w strumieniu zdarzeń GitHub Issues API. Typ zdarzenia to 'reopened'.

Rejestrowanie

Nasłuchuj zdarzenia 'reopened' dla zgłoszenia za pomocą webhooków lub cyklicznego odpytywania API.

Typ zdarzenia explicit
Prośba o przegląd kodu
Autor pull request formalnie prosi wybrane osoby lub zespoły o przegląd kodu. To jawna czynność w interfejsie lub API GitHub, która wysyła powiadomienia do wskazanych recenzentów.
Dlaczego to ważne

Ta czynność oznacza formalne przekazanie kodu do przeglądu. Czas od tego momentu do przesłania recenzji pozwala ocenić, jak szybko recenzenci reagują, i wykryć potencjalne wąskie gardła.

Skąd pobrać

Zdarzenie jest rejestrowane w strumieniu zdarzeń GitHub Pull Request API lub przez webhooki. Wartość akcji zdarzenia to 'review_requested'.

Rejestrowanie

Nasłuchuj akcji 'review_requested' dla pull request.

Typ zdarzenia explicit
Przesłanie kodu do PR
Oznacza aktualizację kodu zgłoszonego do przeglądu, zarówno w ramach pierwszego PR, jak i w odpowiedzi na uwagi z przeglądu. Zdarzenie jest rejestrowane za każdym razem, gdy do gałęzi powiązanej z otwartym pull request zostaje przesłany nowy commit.
Dlaczego to ważne

Śledzenie tych zdarzeń pomaga wykrywać powroty do wcześniejszych etapów. Kolejne przesłania kodu po przeglądzie oznaczają, że potrzebne były zmiany, co wydłuża cały cykl.

Skąd pobrać

To jawne zdarzenie na osi czasu pull request, często opisane jako dodanie commita. Można je zarejestrować na podstawie webhooka 'push' lub monitorując commity powiązane z PR.

Rejestrowanie

Śledź zdarzenia 'push' w gałęzi powiązanej z otwartym pull request.

Typ zdarzenia explicit
Utworzenie gałęzi
Oznacza rozpoczęcie aktywnej pracy nad zgłoszeniem, gdy programista tworzy nową gałąź na podstawie głównej bazy kodu. Zdarzenie jest rejestrowane, gdy nowa gałąź zostaje przesłana do repozytorium. Jej nazwa często zawiera numer zgłoszenia.
Dlaczego to ważne

Oznacza przejście od planowania do aktywnego programowania. Pomiar czasu od utworzenia zgłoszenia do tego zdarzenia pomaga ocenić, jak szybko programista podejmuje pracę, i wykryć początkowe opóźnienia w zaległościach.

Skąd pobrać

Zdarzenie można zarejestrować za pomocą GitHub Git API lub webhooków nasłuchujących zdarzeń 'create' typu 'branch'. Często trzeba powiązać nazwę gałęzi ze zgłoszeniem na podstawie przyjętej konwencji, np. 'feature/issue-123'.

Rejestrowanie

Przetwarzaj zdarzenia webhooka 'create' dotyczące nowych gałęzi i przypisuj je do zgłoszeń.

Typ zdarzenia explicit
Zmiany wymagane po przeglądzie
Recenzent zakończył przegląd kodu i uznał, że przed zatwierdzeniem pull request trzeba wprowadzić zmiany. Formalnie przesyła recenzję ze statusem 'request_changes'.
Dlaczego to ważne

To zdarzenie jednoznacznie wskazuje powrót do wcześniejszego etapu. Analiza częstotliwości takich przypadków pomaga wykryć problemy z jakością, niejasne wymagania lub potrzebę szkolenia programistów.

Skąd pobrać

Zdarzenie jest rejestrowane w GitHub Pull Request API lub przez webhooki, gdy recenzja zostaje przesłana ze stanem 'CHANGES_REQUESTED'.

Rejestrowanie

Filtruj zdarzenia przesłania recenzji pull request według stanu 'CHANGES_REQUESTED'.

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z GitHub

Jak zacząć?

Wykorzystajcie Państwo ten szablon do przygotowania danych i rozpoczęcia optymalizacji cyklu życia tworzenia oprogramowania. Wykryjcie nieefektywne działania i usprawnijcie wydawanie oprogramowania.

Usprawnij SDLC: szybko wykrywaj nieefektywne działania

Skróć czas cyklu o 30% i usprawnij proces tworzenia oprogramowania w GitHub.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.