Szablon danych cyklu życia tworzenia oprogramowania
Szablon danych cyklu życia tworzenia oprogramowania
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące ekstrakcji
Atrybuty cyklu życia tworzenia oprogramowania
| 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
|
|||
Działania w cyklu życia tworzenia oprogramowania
| 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
|
|||
Instrukcje ekstrakcji danych
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.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.