Szablon danych cyklu rozwoju oprogramowania
Szablon danych cyklu rozwoju oprogramowania
- Zalecane atrybuty do zebrania
- Najważniejsze aktywności do śledzenia
- Wskazówki dotyczące pobierania danych
Atrybuty cyklu rozwoju oprogramowania
| 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 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 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 Ś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
|
|||
Aktywności w cyklu rozwoju oprogramowania
| 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
|
|||
Instrukcje pobierania danych
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ść.
Karta kredytowa nie jest wymagana. Optymalizację można rozpocząć od razu.