Szablon danych cyklu rozwoju oprogramowania

GitLab
Szablon danych cyklu rozwoju oprogramowania

Szablon danych cyklu rozwoju oprogramowania

Ten szablon pokazuje, jakie dane są potrzebne do analizy procesu rozwoju oprogramowania. Zawiera zalecane atrybuty, najważniejsze aktywności do śledzenia oraz praktyczne wskazówki, jak pobrać te informacje bezpośrednio z GitLab. Dzięki niemu można przygotować dane do analizy process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze aktywności do śledzenia
  • Wskazówki dotyczące pobierania danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty cyklu rozwoju oprogramowania

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby analizować i usprawniać cały cykl rozwoju oprogramowania.
3 Wymagane 5 Zalecane 12 Opcjonalne
Nazwa Opis
Czas rozpoczęcia
StartTime
Znacznik czasu wskazujący, kiedy rozpoczęło się działanie lub wystąpiło zdarzenie.
Opis

StartTime wskazuje dokładną datę i godzinę wystąpienia danego działania. W przypadku zdarzeń GitLab wartość pochodzi z różnych pól ze znacznikami czasu. Na przykład StartTime działania „Utworzenie zgłoszenia” to znacznik czasu created_at zgłoszenia, a StartTime działania „Scalenie merge request” to znacznik czasu merged_at merge request.

Ten znacznik czasu jest podstawowym elementem analizy czasu w process mining. Służy do chronologicznego porządkowania zdarzeń, obliczania czasu między działaniami, mierzenia czasu cyklu i analizy wyników procesu w czasie.

Dlaczego to ważne

Atrybut ten określa chronologiczną kolejność zdarzeń. Jest niezbędny do obliczania wszystkich miar opartych na czasie i zrozumienia przebiegu procesu.

Skąd pobrać

Dane pochodzą z różnych pól ze znacznikami czasu w GitLab, takich jak 'created_at', 'updated_at' i 'closed_at' w zgłoszeniach oraz 'merged_at' w merge requestach.

Przykłady
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Działanie
Activity
Nazwa konkretnego kroku procesu lub zdarzenia, na przykład „Utworzenie zgłoszenia” albo „Scalenie merge request”.
Opis

Atrybut Działanie obejmuje poszczególne zdarzenia dotyczące elementu pracy programistycznej. W GitLab nie są one zapisane w jednym polu, lecz wynikają z różnych działań i pól ze znacznikami czasu w zgłoszeniach, merge requestach i pipeline’ach CI/CD. Przykładowe działania to utworzenie zgłoszenia, wypchnięcie commitu, niepowodzenie pipeline’u i zatwierdzenie merge request.

Atrybut ten jest podstawą mapy procesu. Pozwala przedstawić workflow oraz analizować kolejność i częstotliwość zdarzeń. Służy do wykrywania odstępstw, wąskich gardeł między etapami i typowych ścieżek procesu.

Dlaczego to ważne

Określa kroki na mapie procesu, umożliwiając przedstawienie i analizę workflow wytwarzania oprogramowania od początku do końca.

Skąd pobrać

Wartość jest wyznaczana na podstawie typów zdarzeń i zmian stanu w strumieniu zdarzeń GitLab lub przez interpretację pól ze znacznikami czasu, takich jak 'created_at', 'merged_at' i 'closed_at' w zgłoszeniach i merge requestach.

Przykłady
Utworzenie zgłoszeniaRozpoczęcie prac programistycznychScalenie merge requestNiepowodzenie pipeline’uWdrożenie na produkcję
Element pracy programistycznej
DevelopmentItem
Unikalny identyfikator jednostki pracy, na przykład funkcji, poprawki błędu lub zadania. Służy jako główny identyfikator case.
Opis

Element pracy programistycznej to pojedyncza, możliwa do śledzenia jednostka pracy przechodząca przez cykl wytwarzania oprogramowania. Łączy wszystkie powiązane działania, od utworzenia po wdrożenie, w jeden spójny case. W GitLab jest to zwykle wewnętrzny identyfikator zgłoszenia (IID), unikalny w obrębie projektu.

Analiza według elementu pracy programistycznej pozwala mierzyć czas cyklu od początku do końca, wykrywać wąskie gardła i sprawdzać zgodność procesu. Stanowi podstawę oceny, jak sprawnie praca przechodzi od pomysłu do wdrożenia na produkcję.

Dlaczego to ważne

To podstawowy identyfikator case, który łączy wszystkie zdarzenia procesu i pozwala prześledzić pełny cykl życia danego elementu pracy.

Skąd pobrać

Zwykle jest to wewnętrzny identyfikator (IID) zgłoszenia GitLab. Można go znaleźć w odpowiedzi Issues API w polu 'iid'.

Przykłady
1024512PRJ-2345
Czas zakończenia
EndTime
Znacznik czasu wskazujący, kiedy zakończyło się działanie lub zdarzenie.
Opis

EndTime wskazuje dokładną datę i godzinę zakończenia działania. W przypadku wielu pojedynczych zdarzeń w GitLab, takich jak „Utworzenie zgłoszenia”, EndTime jest taki sam jak StartTime. W przypadku działań trwających przez pewien czas, na przykład przeglądu kodu, oznacza moment ich zakończenia, na przykład udzielenia ostatniego zatwierdzenia.

Atrybut ten jest niezbędny do dokładnego obliczania czasu trwania poszczególnych działań (czasu przetwarzania). Ułatwia szczegółową analizę wąskich gardeł, ponieważ pozwala odróżnić czas aktywnej pracy nad zadaniem od czasu oczekiwania między zadaniami.

Dlaczego to ważne

Pozwala dokładnie obliczać czas trwania działań (czas przetwarzania), co pomaga wykrywać nieefektywne etapy procesu.

Skąd pobrać

W przypadku pojedynczych zdarzeń jest taki sam jak StartTime. Dla działań trwających przez pewien czas należy go ustalić na podstawie odpowiadającego im zdarzenia zakończenia w danych.

Przykłady
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Nazwa projektu
ProjectName
Nazwa projektu GitLab, do którego należy element pracy programistycznej.
Opis

Atrybut ten wskazuje konkretne repozytorium kodu lub projekt, w którym wykonywana jest praca. W GitLab każde zgłoszenie i każdy merge request należą do projektu.

Analiza według nazwy projektu pozwala porównywać wyniki dla różnych produktów, komponentów i usług. Pomaga sprawdzić, czy procesy SDLC w niektórych projektach przebiegają sprawniej niż w innych. Ułatwia też filtrowanie dashboardów do wybranego obszaru.

Dlaczego to ważne

Pozwala dzielić analizę procesu według produktu, aplikacji lub komponentu i kierować działania usprawniające do konkretnych obszarów.

Skąd pobrać

Dane pochodzą z pól 'name' lub 'path_with_namespace' w Project API. Projekt jest powiązany ze zgłoszeniami i merge requestami przez pole 'project_id'.

Przykłady
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Osoba przypisana
Assignee
Użytkownik przypisany do zgłoszenia lub merge request w chwili wystąpienia zdarzenia.
Opis

Osoba przypisana to programista lub użytkownik odpowiedzialny za element pracy na danym etapie procesu. W GitLab informacja ta znajduje się w polu assignee lub assignees zgłoszenia albo merge request.

Analiza według osoby przypisanej jest ważna dla dashboardu „Obciążenie i alokacja pracy programistów”. Pomaga ocenić wykorzystanie zasobów, wykryć przeciążone osoby lub zespoły oraz analizować przekazywanie pracy między osobami.

Dlaczego to ważne

Wskazuje, kto wykonał pracę, co umożliwia analizę obciążenia, efektywności alokacji zasobów i opóźnień związanych z przekazywaniem zadań.

Skąd pobrać

Dane pochodzą z pól 'assignee.username' lub 'assignees' w odpowiedziach GitLab Issues API i Merge Requests API.

Przykłady
jdoeasmithr.williams
Poziom ważności
Severity
Poziom ważności elementu pracy programistycznej, zwykle błędu lub incydentu.
Opis

Poziom ważności określa wpływ błędu lub problemu, od krytycznego do niewielkiego. GitLab nie ma wbudowanego pola poziomu ważności, dlatego niemal zawsze wykorzystuje się do tego etykiety, na przykład 'severity::1' lub 'severity::2'.

Atrybut ten jest niezbędny na dashboardzie „Zmiany poziomu ważności” i do obliczania powiązanego KPI. Analiza zmian poziomu ważności w cyklu życia może ujawnić problemy początkowo uznane za mniej poważne lub procesy, które pogłębiają problemy.

Dlaczego to ważne

Pomaga ustalać priorytety i sprawdzać, czy elementy o wysokim poziomie ważności są obsługiwane szybciej. Śledzenie zmian pozwala obliczać KPI „Częstotliwość eskalacji poziomu ważności”.

Skąd pobrać

Wartość ustala się na podstawie etykiet 'labels' przypisanych do zgłoszenia GitLab. Potrzebne jest mapowanie, które pozwoli interpretować etykiety takie jak 'S1' i 'S2' jako poziomy ważności.

Przykłady
1 - Krytyczny2 - Wysoki3 - Średni4 - Niski
Typ elementu pracy programistycznej
DevelopmentItemType
Klasyfikacja elementu pracy programistycznej, na przykład „Funkcja”, „Błąd”, „Zadanie” lub „Utrzymanie”.
Opis

Atrybut ten określa rodzaj wykonywanej pracy. W GitLab zwykle wykorzystuje się do tego etykiety zgłoszeń. Zespoły oznaczają nimi nowe funkcje, poprawki błędów, dług techniczny i inne rodzaje pracy.

Analiza według typu elementu pracy programistycznej pozwala porównywać przebieg procesów i czasy cyklu dla różnych rodzajów pracy. Można na przykład sprawdzić, czy błędy są usuwane szybciej niż powstają nowe funkcje albo czy zadania związane z długiem technicznym przechodzą inny przegląd.

Dlaczego to ważne

Podział procesu według rodzaju pracy pomaga ustalić, które rodzaje zadań częściej wiążą się z opóźnieniami, poprawkami lub odstępstwami.

Skąd pobrać

Wartość zwykle ustala się na podstawie etykiet 'labels' przypisanych do zgłoszenia GitLab. Potrzebne jest mapowanie, które przypisze konkretne etykiety do standardowych typów.

Przykłady
FunkcjaBłądZadanieDług techniczny
Czas oczekiwania przy przekazaniu pracy
HandoffWaitTime
Obliczany czas bezczynności między dwiema kolejnymi aktywnościami wykonanymi przez różne osoby.
Opis

Ta miara określa czas między zakończeniem jednej aktywności a rozpoczęciem kolejnej, gdy zmienia się osoba przypisana do zadania. Na przykład mierzy czas od zakończenia pracy przez programistę do rozpoczęcia przeglądu kodu przez recenzenta.

To główna miara KPI „Średni czas oczekiwania przy przekazaniu pracy”. Pomaga wykrywać ukryte problemy z przydziałem zasobów i komunikacją między zespołami lub osobami. Pokazuje opóźnienia, które nie wynikają z aktywnej pracy.

Dlaczego to ważne

Mierzy czas bezczynności podczas przekazywania pracy między osobami lub zespołami, ujawniając ukryte opóźnienia i problemy z komunikacją.

Skąd pobrać

Obliczany przez narzędzie process mining. Wymaga analizy kolejnych zdarzeń w sprawie, sprawdzenia, czy wartość „Assignee” się zmieniła, a następnie obliczenia różnicy czasu.

Przykłady
1 dzień 2 godziny15 minut8 godzin
Czas realizacji
CycleTime
Łączny czas od pierwszej do ostatniej aktywności dotyczącej elementu prac rozwojowych.
Opis

Czas realizacji to obliczana miara całkowitego czasu trwania sprawy. Zwykle wyznacza się go jako różnicę między pierwszym zdarzeniem, na przykład „Utworzono zgłoszenie”, a ostatnim, na przykład „Wdrożono na produkcję”, dla jednego elementu prac rozwojowych.

To podstawowy KPI służący do pomiaru ogólnej efektywności procesu. Jest główną miarą na dashboardach takich jak „Czas realizacji SDLC od początku do końca”. Pomaga śledzić usprawnienia i wykrywać długo trwające sprawy, które mogą wskazywać na problemy systemowe.

Dlaczego to ważne

To podstawowy KPI process mining, który mierzy efektywność całego cyklu rozwoju oprogramowania.

Skąd pobrać

Obliczany przez narzędzie process mining jako różnica między najwcześniejszą a najpóźniejszą wartością StartTime dla każdego unikalnego CaseId.

Przykłady
10 dni 4 godziny23 godziny 15 minut35 dni
Czy wystąpiły poprawki
IsRework
Wartość logiczna wskazująca, czy aktywność jest częścią pętli poprawek.
Opis

Ten obliczany atrybut oznacza aktywności wskazujące na cofnięcie się w procesie, na przykład powrót do programowania po rozpoczęciu testów. Zwykle ustala się go na podstawie określonych sekwencji aktywności. Przykładem może być zdarzenie „Rozpoczęto programowanie” występujące po zdarzeniu „Błąd pipeline” lub „Rozpoczęto testy QA” w tej samej sprawie.

Atrybut ten zasila dashboard „Analiza poprawek i ponownych uruchomień” oraz KPI „Odsetek poprawek po testach”. Ułatwia filtrowanie i mierzenie dodatkowej pracy, dzięki czemu zespoły mogą poznać jej częstotliwość, przyczyny i wpływ na harmonogram projektu.

Dlaczego to ważne

Bezpośrednio oznacza i mierzy dodatkową pracę, ułatwiając analizę przyczyn oraz wpływu nieefektywności procesu i problemów z jakością.

Skąd pobrać

Obliczany przez narzędzie process mining na podstawie sekwencji aktywności w każdej sprawie i wzorców wskazujących na poprawki.

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

Atrybut ten zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych o zdarzeniu w zbiorze danych process mining. Nie wskazuje, kiedy zdarzenie wystąpiło, lecz kiedy jego zapis został ostatnio zsynchronizowany.

Informacja ta pozwala ocenić aktualność danych i sprawdzić, czy analiza procesu opiera się na świeżych danych. Użytkownicy mogą też ustalić, z jakim opóźnieniem dane z systemu źródłowego trafiają do analizy.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak świeża jest analiza procesu.

Skąd pobrać

Ten znacznik czasu jest generowany i zapisywany przez narzędzie do pobierania danych lub proces ETL podczas odświeżania danych.

Przykłady
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Gałąź docelowa
TargetBranch
Nazwa gałęzi, do której ma zostać scalony merge request.
Opis

Gałąź docelowa to gałąź, do której mają trafić zmiany, na przykład „main”, „develop” lub gałąź wydania, taka jak „release/1.5”. To podstawowa informacja o każdym merge requeście.

Analiza według gałęzi docelowej może ujawnić różnice w przebiegu prac nad kodem scalanym do różnych gałęzi. Na przykład scalanie do „main” może wymagać dokładniejszego zatwierdzania i trwać dłużej niż scalanie do gałęzi funkcjonalnej. Pozwala też odróżnić wdrożenia produkcyjne od innych form integracji kodu.

Dlaczego to ważne

Ułatwia rozróżnienie workflow związanych z rozwojem i wydaniami, ponieważ przebieg prac może się znacznie różnić w zależności od gałęzi docelowej.

Skąd pobrać

Pobierana z pola „target_branch” w odpowiedzi GitLab Merge Requests API.

Przykłady
głównarozwojowawydanie/v2.1.0poprawka-błędu-uwierzytelniania-użytkownika
Nazwa kamienia milowego
MilestoneTitle
Tytuł kamienia milowego lub sprintu, do którego przypisano element prac rozwojowych.
Opis

W GitLab kamienie milowe służą do śledzenia prac związanych z konkretnym celem lub okresem, na przykład sprintem albo wersją wydania. Ten atrybut zawiera nazwę lub tytuł kamienia milowego.

Dzięki niemu można analizować przebieg procesu w ramach konkretnych sprintów lub okresów planowania. Można sprawdzić, czy czas realizacji skraca się z jednego sprintu na kolejny, albo ograniczyć widok procesu do prac związanych z nadchodzącym wydaniem.

Dlaczego to ważne

Łączy prace programistyczne z cyklami planowania, takimi jak sprinty i wydania, co pozwala oceniać wyniki w odniesieniu do zaplanowanych okresów.

Skąd pobrać

Pobierany z pola „milestone.title” w odpowiedzi GitLab Issues API lub Merge Requests API.

Przykłady
Wydanie za IV kwartał 2023Sprint 23.11Etap 1: MVP
Nazwa zespołu
TeamName
Zespół programistyczny powiązany z projektem lub osobą przypisaną.
Opis

Nazwa zespołu wskazuje grupę lub squad odpowiedzialny za element pracy programistycznej. Zwykle nie jest to standardowe pole w GitLab. Informację tę często ustala się na podstawie konwencji nazewniczych projektów, struktury grup lub zewnętrznej tabeli przypisującej użytkowników do zespołów.

Atrybut ten służy do analizy wyników procesu na poziomie zespołu. Ułatwia porównywanie efektywności, obciążenia i przestrzegania procesu w różnych zespołach. Pozwala też analizować dane zespołowe na dashboardach, takich jak „Analiza wąskich gardeł na poszczególnych etapach”.

Dlaczego to ważne

Umożliwia analizę wyników i porównywanie procesów między zespołami, pomagając wykrywać wąskie gardła charakterystyczne dla danego zespołu oraz dobre praktyki.

Skąd pobrać

Wartość często ustala się przez przypisanie projektu lub osoby do struktury zespołów zdefiniowanej poza GitLab albo na podstawie hierarchii grup w GitLab.

Przykłady
Frontend-AlphaBackend-ServicesPlatform-Infra
Status elementu pracy programistycznej
DevelopmentItemStatus
Status elementu pracy programistycznej w chwili wystąpienia zdarzenia, na przykład „Otwarte”, „W trakcie” lub „Zamknięte”.
Opis

Atrybut ten odzwierciedla stan głównego elementu pracy, którym zwykle jest zgłoszenie w GitLab. Zgłoszenia GitLab mają pole state o wartości 'opened' lub 'closed'. Bardziej szczegółowe statusy często są określane za pomocą etykiet z zakresem, na przykład 'Status::Triage', 'Status::In-Dev' lub 'Status::In-Review'.

Śledzenie zmian statusu jest niezbędne do zrozumienia cyklu życia case. Pozwala ustalić, jak długo elementy pozostają w poszczególnych stanach, oraz filtrować aktywne i zakończone prace na dashboardach, takich jak „Czas cyklu SDLC od początku do końca”.

Dlaczego to ważne

Pokazuje stan case, umożliwiając analizę czasu spędzonego na poszczególnych etapach oraz filtrowanie trwających i zakończonych prac.

Skąd pobrać

Podstawowy status pochodzi z pola 'state' zgłoszenia GitLab ('opened', 'closed'). Bardziej szczegółowe statusy często ustala się na podstawie etykiet.

Przykłady
otwartezamknięteW trakcieW przeglądzie
Status merge requestu
MergeRequestStatus
Status merge requestu powiązanego ze zdarzeniem, na przykład „otwarty”, „scalony” lub „zamknięty”.
Opis

Ten atrybut określa stan merge requestu (MR) w chwili wystąpienia zdarzenia. W GitLab MR może mieć jeden z kilku stanów: „opened”, „closed”, „merged” lub „locked”. Nie jest to to samo co ogólny status elementu prac rozwojowych.

Śledzenie statusu MR pozwala analizować etap integracji kodu w cyklu SDLC. Dane te zasilają między innymi dashboard „Czas przeglądu kodu i przepustowość” oraz pomagają wykryć opóźnienia między utworzeniem MR, przeglądem, zatwierdzeniem i scaleniem.

Dlaczego to ważne

Pokazuje przebieg przeglądu i scalania kodu, który często jest wąskim gardłem w cyklu SDLC.

Skąd pobrać

Pobierany z pola „state” w odpowiedzi GitLab Merge Requests API.

Przykłady
otwartescalonyzamkniętezablokowany
Status pipeline
PipelineStatus
Status uruchomienia pipeline CI/CD, na przykład „zakończony powodzeniem”, „niepowodzenie” lub „w toku”.
Opis

Ten atrybut wskazuje wynik wykonania pipeline CI/CD powiązanego z commitem lub merge requestem. Typowe statusy w GitLab to „running”, „pending”, „success”, „failed”, „canceled” i „skipped”.

Dane te są niezbędne do dashboardu „Analiza poprawek i ponownych uruchomień”. Częste błędy pipeline mogą powodować dodatkową pracę i opóźnienia. Analiza ich częstotliwości, miejsca występowania i wpływu pomaga zwiększyć efektywność prac programistycznych oraz jakość kodu.

Dlaczego to ważne

Śledzi powodzenie i niepowodzenia automatycznych kompilacji oraz testów, wskazując powtarzające się poprawki i problemy z jakością kodu lub automatyzacją testów.

Skąd pobrać

Pobierany z pola „status” w odpowiedzi GitLab CI/CD Pipelines API.

Przykłady
powodzenieniepowodzeniew tokuanulowany
System źródłowy
SourceSystem
Wskazuje system, z którego pochodzą dane.
Opis

Atrybut ten określa źródło danych o procesie. W tym modelu danych jego wartością będzie zawsze 'GitLab'.

Atrybut jest przydatny w środowiskach, w których dane o procesie pochodzą z wielu systemów, na przykład z Jira do planowania i z GitLab do realizacji. Umożliwia filtrowanie i segmentację oraz pomaga zachować informacje o pochodzeniu danych.

Dlaczego to ważne

Jasno wskazuje pochodzenie danych, co ma znaczenie dla zarządzania danymi i łączenia informacji z wielu systemów firmowych.

Skąd pobrać

To stała wartość 'GitLab', dodawana podczas przekształcania danych.

Przykłady
GitLab
Wersja wydania
ReleaseVersion
Planowana lub faktyczna wersja oprogramowania powiązana z wdrożeniem.
Opis

Ten atrybut wskazuje konkretne wydanie oprogramowania, którego częścią jest dany element prac rozwojowych. W GitLab można je powiązać z kamieniem milowym, chronionym tagiem lub wpisem w funkcjach Releases.

Atrybut ten jest niezbędny do dashboardu „Śledzenie zgodności z harmonogramem wydań”. Porównując faktyczną datę wdrożenia z planowaną datą przypisaną do wersji wydania, można ocenić, czy organizacja dotrzymuje harmonogramu, i ustalić przyczyny opóźnień.

Dlaczego to ważne

Łączy elementy prac rozwojowych z konkretnym wydaniem oprogramowania, co ułatwia śledzenie postępów i zgodności z harmonogramem.

Skąd pobrać

Źródłem może być GitLab Releases, nazwa tagu git lub tytuł kamienia milowego używanego do planowania wydania.

Przykłady
v1.2.0v3.0.0-beta2023.4.1
Wymagane Zalecane Opcjonalne

Aktywności w cyklu rozwoju oprogramowania

To najważniejsze etapy procesu i kamienie milowe, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie odtworzyć przebieg procesu i wykryć wąskie gardła.
4 Zalecane 8 Opcjonalne
Działanie Opis
Scalenie merge request
To zdarzenie oznacza pomyślne zakończenie przeglądu i integracji kodu. Występuje, gdy użytkownik scala gałąź merge request z gałęzią docelową.
Dlaczego to ważne

To ważny etap oznaczający zakończenie programowania i przeglądu. Wyznacza koniec pomiaru czasu cyklu wytwarzania oprogramowania i początek pomiaru czasu do wdrożenia.

Skąd pobrać

To jawnie rejestrowane zdarzenie, którego źródłem jest znacznik czasu 'merged_at' w tabeli 'merge_requests'. Po scaleniu generowana jest również notatka systemowa.

Rejestrowanie

Należy użyć znacznika czasu 'merged_at' merge request.

Typ zdarzenia explicit
Utworzenie merge request
Oznacza zakończenie początkowych prac programistycznych i gotowość kodu do przeglądu oraz integracji. To jawne, podstawowe zdarzenie w workflow GitLab, rejestrowane w chwili utworzenia merge request (MR) przez programistę.
Dlaczego to ważne

To ważny etap, który oznacza przekazanie pracy z programowania do przeglądu i testów. Rozpoczyna analizę całego cyklu przeglądu kodu i pipeline’u CI/CD.

Skąd pobrać

To jawnie rejestrowane zdarzenie, którego źródłem jest znacznik czasu 'created_at' w tabeli 'merge_requests' lub dane z Merge Requests API.

Rejestrowanie

Należy użyć znacznika czasu 'created_at' merge request.

Typ zdarzenia explicit
Utworzenie zgłoszenia
To zdarzenie rozpoczyna cykl wytwarzania oprogramowania i oznacza utworzenie nowego elementu pracy, na przykład funkcji, błędu lub zadania. Jest rejestrowane w chwili utworzenia zgłoszenia w GitLab, który zapisuje znacznik czasu.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces od początku do końca. Analiza czasu od utworzenia zgłoszenia do wdrożenia pokazuje pełny czas cyklu SDLC.

Skąd pobrać

To jawnie rejestrowane zdarzenie, którego źródłem jest znacznik czasu 'created_at' w tabeli 'issues' lub dane z Issues API. Utworzenie zgłoszenia jest również zapisywane w notatkach systemowych.

Rejestrowanie

Należy użyć znacznika czasu 'created_at' zgłoszenia.

Typ zdarzenia explicit
Wdrożenie na produkcję
To zdarzenie oznacza pomyślne wdrożenie kodu w środowisku produkcyjnym, dzięki czemu staje się on dostępny dla użytkowników końcowych. Jest rejestrowane po pomyślnym zakończeniu konkretnego zadania 'deploy to production' w pipeline’ie CI/CD GitLab.
Dlaczego to ważne

To główne zdarzenie kończące proces i oznaczające dostarczenie wartości. Jest niezbędne do pomiaru całkowitego czasu cyklu SDLC od początku do końca oraz częstotliwości wydań.

Skąd pobrać

Dane pochodzą ze znacznika czasu 'finished_at' pomyślnie zakończonego zadania CI/CD przeznaczonego do wdrożenia na produkcję. Funkcja Environments w GitLab jawnie śledzi to zdarzenie.

Rejestrowanie

Należy użyć znacznika czasu 'finished_at' z pomyślnie zakończonego zadania CI wdrażającego na produkcję.

Typ zdarzenia explicit
Dodanie zatwierdzenia
Oznacza formalne zatwierdzenie zmian w kodzie w merge request przez osobę sprawdzającą. GitLab jawnie rejestruje to zdarzenie, gdy użytkownik kliknie przycisk 'Approve'.
Dlaczego to ważne

Zatwierdzenia są ważnymi punktami kontroli jakości. Ich śledzenie pozwala analizować czas potrzebny na uzyskanie wymaganych akceptacji i sprawdzać zgodność z zasadami przeglądu kodu.

Skąd pobrać

Dane pochodzą ze zdarzeń zatwierdzenia merge request. Są dostępne przez Approvals API lub w historii MR.

Rejestrowanie

Należy użyć znacznika czasu ze zdarzenia zatwierdzenia merge request w dzienniku zdarzeń.

Typ zdarzenia explicit
Niepowodzenie pipeline’u
To zdarzenie występuje, gdy wykonanie pipeline’u CI/CD kończy się niepowodzeniem na dowolnym etapie, na przykład z powodu błędu kompilacji lub niezaliczonego testu. GitLab jawnie zapisuje końcowy status każdego pipeline’u, dzięki czemu łatwo wykryć niepowodzenia.
Dlaczego to ważne

Niepowodzenia pipeline’ów są częstą przyczyną poprawek. Analiza ich częstotliwości, czasu trwania i przyczyn pomaga wykryć problemy z jakością, niestabilne testy i wąskie gardła w przekazywaniu informacji zwrotnej programistom.

Skąd pobrać

Zdarzenie rozpoznaje się po statusie 'failed' rekordu pipeline’u w tabeli 'ci_pipelines'. Znacznik czasu 'finished_at' wskazuje, kiedy wystąpiło niepowodzenie.

Rejestrowanie

Należy wybrać rekordy pipeline’ów ze statusem 'failed' i użyć znacznika czasu 'finished_at'.

Typ zdarzenia explicit
Przypisanie zgłoszenia
Oznacza przypisanie zgłoszenia konkretnemu programiście lub zespołowi, czyli wskazanie osoby odpowiedzialnej za pracę. GitLab jawnie rejestruje to zdarzenie za każdym razem, gdy pole osoby przypisanej do zgłoszenia zostaje wypełnione lub zmienione.
Dlaczego to ważne

Śledzenie przypisań jest ważne przy analizie alokacji zasobów, obciążenia zespołów i czasu przekazywania pracy. Pomaga wykryć opóźnienia między utworzeniem pracy a jej podjęciem.

Skąd pobrać

Dane pochodzą z notatek systemowych GitLab dotyczących zgłoszenia. Zapisują one dodanie lub zmianę wartości 'assignee'. Znacznik czasu zdarzenia znajduje się w notatce.

Rejestrowanie

Należy pobrać zdarzenia 'assignee changed' z notatek systemowych zgłoszenia.

Typ zdarzenia explicit
Rozpoczęcie prac programistycznych
To zdarzenie oznacza rozpoczęcie aktywnego programowania w ramach zgłoszenia. Zwykle jest ustalane na podstawie pierwszego commitu wypchniętego do powiązanej gałęzi, ponieważ GitLab nie ma jawnego przycisku „rozpocznij programowanie”.
Dlaczego to ważne

Pozwala dokładnie określić początek prac programistycznych, które przynoszą wartość. Dzięki temu można precyzyjnie zmierzyć czas samego programowania i oddzielić go od planowania oraz oczekiwania w kolejce.

Skąd pobrać

Zdarzenie ustala się na podstawie znacznika czasu pierwszego commitu w gałęzi funkcji powiązanej ze zgłoszeniem. Wymaga to połączenia zgłoszeń z gałęziami, zwykle na podstawie konwencji nazewniczych lub metadanych.

Rejestrowanie

Należy znaleźć znacznik czasu pierwszego commitu w gałęzi powiązanej z identyfikatorem zgłoszenia.

Typ zdarzenia inferred
Rozpoczęcie przeglądu kodu
Oznacza początek wzajemnego przeglądu kodu w ramach merge request. Zdarzenie ustala się na podstawie pierwszej czynności związanej z przeglądem, na przykład pierwszego komentarza lub wpisu w wątku dodanego przez osobę inną niż autor.
Dlaczego to ważne

Pomiar czasu od utworzenia MR do rozpoczęcia przeglądu ujawnia opóźnienia w kolejce. Skrócenie oczekiwania pomaga skrócić cały cykl przeglądu kodu.

Skąd pobrać

Zdarzenie ustala się na podstawie znacznika czasu pierwszego komentarza lub wątku przeglądu w merge request, dodanego przez osobę inną niż autor MR. Dane są dostępne w notatkach systemowych lub przez Notes API.

Rejestrowanie

Należy znaleźć znacznik czasu pierwszego komentarza w MR dodanego przez użytkownika innego niż autor.

Typ zdarzenia inferred
Rozpoczęcie wdrożenia
Oznacza rozpoczęcie procesu wdrażania kodu w określonym środowisku, na przykład testowym lub produkcyjnym. W GitLab odpowiada rozpoczęciu zadania 'deploy' w pipeline’ie CI/CD.
Dlaczego to ważne

Śledzenie początku wdrożenia pozwala określić czas trwania tej fazy. Jest niezbędne do pomiaru i skracania czasu do wdrożenia.

Skąd pobrać

Dane pochodzą ze znacznika czasu 'started_at' zadania CI/CD skonfigurowanego jako zadanie wdrożeniowe. Jest to część funkcji Environments and Deployments w GitLab.

Rejestrowanie

Należy użyć znacznika czasu 'started_at' z dziennika zadania CI dotyczącego wdrożenia.

Typ zdarzenia explicit
Uruchomienie pipeline’u
Oznacza uruchomienie automatycznego pipeline’u CI/CD, który zwykle wykonuje kompilacje, testy i skanowanie bezpieczeństwa. Po uruchomieniu pipeline’u, na przykład w wyniku commitu lub utworzenia MR, GitLab jawnie zapisuje jego rekord i znacznik czasu rozpoczęcia.
Dlaczego to ważne

Śledzenie uruchomień pipeline’ów jest niezbędne do monitorowania stanu i efektywności automatycznych testów oraz integracji. Pozwala ustalić, ile czasu zajmuje automatyczna weryfikacja.

Skąd pobrać

Dane pochodzą ze znacznika czasu 'created_at' lub 'started_at' rekordu pipeline’u w tabeli 'ci_pipelines' albo z Pipelines API.

Rejestrowanie

Należy użyć znacznika czasu z rekordu wykonania pipeline’u powiązanego z gałęzią MR.

Typ zdarzenia explicit
Zamknięcie zgłoszenia
Oznacza ostateczne, administracyjne zamknięcie elementu pracy, zwykle po wdrożeniu i weryfikacji zmian. GitLab jawnie rejestruje to zdarzenie, gdy użytkownik zamyka zgłoszenie.
Dlaczego to ważne

Zamknięcie zgłoszenia często oznacza koniec wszystkich powiązanych prac. Porównanie tego momentu z czasem wdrożenia może ujawnić opóźnienia w weryfikacji po wdrożeniu lub procesach administracyjnych.

Skąd pobrać

To jawnie rejestrowane zdarzenie, którego źródłem jest znacznik czasu 'closed_at' w tabeli 'issues' lub odpowiednia notatka systemowa.

Rejestrowanie

Należy użyć znacznika czasu 'closed_at' zgłoszenia.

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z GitLab

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby przygotować dane i rozpocząć usprawnianie cyklu rozwoju oprogramowania. Zacznij analizować przebieg procesu.

Usprawnij cykl rozwoju oprogramowania, zacznij już teraz

Ogranicz wąskie gardła w SDLC, skróć czas realizacji o 30% i popraw jakość.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Optymalizację można rozpocząć od razu.