Yazılım Geliştirme Yaşam Döngüsü Veri Template'iniz

GitLab
Yazılım Geliştirme Yaşam Döngüsü Veri `Template`'iniz

Yazılım Geliştirme Yaşam Döngüsü Veri Template'iniz

Bu kapsamlı şablon, Yazılım Geliştirme Yaşam Döngüsü sürecinizi analiz etmek için gereken temel veri noktalarında size rehberlik eder. Toplanması gereken kritik öznitelikleri, izlenecek temel aktiviteleri özetler ve bu bilgileri doğrudan GitLab'den çıkarmak için pratik rehberlik sağlar. Bu kaynakla, verilerinizi anlamlı süreç madenciliği için güvenle hazırlayabilirsiniz.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • Veri Çekim Rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Yazılım Geliştirme Yaşam Döngüsü Öznitelikleri

Bunlar, kapsamlı yazılım geliştirme yaşam döngüsü analizi ve optimizasyonu için olay günlüğünüze dahil etmeniz önerilen veri alanlarıdır.
3 Gerekli 5 Önerilen 13 İsteğe Bağlı
Ad Açıklama
Aktivite
Activity
Meydana gelen belirli süreç adımının veya olayın adı, örneğin 'Sorun Oluşturuldu' veya 'Birleştirme İsteği Birleştirildi'.
Açıklama

Aktivite özniteliği, bir Geliştirme Öğesinde meydana gelen belirgin olayları yakalar. Bunlar GitLab'de tek bir alan olarak saklanmaz, ancak Issues, Merge Requests ve CI/CD Pipeline'ları genelindeki çeşitli eylemlerden ve zaman damgası alanlarından türetilir. Örneğin, bir sorunun oluşturulması, bir commit'in gönderilmesi, bir pipeline'ın başarısız olması veya bir birleştirme isteğinin onaylanması hepsi farklı aktivitelerdir.

Bu öznitelik, süreç haritası oluşturmak, iş akışını görselleştirmek ve olayların sırasını ve sıklığını analiz etmek için temeldir. Sapmaları, adımlar arasındaki darboğazları ve ortak süreç yollarını belirlemek için kullanılır.

Neden önemli

Süreç haritasındaki adımları tanımlar, uçtan uca geliştirme iş akışının görselleştirilmesine ve analiz edilmesine olanak tanır.

Nereden alınır

GitLab'in olay akışındaki event türlerinden ve durum değişikliklerinden veya Sorunlar (Issues) ve Birleştirme İstekleri (Merge Requests) üzerindeki 'created_at', 'merged_at' ve 'closed_at' gibi timestamp alanlarını yorumlayarak türetilmiştir.

Örnekler
Sorun OluşturulduGeliştirme BaşladıBirleştirme İsteği BirleştirildiPipeline Başarısız OlduÜretime Dağıtıldı
Başlangıç Zamanı
StartTime
Bir etkinlik veya olayın ne zaman başladığını gösteren `timestamp` (zaman damgası).
Açıklama

StartTime, belirli bir aktivitenin meydana geldiği kesin tarihi ve saati işaretler. GitLab'deki olaylar için bu, çeşitli zaman damgası alanlarında yakalanır. Örneğin, 'Sorun Oluşturuldu' aktivitesinin StartTime'ı sorunun created_at zaman damgası olurken, 'Birleştirme İsteği Birleştirildi' aktivitesinin StartTime'ı birleştirme isteğinin merged_at zaman damgası olacaktır.

Bu zaman damgası, süreç madenciliğindeki temel zamansal öğedir. Olayları kronolojik olarak sıralamak, aktiviteler arasındaki süreleri hesaplamak, döngü sürelerini ölçmek ve zaman içindeki süreç performansını analiz etmek için kullanılır.

Neden önemli

Bu öznitelik, tüm zaman tabanlı metrikleri hesaplamak ve süreç akışını anlamak için temel olan kronolojik olay dizisini sağlar.

Nereden alınır

GitLab'deki çeşitli timestamp alanlarından, örneğin sorunlardaki 'created_at', 'updated_at', 'closed_at' ve birleştirme isteklerindeki 'merged_at' alanlarından çıkarılmıştır.

Örnekler
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Geliştirme Öğesi
DevelopmentItem
Bir özellik, hata düzeltmesi veya görev gibi bir iş birimi için benzersiz tanımlayıcı, birincil vaka tanımlayıcısı olarak hizmet verir.
Açıklama

Geliştirme Öğesi, yazılım geliştirme yaşam döngüsü boyunca akan tek, izlenebilir bir iş parçasını temsil eder. Oluşturulmasından nihai dağıtımına kadar tüm ilgili aktiviteleri tutarlı bir vakaya bağlar. GitLab'de bu, genellikle bir proje içinde benzersiz olan Issue'nun dahili Kimliği (IID) ile temsil edilir.

Geliştirme Öğesine göre analiz, uçtan uca döngü süresi ölçümü, darboğaz tespiti ve süreç uygunluk kontrolü sağlar. İşin konseptten prodüksiyona ne kadar verimli bir şekilde teslim edildiğini anlamanın temelini oluşturur.

Neden önemli

Bu, tüm süreç olaylarını birbirine bağlayan temel vaka tanımlayıcısıdır ve herhangi bir iş öğesinin tam yaşam döngüsünü izlemeyi mümkün kılar.

Nereden alınır

Bu genellikle bir GitLab Issue'nun dahili ID'sidir (IID). Issues API yanıtında 'iid' alanı olarak bulunabilir.

Örnekler
1024512PRJ-2345
Atanan Kişi
Assignee
Olay anında soruna veya birleştirme isteğine atanan kullanıcı.
Açıklama

Atanan, sürecin belirli bir noktasında iş öğesinden sorumlu bireysel geliştirici veya kullanıcıdır. GitLab'de bu, bir Issue veya Merge Request'in assignee veya assignees alanında yakalanır.

Atanana göre analiz, 'Geliştirici İş Yükü ve Tahsisi' dashboard'u için kritiktir. Kaynak kullanımını anlamaya, aşırı yüklenmiş bireyleri veya ekipleri belirlemeye ve farklı kişiler arasındaki devirleri analiz etmeye yardımcı olur.

Neden önemli

İşi kimin yaptığını takip ederek iş yükü analizi, kaynak tahsis verimliliği ve el değiştirmelerden kaynaklanan gecikmelerin tespit edilmesini sağlar.

Nereden alınır

GitLab Issues ve Merge Requests API yanıtlarındaki 'assignee.username' veya 'assignees' alanlarından alınmıştır.

Örnekler
jdoeasmithr.williams
Bitiş Saati
EndTime
Bir aktivitenin veya olayın ne zaman tamamlandığını gösteren zaman damgası.
Açıklama

EndTime, bir aktivitenin bittiği tam tarih ve saati belirtir. GitLab'deki 'Issue Created' (Talep Oluşturuldu) gibi pek çok atomik olayda EndTime, StartTime ile aynıdır. 'Code Review' (Kod İncelemesi) gibi belirli bir süresi olan aktivitelerde ise tamamlanma zaman damgasını, örneğin son onayın verildiği anı temsil eder.

Bu öznitelik, münferit aktivitelerin süresini (İşlem Süresi) doğru hesaplamak için kritiktir. Aktif çalışma süresi ile görevler arasındaki bekleme süresini birbirinden ayırarak detaylı darboğaz (bottleneck) analizine yardımcı olur.

Neden önemli

Süreçteki verimsiz adımları belirlemede anahtar olan kesin etkinlik sürelerinin (işleme süreleri) hesaplanmasını sağlar.

Nereden alınır

Atomik olaylar için bu, StartTime ile aynıdır. Süreli aktiviteler için, verilerdeki karşılık gelen bir tamamlanma olayını bularak türetilmelidir.

Örnekler
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Geliştirme Öğesi Türü
DevelopmentItemType
Geliştirme öğesinin 'Özellik', 'Hata', 'Görev' veya 'Bakım' gibi sınıflandırması.
Açıklama

Bu öznitelik, gerçekleştirilen işin doğasını kategorize eder. GitLab'de bu, genellikle bir sorun üzerindeki etiketler kullanılarak uygulanır. Ekipler, yeni işlevsellik, hata çözümü, teknik borç ve diğer iş türleri arasında ayrım yapmak için etiketleri kullanır.

Geliştirme Öğesi Türüne göre analiz, farklı iş türleri için süreç akışlarını ve döngü sürelerini karşılaştırmaya olanak tanır. Örneğin, hataların özelliklerden daha hızlı çözülüp çözülmediği veya teknik borç görevlerinin farklı bir inceleme sürecini takip edip etmediği analiz edilebilir.

Neden önemli

Süreci iş türüne göre segmentlere ayırmak, belirli iş türlerinin gecikmelere, tekrar işleme veya sapmalara daha yatkın olup olmadığını belirlemeye yardımcı olur.

Nereden alınır

Genellikle bir GitLab Issue'una uygulanan 'etiketlerden' türetilir. Belirli etiketleri standartlaştırılmış tiplere çevirmek için bir eşleme mantığına ihtiyaç vardır.

Örnekler
ÖzellikHataGörevTeknik Borç
Proje Adı
ProjectName
Geliştirme öğesinin ait olduğu GitLab projesinin adı.
Açıklama

Bu öznitelik, işin yapıldığı belirli kod deposunu veya projeyi tanımlar. GitLab'de her sorun ve birleştirme isteği bir projenin içindedir.

Proje Adına göre analiz yapmak, farklı ürünler, bileşenler veya hizmetler arasında performans karşılaştırmalarına olanak tanır. Belirli projelerin diğerlerinden daha sağlıklı SDLC süreçlerine sahip olup olmadığını belirlemeye yardımcı olabilir ve dashboard'ları belirli bir ilgi alanına göre filtrelemek için kullanışlıdır.

Neden önemli

Süreç analizinin ürüne, uygulamaya veya bileşene göre segmentlere ayrılmasını sağlayarak, hedeflenmiş iyileştirme çabalarını kolaylaştırır.

Nereden alınır

Project API'deki 'name' veya 'path_with_namespace' alanlarından, Issues ve Merge Requests'deki 'project_id' aracılığıyla bağlantılı olarak alınmıştır.

Örnekler
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Şiddet
Severity
Geliştirme öğesinin önem derecesi, genellikle hatalar veya olaylar için.
Açıklama

Önem derecesi, kritikden küçük olana kadar bir hata veya sorunun etkisini gösterir. GitLab'de yerleşik bir önem derecesi alanı bulunmadığından, bu neredeyse her zaman etiketler (örneğin, 'severity::1', 'severity::2') kullanılarak uygulanır.

Bu öznitelik, 'Önem Derecesi Artış Trendleri' Dashboard'u ve ilişkili KPI için çok önemlidir. Yaşam döngüsü boyunca önem derecesindeki değişiklikleri analiz etmek, başlangıçta hafife alınan sorunları veya problemleri ağırlaştıran süreçleri vurgulayabilir.

Neden önemli

İşi önceliklendirmeye ve yüksek önem dereceli maddelerin daha hızlı ele alınıp alınmadığını analiz etmeye yardımcı olur. Değişiklikleri izlemek, 'Önem Derecesi Artış Sıklığı' KPI'ını destekler.

Nereden alınır

Bir GitLab Sorununa uygulanan 'etiketlerden' türetilmiştir. 'S1', 'S2' gibi etiketleri şiddet seviyeleri olarak yorumlamak için bir eşleme gereklidir.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Aktarım Bekleme Süresi
HandoffWaitTime
Farklı atanan kişiler tarafından gerçekleştirilen iki ardışık etkinlik arasındaki hesaplanan boşta kalma süresi.
Açıklama

Bu metrik, bir aktivitenin tamamlanması ile bir sonrakinin başlaması arasındaki boşluğun süresini, özellikle atanan kişi değiştiğinde hesaplar. Örneğin, bir geliştiricinin işini bitirmesinden bir incelemecinin kod incelemesine başlamasına kadar geçen süreyi ölçer.

Bu, 'Ortalama Devir Bekleme Süresi' KPI'sı için anahtar metrik olup kaynak tahsisindeki ve ekipler veya bireyler arasındaki iletişimdeki gizli verimsizlikleri ortaya çıkarmaya yardımcı olarak, aktif bir işin parçası olmayan gecikmeleri vurgular.

Neden önemli

Farklı kişiler veya ekipler arasındaki devirler sırasındaki boşta kalma süresini nicelendirir, gizli gecikmeleri ve iletişim darboğazlarını ortaya çıkarır.

Nereden alınır

Process mining aracı tarafından hesaplanır. Bir case içindeki ardışık olayları analiz etmeyi, 'Atanan' kişinin farklı olup olmadığını kontrol etmeyi ve ardından zaman farkını hesaplamayı gerektirir.

Örnekler
1 gün 2 saat15 dakika8 saat
Birleştirme İsteği Durumu
MergeRequestStatus
Olayla ilişkili birleştirme isteğinin durumu, örneğin 'Açıldı', 'Birleştirildi' veya 'Kapalı'.
Açıklama

Bu öznitelik, bir olayın anındaki Birleştirme İsteği (MR) durumunu yakalar. GitLab MR'larının 'açık', 'kapalı', 'birleştirilmiş' veya 'kilitli' gibi farklı durumları vardır. Bu, genel Geliştirme Öğesi Durumundan ayrıdır.

MR durumunu takip etmek, SDLC'nin kod entegrasyon aşamasını analiz etmek için kritik öneme sahiptir. 'Kod İnceleme Döngü Süresi ve Verimlilik' gibi dashboard'ları doğrudan destekler ve MR oluşturma, inceleme, onay ve birleştirme arasındaki gecikmeleri belirlemeye yardımcı olur.

Neden önemli

Kod inceleme ve birleştirme sürecine görünürlük sağlar, bu da SDLC'de genellikle kritik bir darboğazdır.

Nereden alınır

GitLab Merge Requests API yanıtındaki 'state' alanından alınmıştır.

Örnekler
openedmergedkapalılocked
Döngü Süresi
CycleTime
Bir geliştirme öğesi için ilk aktiviteden son aktiviteye kadar geçen toplam süre.
Açıklama

Döngü Süresi (Cycle Time), bir case'in toplam süresini ölçen hesaplanmış bir metriktir. Genellikle tek bir Development Item için ilk olay ('Sorun Oluşturuldu' gibi) ile en son olay ('Üretime Dağıtıldı' gibi) arasındaki zaman farkı olarak hesaplanır.

Bu, genel süreç verimliliğini ölçmek için birincil bir KPI'dır. 'SDLC Uçtan Uca Döngü Süresi' gibi dashboard'larda anahtar metriktir ve iyileştirmeleri izlemek ve sistemik sorunları gösterebilecek uzun süreli case'leri belirlemek için kullanılır.

Neden önemli

Bu, geliştirme yaşam döngüsünün uçtan uca verimliliğini ölçen temel bir Process Mining KPI'ıdır.

Nereden alınır

Process mining aracı tarafından her benzersiz CaseId için maksimum StartTime'dan minimum StartTime çıkarılarak hesaplanır.

Örnekler
10 gün 4 saat23 saat 15 dakika35 gün
Dönüm Noktası Başlığı
MilestoneTitle
Geliştirme öğesinin atandığı dönüm noktasının veya sprintin başlığı.
Açıklama

GitLab'de bir Dönüm Noktası (Milestone), sprint veya sürüm gibi belirli bir hedefe veya zaman dilimine karşı işi izlemek için kullanılır. Bu attribute, o dönüm noktasının adını veya başlığını yakalar.

Bu attribute, belirli sprint'ler veya planlama dönemleri bağlamında süreç performansının analiz edilmesini sağlar. Döngü sürelerinin bir sprint'ten diğerine iyileşip iyileşmediğini görmek veya süreç görünümünü yalnızca yaklaşan bir sürümle ilgili işi gösterecek şekilde filtrelemek için kullanılabilir.

Neden önemli

Geliştirme çalışmalarını sprintler veya sürümler gibi planlama döngülerine bağlar, planlanan zaman kutularına göre performans analizini mümkün kılar.

Nereden alınır

GitLab Issues veya Merge Requests API yanıtlarındaki 'milestone.title' alanından alınmıştır.

Örnekler
2023 4. Çeyrek SürümüSprint 23.11Aşama 1: MVP
Ekip Adı
TeamName
Proje veya atanana bağlı geliştirme ekibi.
Açıklama

Ekip Adı, geliştirme öğesinden sorumlu grubu veya takımı temsil eder. Bu bilgi genellikle GitLab'de standart bir alan değildir ve genellikle proje adlandırma kurallarından, grup yapılarından veya atananları harici bir referans tablosu kullanarak ilgili ekiplerine eşleştirerek türetilir.

Bu öznitelik, süreç performansını ekip düzeyinde analiz etmek için kullanılır. Farklı ekipler arasındaki verimliliği, iş yükünü ve sürece bağlılığı karşılaştırmaya yardımcı olur, 'Aşamaya Özgü Darboğaz Analizi' gibi Dashboard'ları ekip tabanlı bir görünümden destekler.

Neden önemli

Farklı ekipler arasında performans analizi ve süreç karşılaştırması yapılmasına olanak tanır, ekip bazında bottleneck'leri veya en iyi uygulamaları belirlemeye yardımcı olur.

Nereden alınır

Genellikle Proje Adı veya Atananı GitLab dışında tanımlanmış bir ekip yapısına eşleyerek veya GitLab grup hiyerarşilerinden çıkarılarak elde edilir.

Örnekler
Frontend-AlphaBackend-HizmetleriPlatform-Infra
Geliştirme Öğesi Durumu
DevelopmentItemStatus
Olay anındaki geliştirme öğesinin durumu, örneğin 'Açık', 'Devam Ediyor' veya 'Kapalı'.
Açıklama

Bu öznitelik, birincil iş öğesinin durumunu yansıtır, genellikle GitLab'deki bir Issue'dur. GitLab Issue'larının 'açık' veya 'kapalı' olabilen bir state'i vardır. Daha ayrıntılı durumlar genellikle kapsamlı etiketler (örneğin, 'Durum::Triage', 'Durum::Geliştirmede', 'Durum::İncelemede') kullanılarak yönetilir.

Durum değişikliklerini izlemek, vaka yaşam döngüsünü anlamak için çok önemlidir. Öğelerin her durumda ne kadar zaman geçirdiğini belirlemeye yardımcı olur ve 'SDLC Uçtan Uca Döngü Süresi' gibi dashboard'larda aktif veya tamamlanmış işleri filtrelemek için kullanılabilir.

Neden önemli

Davanın durumunun bir anlık görüntüsünü sunarak, çeşitli aşamalarda harcanan sürenin analizini ve devam eden ile tamamlanmış işler arasında filtreleme yapılmasını sağlar.

Nereden alınır

Birincil durum, bir GitLab Issue'nun 'state' alanından ('opened', 'closed') gelir. Daha ayrıntılı durumlar genellikle etiketlerden türetilir.

Örnekler
openedkapalıDevam Ediyorİncelemede
Hedef Dal
TargetBranch
Bir birleştirme isteği için hedef dalın adı.
Açıklama

Hedef Dal, değişikliklerin birleştirilmesi amaçlanan daldır; örneğin 'main', 'develop' veya 'release/1.5' gibi bir sürüm dalı. Bu, herhangi bir Birleştirme İsteği için temel bir bilgi parçasıdır.

Hedef Bala göre analiz yapmak, farklı hedeflere birleştirilen kodlar için farklı süreç davranışlarını ortaya çıkarabilir. Örneğin, 'main' dalına birleştirmeler, bir özellik dalına birleştirmelerden daha titiz bir onay sürecine ve daha uzun döngü sürelerine sahip olabilir. Ayrıca üretim dağıtımlarını diğer kod entegrasyonu türlerinden ayırmaya da yardımcı olabilir.

Neden önemli

Hedef dallara bağlı olarak süreçler önemli ölçüde değişebildiğinden, çeşitli geliştirme ve sürüm iş akışlarını ayırt etmeye yardımcı olur.

Nereden alınır

GitLab Merge Requests API yanıtındaki 'target_branch' alanından alınmıştır.

Örnekler
maingeliştirmerelease/v2.1.0hotfix/user-auth-bug
İşlem Süresi
ProcessingTime
Tek bir aktivitenin süresi, bitiş ve başlangıç zamanı arasındaki fark olarak hesaplanır.
Açıklama

İşlem süresi, belirli bir aktivite için aktif çalışma süresini ölçer ve aktiviteler arasındaki bekleme süresinden farklıdır. Tek bir olay kaydı için EndTime eksi StartTime olarak hesaplanır. Anlık olaylar için işlem süresi sıfırdır.

Bu metrik, Aşamaya Özgü Darboğaz Analizi için kritik öneme sahiptir. Kod İncelemesi gibi bir aşamadaki aktivitelerin işlem sürelerini bir araya getirerek, analistler aktif olarak ne kadar süre harcandığını tam olarak belirleyebilir ve verimsiz süreç adımlarını tespit etmeye yardımcı olabilir.

Neden önemli

Bireysel aktivitelerin süresini ölçer, hassas darboğaz analizi için aktif çalışma süresini boşta bekleme süresinden ayırmaya yardımcı olur.

Nereden alınır

Process mining aracı tarafından bir etkinliğin EndTime ve StartTime arasındaki fark olarak hesaplanır.

Örnekler
2 saat 30 dakika0 dakika3 gün 8 saat
Kaynak Sistem
SourceSystem
Verilerin kaynaklandığı sistemi tanımlar.
Açıklama

Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu veri modeli için değer tutarlı olarak 'GitLab' olacaktır.

Bu özniteliği dahil etmek, süreç verilerinin birden fazla sistemden (örneğin planlama için Jira ve yürütme için GitLab) birleştirilebileceği ortamlarda çok önemlidir. Filtreleme, segmentasyon sağlar ve veri kökenini korumaya yardımcı olur.

Neden önemli

Veri kaynağı konusunda netlik sağlayarak veri yönetişimi ve birden fazla kurumsal sistemden veri entegrasyonu için kritik bir avantaj sunar.

Nereden alınır

Bu, veri dönüştürme süreci sırasında eklenen statik bir değer olan 'GitLab'dir.

Örnekler
GitLab
Pipeline Durumu
PipelineStatus
CI/CD pipeline çalıştırmasının durumu, örneğin 'Başarılı', 'Başarısız' veya 'Çalışıyor'.
Açıklama

Bu öznitelik, bir commit veya birleştirme isteğiyle ilişkili bir CI/CD pipeline yürütmesinin sonucunu gösterir. GitLab'deki yaygın durumlar arasında 'running', 'pending', 'success', 'failed', 'canceled' ve 'skipped' bulunur.

Bu veri, 'Tekrar İşleme ve Yeniden Çalıştırma Analizi' dashboard'u için temeldir. Sık pipeline hataları, önemli bir tekrar işleme ve gecikme kaynağı olabilir ve bunların sıklığını, konumunu ve etkisini analiz etmek, geliştirme verimliliğini ve kod kalitesini artırmak için anahtardır.

Neden önemli

Otomatik derlemelerin ve testlerin başarılarını/başarısızlıklarını izler; yeniden işleme döngülerini ve kod kalitesi veya test otomasyonuyla ilgili sorunları ortaya çıkarır.

Nereden alınır

GitLab CI/CD Pipelines API yanıtındaki 'status' alanından alınmıştır.

Örnekler
successbaşarısızrunningiptal edildi
Son Veri Güncellemesi
LastDataUpdate
Bu olay için verilerin kaynak sistemden en son ne zaman güncellendiğini gösteren zaman damgası.
Açıklama

Bu öznitelik, olay verilerinin süreç madenciliği veri kümesinde en son ne zaman çıkarıldığını veya güncellendiğini kaydeder. Olayın ne zaman meydana geldiğini değil, olayın kaydının en son ne zaman senkronize edildiğini gösterir.

Bu bilgi, veri güncelliğini anlamak ve süreç analizinin zamanlamasını doğrulamak için hayati öneme sahiptir. Kullanıcıların dashboard'ların ve KPI'ların güncel verilere dayandığına güvenmelerine yardımcı olur ve kaynak sistemi ile analiz arasındaki olası gecikme hakkında bilgi verir.

Neden önemli

Veri güncelliği konusunda şeffaflık sağlayarak, kullanıcıların süreç analizinin ne kadar güncel olduğundan haberdar olmalarını temin eder.

Nereden alınır

Bu zaman damgası, bir veri yenilemesi sırasında veri çıkarma aracı veya ETL süreci tarafından oluşturulur ve kaydedilir.

Örnekler
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Sürüm Versiyonu
ReleaseVersion
Dağıtımla ilişkili planlanan veya gerçek yazılım sürüm etiketi.
Açıklama

Bu öznitelik, bir geliştirme öğesinin parçası olduğu belirli yazılım sürümünü tanımlar. GitLab'de bu, bir Dönüm Noktası, korumalı bir etiket veya Sürümler özelliğindeki bir giriş aracılığıyla ilişkilendirilebilir.

Bu, 'Sürüm Takvimi Uyumluluk Takibi' dashboard'u için temeldir. Gerçek dağıtım tarihini sürüm versiyonuyla ilişkili planlanan bir tarihle karşılaştırarak, kuruluşlar takvimlere uyma yeteneklerini ölçebilir ve sürüm gecikmelerinin nedenlerini teşhis edebilir.

Neden önemli

Geliştirme öğelerini belirli bir yazılım sürümüne bağlar; bu, sürüm ilerlemesini ve zaman çizelgesine uyumu izlemek için çok önemlidir.

Nereden alınır

Bu, GitLab Sürümleri'nden, bir git etiketinin adından veya sürüm planlaması için kullanılan bir dönüm noktasının başlığından alınabilir.

Örnekler
v1.2.0v3.0.0-beta2023.4.1
Yeniden İşleme mi?
IsRework
Bir etkinliğin yeniden işleme döngüsünün bir parçası olup olmadığını gösteren bir boolean bayrağı.
Açıklama

Bu hesaplanmış öznitelik, test başlamışken geliştirmeye geri dönme gibi süreçte geriye doğru bir adımı temsil eden aktiviteleri işaretler. Bu işaret için mantık genellikle belirli aktivite dizilerini tespit etmeyi içerir; örneğin, aynı durum için bir 'Pipeline Başarısız Oldu' veya 'KG Testi Başladı' olayından sonra bir 'Geliştirme Başladı' olayının meydana gelmesi.

Bu öznitelik, 'Tekrar İşleme ve Yeniden Çalıştırma Analizi' dashboard'unu ve 'Test Sonrası Tekrar İşleme Oranı' KPI'ını doğrudan destekler. Tekrar işlemenin kolayca filtrelenmesini ve nicelleştirilmesini sağlayarak ekiplerin sıklığını, nedenlerini ve proje zaman çizelgeleri üzerindeki etkisini anlamalarına yardımcı olur.

Neden önemli

Yeniden işi doğrudan işaretler ve nicelleştirir, bu da süreç verimsizliklerinin ve kalite sorunlarının nedenlerini ve etkilerini analiz etmeyi kolaylaştırır.

Nereden alınır

Process mining aracı tarafından her case için etkinlik dizisi analiz edilerek ve yeniden işi gösteren kalıplar belirlenerek hesaplanır.

Örnekler
truefalse
Gerekli Önerilen İsteğe Bağlı

Yazılım Geliştirme Yaşam Döngüsü Aktiviteleri

Bunlar, doğru Process Discovery ve darboğaz tespiti için event log'unuza dahil etmeniz gereken temel süreç adımları ve kilometre taşlarıdır.
4 Önerilen 8 İsteğe Bağlı
Aktivite Açıklama
Birleştirme İsteği Birleştirildi
Bu aktivite, kod inceleme ve entegrasyon sürecinin başarılı bir şekilde tamamlandığını gösterir. Bir kullanıcının birleştirme isteğinin dalını hedef dala birleştirdiğinde meydana gelen açık bir olaydır.
Neden önemli

Bu, geliştirme ve incelemenin tamamlandığını gösteren önemli bir dönüm noktasıdır. Geliştirme döngü süresini ölçmek için bitiş noktası ve dağıtım teslim süresini ölçmek için başlangıç noktası olarak hizmet eder.

Nereden alınır

Bu, 'merge_requests' tablosundaki 'merged_at' zaman damgasından yakalanan açık bir olaydır. Birleştirme sırasında bir sistem notu da oluşturulur.

Yakala

Merge request'in 'merged_at' zaman damgasını kullanın.

Event tipi explicit
Birleştirme İsteği Oluşturuldu
İlk geliştirme çalışmasının tamamlandığını ve kodun inceleme ve entegrasyon için hazır olduğunu gösterir. Bu, bir geliştiricinin yeni bir birleştirme isteği (MR) açtığında yakalanan, GitLab iş akışında açık ve temel bir olaydır.
Neden önemli

Bu, geliştirmeden inceleme ve teste geçişi işaret eden kritik bir dönüm noktasıdır. Tüm kod inceleme ve CI/CD pipeline döngüsünü analiz etmek için giriş noktasıdır.

Nereden alınır

Bu, 'merge_requests' tablosundaki 'created_at' zaman damgasından veya Merge Requests API aracılığıyla yakalanan açık bir olaydır.

Yakala

Merge request'in 'created_at' zaman damgasını kullanın.

Event tipi explicit
Sorun Oluşturuldu
Bu aktivite, bir özellik, hata veya görev gibi yeni bir iş öğesinin oluşturulmasını temsil ederek geliştirme yaşam döngüsünün başlangıcını işaretler. Bir kullanıcı GitLab'de yeni bir sorun oluşturduğunda açıkça yakalanır ve bu da oluşturma zaman damgasını kaydeder.
Neden önemli

Bu, uçtan uca süreç için birincil başlangıç olayıdır. Sorun oluşturmadan dağıtıma kadar geçen süreyi analiz etmek, SDLC döngü süresinin tam bir resmini sağlar.

Nereden alınır

Bu, 'issues' tablosundaki 'created_at' zaman damgasından veya Issues API aracılığıyla yakalanan açık bir olaydır. Sistem notları da oluşturma olayını kaydeder.

Yakala

Issue'nun 'created_at' zaman damgasını kullanın.

Event tipi explicit
Üretime Dağıtıldı
Bu aktivite, kodun canlı üretim ortamına başarılı bir şekilde dağıtıldığını işaret eder ve son kullanıcılara sunulmasını sağlar. Bu, bir GitLab CI/CD pipeline'ında belirli bir 'üretim ortamına dağıt' görevinin başarıyla tamamlanmasıyla yakalanır.
Neden önemli

Bu, sürecin birincil bitiş olayıdır ve değerin teslim edildiğini gösterir. Toplam uçtan uca SDLC döngü süresini ve sürüm sıklığını ölçmek için temeldir.

Nereden alınır

Özellikle üretim dağıtımı için belirlenmiş başarılı bir CI/CD işinin 'finished_at' timestamp'ından alınır. GitLab'in Ortamlar (Environments) özelliği bunu açıkça izler.

Yakala

Başarılı bir üretim dağıtımı CI işindeki 'finished_at' zaman damgasını kullanın.

Event tipi explicit
Dağıtım Başladı
Kodu staging veya production gibi belirli bir ortama yayınlama sürecinin başlangıcını temsil eder. GitLab'de bu, bir CI/CD pipeline'ı içindeki bir 'deploy' görevinin başlangıcına karşılık gelir.
Neden önemli

Dağıtım başlangıcını takip etmek, dağıtım aşamasının süresini izole etmeye yardımcı olur. Dağıtım teslim süresini ölçmek ve optimize etmek için çok önemlidir.

Nereden alınır

Dağıtım işi olarak yapılandırılmış bir CI/CD işinin 'started_at' timestamp'ından alınır. Bu, GitLab'in Ortamlar (Environments) ve Dağıtımlar (Deployments) özelliğinin bir parçasıdır.

Yakala

Bir dağıtım görevi için CI iş günlüğündeki 'started_at' zaman damgasını kullanın.

Event tipi explicit
Geliştirme Başladı
Bu aktivite, sorun üzerinde aktif kodlama çalışmasının başlangıcını işaret eder. GitLab'de açık bir 'geliştirmeyi başlat' düğmesi bulunmadığından, bu genellikle soruna bağlı bir dala gönderilen ilk kod commit'inden çıkarılır.
Neden önemli

Değer katan geliştirme çalışmasının kesin başlangıcını belirler, saf kodlama aşamasının doğru bir şekilde ölçülmesine ve planlama veya bekleme süresinden ayrılmasına olanak tanır.

Nereden alınır

Soruna bağlı bir özellik dalındaki ilk commit'in zaman damgasının bulunmasıyla çıkarılır. Bu, sorunları dallara bağlamayı gerektirir ve genellikle adlandırma kuralları veya meta veriler aracılığıyla yapılır.

Yakala

İlgili sorun kimliğine sahip bir daldaki ilk commit zaman damgasını bulun.

Event tipi inferred
Kod İncelemesi Başladı
Bir birleştirme isteği için akran inceleme sürecinin başlangıcını işaretler. Bu olay, yazar dışında birisi tarafından gönderilen ilk yorum veya konu gibi ilk inceleme ile ilgili eylemden çıkarılır.
Neden önemli

MR oluşturma anından inceleme başlangıcına kadar geçen süreyi ölçmek, kuyruklanma gecikmelerini vurgular. Bu bekleme süresini azaltmak, genel kod inceleme döngüsünü kısaltmanın anahtarıdır.

Nereden alınır

Birleştirme isteğindeki, MR yazarından olmayan ilk yorum veya inceleme dizisinin zaman damgasından çıkarılır. Bu veriler sistem notları veya Notlar API'si aracılığıyla elde edilebilir.

Yakala

Bir MR'daki yazar olmayan ilk kullanıcı yorumunun zaman damgasını bulun.

Event tipi inferred
Onay Eklendi
Bir incelemeci tarafından birleştirme isteğindeki kod değişikliklerinin resmi onayını temsil eder. Bu, bir kullanıcının 'Onayla' düğmesine tıkladığında GitLab tarafından yakalanan açık bir olaydır.
Neden önemli

Onaylar, temel kalite kapılarıdır. Onayları izlemek, gerekli imzaları almanın ne kadar sürdüğünü analiz etmeye yardımcı olur ve inceleme politikalarına compliance sağlar.

Nereden alınır

Birleştirme isteği onay olaylarından alınır. Bunlar Onaylar API'si aracılığıyla kullanılabilir veya MR'ın geçmişinde görülebilir.

Yakala

Merge request onay olay günlüğündeki zaman damgasını kullanın.

Event tipi explicit
Pipeline Başarısız Oldu
Bu aktivite, bir CI/CD pipeline yürütmesinin herhangi bir aşamada, örneğin bir build hatası veya başarısız bir test gibi, başarısız olması durumunda meydana gelir. GitLab, her pipeline'ın son durumunu açıkça kaydeder ve hataların kolayca belirlenmesini sağlar.
Neden önemli

Pipeline hataları, tekrar işleme neden olan başlıca faktörlerden biridir. Sıklıklarını, sürelerini ve nedenlerini analiz etmek, kalite sorunlarını, kararsız testleri ve geliştiricilere geri bildirim döngüsündeki darboğazları belirlemeye yardımcı olur.

Nereden alınır

'ci_pipelines' tablosundaki bir pipeline kaydındaki 'failed' durumu ile tanımlanır. 'finished_at' zaman damgası, hatanın ne zaman meydana geldiğini gösterir.

Yakala

Hatalı' durumdaki pipeline kayıtlarını filtreleyin ve 'finished_at' zaman damgasını kullanın.

Event tipi explicit
Pipeline Başladı
Otomatik bir CI/CD pipeline'ının başlatılmasını temsil eder; bu genellikle build'ler, testler ve güvenlik taramaları çalıştırır. GitLab, bir pipeline bir commit veya MR oluşturma gibi bir olayla tetiklendiğinde açıkça bir başlangıç zaman damgasıyla bir pipeline kaydı oluşturur.
Neden önemli

Pipeline yürütmelerini takip etmek, otomatik test ve entegrasyon süreçlerinin sağlığını ve verimliliğini izlemek için temeldir. Otomatik doğrulama işlemlerinde ne kadar zaman harcandığını belirlemeye yardımcı olur.

Nereden alınır

'ci_pipelines' tablosundaki bir pipeline kaydının 'created_at' veya 'started_at' timestamp'ından veya Pipelines API'si aracılığıyla alınır.

Yakala

MR'ın dalıyla ilişkili pipeline yürütme kaydındaki zaman damgasını kullanın.

Event tipi explicit
Sorun Atandı
Bir sorunun belirli bir geliştiriciye veya ekibe atanmasını temsil eder ve işin sahipliğinin belirlendiğini gösterir. Bu, bir sorunun assignee alanı her doldurulduğunda veya değiştirildiğinde GitLab tarafından kaydedilen açık bir olaydır.
Neden önemli

Atamaları takip etmek, kaynak tahsisi, ekip iş yükü ve devir sürelerini analiz etmek için çok önemlidir. İşin oluşturulması ile alınması arasındaki gecikmeleri belirlemeye yardımcı olur.

Nereden alınır

GitLab'in sorunla ilgili sistem notlarından alınır; bu notlar, bir 'atanan' kişi eklendiğinde veya değiştirildiğinde log tutar. Olay timestamp'ı nota kaydedilir.

Yakala

Sorunun sistem notlarından 'atanan değişti' olaylarını çıkarın.

Event tipi explicit
Sorun Kapatıldı
İş öğesinin, değişiklikleri dağıtıldıktan ve doğrulandıktan sonraki son idari kapanışını temsil eder. Bu, bir kullanıcının GitLab'de sorunu kapattığında yakalanan açık bir olaydır.
Neden önemli

Bir sorunu kapatmak genellikle ilgili tüm işlerin sonunu işaret eder. Bunu dağıtım zamanıyla karşılaştırmak, dağıtım sonrası doğrulama veya idari süreçlerdeki gecikmeleri ortaya çıkarabilir.

Nereden alınır

Bu, 'issues' tablosundaki 'closed_at' zaman damgasından veya ilgili sistem notundan yakalanan açık bir olaydır.

Yakala

Issue'nun 'closed_at' zaman damgasını kullanın.

Event tipi explicit
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi GitLab'den Nasıl Alırsınız?