Yazılım geliştirme yaşam döngüsü Veri Templateiniz

GitLab
Yazılım geliştirme yaşam döngüsü Veri Templateiniz

Yazılım geliştirme yaşam döngüsü Veri Templateiniz

Bu ayrıntılı Template, yazılım geliştirme yaşam döngüsü sürecinizi analiz etmek için gereken temel veri noktalarını belirlemenize yardımcı olur. Toplanması önerilen öznitelikleri ve izlenecek başlıca etkinlikleri sıralar, ayrıca bu bilgileri doğrudan GitLab’dan nasıl alabileceğinizi açıklar. Bu kaynakla verilerinizi Process Mining analizine güvenle hazırlayabilirsiniz.
  • Toplanması önerilen öznitelikler
  • İzlenecek temel etkinlikler
  • Veri çıkarma yönergeleri
Olay günlüklerine yeni misiniz? Process Mining için nasıl Event Log oluşturacağınızı öğrenin.

Yazılım geliştirme yaşam döngüsü öznitelikleri

Yazılım geliştirme yaşam döngüsünü ayrıntılı biçimde analiz edip iyileştirmek için olay günlüğünüze eklemeniz önerilen veri alanları.
3 Zorunlu 5 Önerilen 12 İsteğe bağlı
Ad Açıklama
Başlangıç zamanı
StartTime
Bir etkinliğin veya olayın ne zaman başladığını gösteren zaman damgası.
Açıklama

Başlangıç zamanı, belirli bir etkinliğin gerçekleştiği tarih ve saati tam olarak belirtir. GitLab’deki olaylar için bu bilgi çeşitli zaman damgası alanlarında tutulur. Örneğin 'Sorun oluşturuldu' etkinliğinin başlangıç zamanı, sorunun created_at zaman damgasıdır. 'Merge Request birleştirildi' etkinliğinin başlangıç zamanı ise Merge Request’in merged_at zaman damgasıdır.

Bu zaman damgası, Process Mining’deki temel zaman bilgisidir. Olayları kronolojik sıraya koymak, etkinlikler arasındaki süreleri hesaplamak, çevrim sürelerini ölçmek ve süreç performansını zaman içinde analiz etmek için kullanılır.

Neden önemli?

Olayların kronolojik sırasını verir. Zamana dayalı tüm metrikleri hesaplamak ve süreç akışını anlamak için gereklidir.

Nereden alınır?

GitLab’deki sorunların 'created_at', 'updated_at' ve 'closed_at' alanları ile Merge Request’lerin 'merged_at' alanı gibi çeşitli zaman damgası alanlarından alınır.

Örnekler
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Etkinlik
Activity
Gerçekleşen belirli süreç adımının veya olayın adıdır. Örneğin 'Sorun oluşturuldu' ya da 'Merge Request birleştirildi'.
Açıklama

Etkinlik özniteliği, bir geliştirme öğesinde gerçekleşen farklı olayları kaydeder. GitLab’de bunlar tek bir alanda tutulmaz; Issues, Merge Requests ve CI/CD Pipelines genelindeki çeşitli işlemlerden ve zaman damgası alanlarından türetilir. Örneğin sorun oluşturma, commit gönderme, pipeline başarısızlığı veya Merge Request onayı ayrı etkinliklerdir.

Bu öznitelik, süreç haritasını oluşturmak, iş akışını görselleştirmek ve olayların sırasını ve sıklığını analiz etmek için temel niteliktedir. Sapmaları, adımlar arasındaki darboğazları ve yaygın süreç akışlarını belirlemeye yardımcı olur.

Neden önemli?

Süreç haritasındaki adımları tanımlar ve uçtan uca geliştirme iş akışını görselleştirip analiz etmenizi sağlar.

Nereden alınır?

GitLab olay akışındaki olay türlerinden ve durum değişikliklerinden ya da Issues ve Merge Requests üzerindeki 'created_at', 'merged_at' ve 'closed_at' gibi zaman damgası alanlarının yorumlanmasından elde edilir.

Örnekler
Sorun oluşturulduGeliştirme başladıMerge Request birleştirildiPipeline başarısız olduÜretime dağıtıldı
Geliştirme öğesi
DevelopmentItem
Özellik, hata düzeltmesi veya görev gibi bir iş biriminin benzersiz tanımlayıcısıdır ve temel vaka tanımlayıcısı olarak kullanılır.
Açıklama

Geliştirme öğesi, yazılım geliştirme yaşam döngüsü boyunca ilerleyen, izlenebilir tek bir iş parçasını temsil eder. Oluşturulmasından son dağıtıma kadar ilgili tüm etkinlikleri tek bir vaka altında birleştirir. GitLab’de bu öğe genellikle bir proje içinde benzersiz olan Sorun iç kimliğiyle (IID) temsil edilir.

Geliştirme öğesine göre analiz yapmak, uçtan uca çevrim süresini ölçmenizi, darboğazları belirlemenizi ve sürecin kurallara uygunluğunu denetlemenizi sağlar. İşin fikir aşamasından üretime ne kadar verimli ulaştığını anlamanın temelini oluşturur.

Neden önemli?

Bu temel vaka tanımlayıcısı, süreçteki tüm olayları birbirine bağlar ve belirli bir iş öğesinin tüm yaşam döngüsünü izlemenizi sağlar.

Nereden alınır?

Bu genellikle bir GitLab Sorununun iç kimliğidir (IID). Issues API yanıtındaki 'iid' alanında bulunabilir.

Örnekler
1024512PRJ-2345
Atanan kişi
Assignee
Olayın gerçekleştiği sırada soruna veya Merge Request’e atanmış kullanıcı.
Açıklama

Atanan kişi, sürecin belirli bir noktasında iş öğesinden sorumlu olan geliştirici veya kullanıcıdır. GitLab’de bu bilgi, bir Sorunun veya Merge Request’in assignee ya da assignees alanında tutulur.

Atanan kişiye göre analiz, 'Geliştirici iş yükü ve kaynak dağılımı' Dashboardu için önemlidir. Kaynak kullanımını anlamaya, aşırı iş yükü olan kişileri veya ekipleri belirlemeye ve kişiler arasındaki devir teslimleri analiz etmeye yardımcı olur.

Neden önemli?

İşi kimin yaptığını izleyerek iş yükü analizini, kaynak dağılımının verimliliğini ve devir teslimlerden kaynaklanan gecikmelerin belirlenmesini sağlar.

Nereden alınır?

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

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

Bitiş zamanı, bir etkinliğin tamamlandığı tarih ve saati tam olarak belirtir. GitLab’deki 'Sorun oluşturuldu' gibi birçok tekil olayda bitiş zamanı ile başlangıç zamanı aynıdır. 'Kod incelemesi' gibi süre gerektiren etkinliklerde ise son onayın verildiği an gibi tamamlanma zamanını gösterir.

Bu öznitelik, tek tek etkinliklerin süresini (işlem süresini) doğru hesaplamak için gereklidir. Görev üzerinde etkin olarak çalışılan süreyle görevler arasındaki bekleme süresini ayırarak ayrıntılı darboğaz analizi yapmaya yardımcı olur.

Neden önemli?

Etkinlik sürelerinin (işlem sürelerinin) doğru hesaplanmasını sağlar. Bu, süreçteki verimsiz adımları belirlemek için önemlidir.

Nereden alınır?

Tekil olaylarda başlangıç zamanıyla aynıdır. Süre gerektiren etkinliklerde, verilerdeki karşılık gelen tamamlanma olayı bulunarak türetilmelidir.

Örnekler
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Ciddiyet
Severity
Genellikle hatalar veya olaylar için kullanılan geliştirme öğesinin ciddiyet düzeyi.
Açıklama

Ciddiyet, bir hata veya sorunun etkisini kritik düzeyden düşük düzeye kadar belirtir. GitLab’de yerleşik bir ciddiyet alanı bulunmadığından bu bilgi neredeyse her zaman etiketlerle uygulanır (ör. 'severity::1', 'severity::2').

Bu öznitelik, 'Ciddiyet düzeyindeki artış eğilimleri' Dashboardu ve ilgili KPI için önemlidir. Yaşam döngüsü boyunca ciddiyet değişikliklerini analiz etmek, başlangıçta etkisi düşük değerlendirilen sorunları veya sorunları büyüten süreçleri ortaya çıkarabilir.

Neden önemli?

İşlere öncelik vermeye ve ciddiyeti yüksek öğelerin daha hızlı ele alınıp alınmadığını analiz etmeye yardımcı olur. Değişiklikleri izlemek, 'Ciddiyet düzeyindeki artış sıklığı' KPI’ını destekler.

Nereden alınır?

Bir GitLab Sorununa eklenen 'labels' alanından elde edilir. 'S1' ve 'S2' gibi etiketleri ciddiyet düzeylerine dönüştürmek için eşleme gerekir.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Geliştirme öğesi türü
DevelopmentItemType
Özellik, hata, görev veya bakım gibi geliştirme öğesinin sınıflandırması.
Açıklama

Bu öznitelik, yapılan işin türünü sınıflandırır. GitLab’de bu sınıflandırma genellikle bir soruna eklenen etiketlerle yapılır. Ekipler etiketleri yeni işlevleri, hata düzeltmelerini, teknik borcu ve diğer iş türlerini ayırt etmek için kullanır.

Geliştirme öğesi türüne göre analiz, farklı iş türlerinin süreç akışlarını ve çevrim sürelerini karşılaştırmanızı sağlar. Örneğin hataların özellik geliştirmeye kıyasla daha hızlı çözülüp çözülmediğini veya teknik borç görevlerinin farklı bir inceleme sürecinden geçip geçmediğini analiz edebilirsiniz.

Neden önemli?

Süreci iş türüne göre bölümlere ayırmak, belirli iş türlerinin gecikmeye, yeniden çalışmaya veya sapmalara daha yatkın olup olmadığını belirlemeye yardımcı olur.

Nereden alınır?

Genellikle bir GitLab Sorununa eklenen 'labels' alanından elde edilir. Belirli etiketleri standart türlere dönüştürmek için bir eşleme kuralı gerekir.

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

Bu öznitelik, işin yapıldığı kod deposunu veya projeyi belirtir. GitLab’de her sorun ve Merge Request bir projenin içinde yer alır.

Proje adına göre analiz, farklı ürünlerin, bileşenlerin veya hizmetlerin performansını karşılaştırmanızı sağlar. Bazı projelerin SDLC süreçlerinin diğerlerinden daha iyi işleyip işlemediğini belirlemeye yardımcı olur ve Dashboardları belirli bir alana göre filtrelemek için kullanılabilir.

Neden önemli?

Süreç analizini ürün, uygulama veya bileşene göre bölümlere ayırarak hedefli iyileştirme çalışmalarını kolaylaştırır.

Nereden alınır?

Issues ve Merge Requests içindeki 'project_id' üzerinden bağlantı kurularak Project API’deki 'name' veya 'path_with_namespace' alanlarından alınır.

Örnekler
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Çevrim süresi
CycleTime
Bir geliştirme öğesindeki ilk etkinlik ile son etkinlik arasında geçen toplam süre.
Açıklama

Çevrim süresi, bir vakanın toplam süresini ölçen hesaplanmış bir metriktir. Genellikle tek bir Geliştirme Öğesi için ilk olayın (ör. 'Sorun oluşturuldu') zaman damgası ile son olayın (ör. 'Üretime dağıtıldı') zaman damgası arasındaki fark olarak hesaplanır.

Bu, genel süreç verimliliğini ölçmek için kullanılan temel KPI’lardan biridir. 'SDLC uçtan uca çevrim süresi' gibi Dashboardlarda başlıca metriktir. İyileşmeleri izlemek ve sistemik sorunlara işaret edebilecek uzun süre devam eden vakaları belirlemek için kullanılır.

Neden önemli?

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

Nereden alınır?

Process Mining aracı, her benzersiz CaseId için minimum StartTime değerini maksimum StartTime değerinden çıkararak hesaplar.

Örnekler
10 gün 4 saat23 saat 15 dakika35 gün
Devir teslim bekleme süresi
HandoffWaitTime
Farklı atanan kişilerce gerçekleştirilen ardışık iki etkinlik arasındaki hesaplanmış bekleme süresi.
Açıklama

Bu metrik, özellikle atanan kişi değiştiğinde, bir etkinliğin tamamlanmasıyla sonraki etkinliğin başlaması arasındaki süreyi hesaplar. Örneğin bir geliştiricinin işini bitirmesiyle inceleyenin kod incelemesine başlaması arasında geçen süreyi ölçer.

Bu, 'Ortalama devir teslim bekleme süresi' KPI’ının temel metriğidir. Ekipler veya kişiler arasındaki kaynak dağılımı ve iletişimdeki gizli verimsizlikleri ortaya çıkarır; etkin çalışma sürecinin dışında kalan gecikmeleri gösterir.

Neden önemli?

Kişiler veya ekipler arasındaki devir teslimlerde yaşanan bekleme süresini ölçerek gizli gecikmeleri ve iletişim darboğazlarını ortaya çıkarır.

Nereden alınır?

Process Mining aracı tarafından hesaplanır. Vaka içindeki ardışık olayları inceleyerek 'Atananlar' değerinin değişip değişmediğini kontrol eder ve ardından zaman farkını hesaplar.

Örnekler
1 gün 2 saat15 dakika8 saat
Ekip adı
TeamName
Projeyle veya atanan kişiyle ilişkili geliştirme ekibi.
Açıklama

Ekip adı, geliştirme öğesinden sorumlu grubu veya ekibi belirtir. Bu bilgi genellikle GitLab’de standart bir alan değildir; çoğunlukla proje adlandırma kurallarından, grup yapılarından veya atanan kişileri harici bir referans tablosuyla ilgili ekiplere eşleştirerek elde edilir.

Bu öznitelik, süreç performansını ekip düzeyinde analiz etmek için kullanılır. Ekipler arasındaki verimliliği, iş yükünü ve süreç uyumunu karşılaştırmaya yardımcı olur. Ekip bazında görünüm sunan 'Aşamaya göre darboğaz analizi' gibi Dashboardları destekler.

Neden önemli?

Farklı ekiplerin performansını ve süreçlerini karşılaştırmayı sağlar; ekiplere özgü darboğazları veya iyi uygulamaları belirlemeye yardımcı olur.

Nereden alınır?

Genellikle Proje Adı veya Atanan Kişi, GitLab dışında tanımlanmış bir ekip yapısıyla eşleştirilerek ya da GitLab grup hiyerarşilerinden çıkarılarak elde edilir.

Örnekler
Frontend-AlphaBackend-ServicesPlatform-Infra
Geliştirme öğesi durumu
DevelopmentItemStatus
Açık, devam ediyor veya kapalı gibi, olayın gerçekleştiği sıradaki geliştirme öğesi durumu.
Açıklama

Bu öznitelik, genellikle GitLab’deki bir Sorun olan temel iş öğesinin durumunu gösterir. GitLab Sorunlarının 'opened' veya 'closed' değerini alabilen bir state alanı vardır. Daha ayrıntılı durumlar genellikle kapsamlı etiketlerle yönetilir (ör. 'Status::Triage', 'Status::In-Dev', 'Status::In-Review').

Durum değişikliklerini izlemek, vakanın yaşam döngüsünü anlamak için önemlidir. Öğelerin her durumda ne kadar kaldığını belirlemeye yardımcı olur ve 'SDLC uçtan uca çevrim süresi' gibi Dashboardlarda devam eden veya tamamlanan işleri filtrelemek için kullanılabilir.

Neden önemli?

Vakanın mevcut durumunu göstererek farklı aşamalarda geçirilen sürenin analiz edilmesini ve devam eden işlerin tamamlananlardan ayrılmasını sağlar.

Nereden alınır?

Temel durum, bir GitLab Sorununun 'state' alanından ('opened', 'closed') alınır. Daha ayrıntılı durumlar genellikle etiketlerden elde edilir.

Örnekler
openedclosedDevam ediyorİncelemede
Hedef dal
TargetBranch
Bir Merge Request’in hedef dalının adı.
Açıklama

Hedef dal, değişikliklerin birleştirilmesinin amaçlandığı daldır. Örneğin 'main', 'develop' veya 'release/1.5' gibi bir sürüm dalı olabilir. Her Merge Request için temel bilgilerden biridir.

Hedef dala göre yapacağınız analiz, farklı hedeflere birleştirilen kodların süreçlerinde görülen farklılıkları ortaya çıkarabilir. Örneğin 'main' dalına yapılan birleştirmelerde onay süreci daha ayrıntılı, çevrim süreleri ise özellik dalına yapılan birleştirmelere kıyasla daha uzun olabilir. Bu analiz, üretim dağıtımlarını diğer kod entegrasyonu türlerinden ayırmanıza da yardımcı olur.

Neden önemli?

Hedef dala bağlı olarak süreçler önemli ölçüde değişebileceğinden, farklı geliştirme ve sürüm iş akışlarını ayırt etmenize yardımcı olur.

Nereden alınır?

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

Örnekler
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Kaynak sistem
SourceSystem
Verinin alındığı sistemi belirtir.
Açıklama

Bu öznitelik, süreç verisinin kaynağını belirtir. Bu veri modelinde değer her zaman 'GitLab' olur.

Süreç verilerinin planlama için Jira, uygulama için GitLab gibi birden fazla sistemden birleştirilebildiği ortamlarda bu özniteliği eklemek önemlidir. Verileri filtreleyip bölümlere ayırmayı ve veri kökenini izlemeyi sağlar.

Neden önemli?

Verinin kaynağını açıkça gösterir. Bu, veri yönetişimi ve birden fazla kurumsal sistemden veri entegrasyonu için önemlidir.

Nereden alınır?

Veri dönüştürme sırasında eklenen statik bir 'GitLab' değeridir.

Örnekler
GitLab
Kilometre taşı başlığı
MilestoneTitle
Geliştirme öğesinin atandığı kilometre taşının veya sprintin başlığı.
Açıklama

GitLab’da kilometre taşı, sprint veya sürüm gibi belirli bir hedef ya da zaman aralığındaki işleri izlemek için kullanılır. Bu öznitelik, kilometre taşının adını veya başlığını içerir.

Bu öznitelik sayesinde süreç performansını belirli sprintler veya planlama dönemleri kapsamında analiz edebilirsiniz. Çevrim sürelerinin bir sprintten diğerine iyileşip iyileşmediğini görebilir ya da süreç görünümünü yalnızca yaklaşan bir sürümle ilgili işleri gösterecek şekilde filtreleyebilirsiniz.

Neden önemli?

Geliştirme işlerini sprint veya sürüm gibi planlama döngüleriyle ilişkilendirerek planlanan zaman aralıklarına göre performans analizi yapmanızı sağlar.

Nereden alınır?

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

Örnekler
2023 4. çeyrek sürümü23.11 sprinti1. aşama: MVP
Merge Request durumu
MergeRequestStatus
Olayla ilişkili Merge Request’in durumu; örneğin 'Açıldı', 'Birleştirildi' veya 'Kapatıldı'.
Açıklama

Bu öznitelik, bir olay gerçekleştiği sırada Merge Request’in (MR) durumunu gösterir. GitLab MR’larının farklı durumları vardır: 'açık', 'kapalı', 'birleştirildi' veya 'kilitli'. Bu durum, genel Geliştirme Öğesi Durumundan ayrıdır.

MR durumunu izlemek, SDLC’nin kod entegrasyonu aşamasını analiz etmek için önemlidir. 'Kod inceleme çevrim süresi ve işlem hacmi' gibi Dashboardları doğrudan destekler ve MR oluşturma, inceleme, onay ve birleştirme arasındaki gecikmeleri belirlemenize yardımcı olur.

Neden önemli?

SDLC’de çoğu zaman önemli bir darboğaz olan kod inceleme ve birleştirme sürecini görünür kılar.

Nereden alınır?

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

Örnekler
openedbirleştirildiclosedkilitli
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 Merge Request ile ilişkili CI/CD pipeline çalıştırmasının sonucunu gösterir. GitLab’da yaygın durumlar arasında 'çalışıyor', 'beklemede', 'başarılı', 'başarısız', 'iptal edildi' ve 'atlandı' bulunur.

Bu veri, 'Yeniden çalışma ve yeniden çalıştırma analizi' Dashboardu için gereklidir. Pipeline hatalarının sık yaşanması, yeniden çalışmaya ve gecikmelere önemli ölçüde yol açabilir. Geliştirme verimliliğini ve kod kalitesini artırmak için bu hataların sıklığını, nerede yaşandığını ve etkisini analiz etmek gerekir.

Neden önemli?

Otomatik derleme ve testlerin başarılı ya da başarısız olduğunu izleyerek yeniden çalışma 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ınır.

Örnekler
başarılıbaşarısızçalışıyoriptal edildi
Sürüm numarası
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 hangi yazılım sürümüne ait olduğunu belirtir. GitLab’da bu bilgi bir kilometre taşı, korumalı etiket veya Releases özelliğindeki bir kayıtla ilişkilendirilebilir.

Bu bilgi, 'Sürüm takvimine uyum takibi' Dashboardu için gereklidir. Kuruluşlar, gerçek dağıtım tarihini sürüm numarasıyla ilişkili planlanan tarihle karşılaştırarak takvime uyma becerilerini ölçebilir ve sürüm gecikmelerinin nedenlerini belirleyebilir.

Neden önemli?

Geliştirme öğelerini belirli bir yazılım sürümüyle ilişkilendirerek sürüm ilerlemesini ve takvime uyumu izlemenizi sağlar.

Nereden alınır?

Bu bilgi GitLab Releases bölümünden, bir git etiketinin adından veya sürüm planlamasında kullanılan bir kilometre taşının başlığından alınabilir.

Örnekler
v1.2.0v3.0.0-beta2023.4.1
Verinin son güncellenme zamanı
LastDataUpdate
Bu olaya ait verinin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası.
Açıklama

Bu öznitelik, olay verisinin Process Mining Veri Seti’nde en son çıkarıldığı veya güncellendiği tarih ve saati kaydeder. Olayın ne zaman gerçekleştiğini değil, olay kaydının en son ne zaman eşitlendiğini gösterir.

Bu bilgi, verinin güncelliğini anlamak ve süreç analizinin zamanında yapıldığını doğrulamak için önemlidir. Kullanıcıların Dashboardların ve KPI’ların güncel verilere dayandığına güvenmesine yardımcı olur ve kaynak sistemle analiz arasındaki olası gecikmeyi gösterir.

Neden önemli?

Verinin ne kadar güncel olduğunu açıkça göstererek kullanıcıların süreç analizinin güncelliğini anlamasını sağlar.

Nereden alınır?

Veri yenileme sırasında veri çıkarma aracı veya ETL süreci tarafından oluşturulup kaydedilir.

Örnekler
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Yeniden çalışma mı
IsRework
Bir etkinliğin yeniden çalışma döngüsünün parçası olup olmadığını belirten boole işareti.
Açıklama

Bu hesaplanmış öznitelik, test başladıktan sonra geliştirmeye geri dönmek gibi süreçte geriye gidişi gösteren etkinlikleri işaretler. Bu işaretin mantığı genellikle belirli etkinlik dizilerini saptamaya dayanır. Örneğin aynı vaka için 'Pipeline başarısız oldu' veya 'QA testi başladı' olayından sonra 'Geliştirme başladı' olayının gerçekleşmesi bu duruma işaret edebilir.

Bu öznitelik, 'Yeniden çalışma ve yeniden çalıştırma analizi' Dashboardunu ve 'Test sonrası yeniden çalışma oranı' KPI’ını doğrudan destekler. Yeniden çalışmayı kolayca filtreleyip ölçmenizi, sıklığını, nedenlerini ve proje takvimine etkisini anlamanızı sağlar.

Neden önemli?

Yeniden çalışmayı doğrudan işaretleyip ölçerek süreç verimsizliklerinin ve kalite sorunlarının nedenlerini ve etkilerini analiz etmenizi kolaylaştırır.

Nereden alınır?

Process Mining aracı, her vakanın etkinlik sırasını analiz edip yeniden çalışmaya işaret eden örüntüleri belirleyerek hesaplar.

Örnekler
truefalse
Zorunlu Önerilen İsteğe bağlı

Yazılım geliştirme yaşam döngüsü etkinlikleri

Süreci doğru biçimde keşfetmek ve darboğazları belirlemek için olay günlüğünüze eklemeniz gereken temel süreç adımları ve kilometre taşları.
4 Önerilen 8 İsteğe bağlı
Aktivite Açıklama
Merge Request birleştirildi
Bu etkinlik, kod inceleme ve entegrasyon sürecinin başarıyla tamamlandığını gösterir. Kullanıcı Merge Request dalını hedef dala birleştirdiğinde açıkça gerçekleşen bir olaydır.
Neden önemli?

Bu önemli kilometre taşı, geliştirme ve incelemenin tamamlandığını gösterir. Geliştirme çevrim süresini ölçmenin bitiş, dağıtım süresini ölçmenin ise başlangıç noktasıdır.

Nereden alınır?

Bu olay, 'merge_requests' tablosundaki 'merged_at' zaman damgasından açıkça kaydedilir. Birleştirme işlemi sırasında sistem notu da oluşturulur.

Kaydedin

Merge Request’in 'merged_at' zaman damgasını kullanın.

Olay türü explicit
Merge Request oluşturuldu
İlk geliştirme çalışmalarının tamamlandığını ve kodun inceleme ile entegrasyona hazır olduğunu gösterir. GitLab iş akışındaki bu temel olay, geliştirici yeni bir Merge Request (MR) açtığında açıkça kaydedilir.
Neden önemli?

Bu önemli kilometre taşı, geliştirmeden inceleme ve teste geçişi gösterir. Tüm kod inceleme ve CI/CD hattı döngüsünü analiz etmek için başlangıç noktasıdır.

Nereden alınır?

Bu olay, 'merge_requests' tablosundaki 'created_at' zaman damgasından veya Merge Requests API üzerinden açıkça kaydedilir.

Kaydedin

Merge Request’in 'created_at' zaman damgasını kullanın.

Olay türü explicit
Sorun oluşturuldu
Bu etkinlik, yeni bir özellik, hata veya görev gibi iş öğesinin oluşturulmasıyla geliştirme yaşam döngüsünün başladığını gösterir. Kullanıcı GitLab’de yeni bir sorun oluşturduğunda bu olay açıkça kaydedilir ve oluşturulma zaman damgası tutulur.
Neden önemli?

Bu, uçtan uca sürecin temel başlangıç olayıdır. Sorunun oluşturulmasından dağıtıma kadar geçen süreyi analiz etmek, SDLC çevrim süresinin tamamını görmenizi sağlar.

Nereden alınır?

Bu olay, 'issues' tablosundaki 'created_at' zaman damgasından veya Issues API üzerinden açıkça kaydedilir. Sistem notlarında da oluşturma olayı tutulur.

Kaydedin

Sorunun 'created_at' zaman damgasını kullanın.

Olay türü explicit
Üretime dağıtıldı
Bu etkinlik, kodun canlı üretim ortamına başarıyla dağıtıldığını ve son kullanıcıların erişimine açıldığını gösterir. GitLab CI/CD pipeline’ındaki belirli bir 'deploy to production' işi başarıyla tamamlandığında kaydedilir.
Neden önemli?

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

Nereden alınır?

Özellikle üretime dağıtım için belirlenmiş başarılı bir CI/CD işinin 'finished_at' zaman damgasından alınır. GitLab’in Environments özelliği bu bilgiyi açıkça izler.

Kaydedin

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

Olay türü explicit
Dağıtım başladı
Kodun hazırlık veya üretim gibi belirli bir ortama yayımlanma sürecinin başlangıcını gösterir. GitLab’de bu, CI/CD pipeline içindeki bir 'deploy' işinin başlamasına karşılık gelir.
Neden önemli?

Dağıtımın başlangıcını izlemek, dağıtım aşamasının süresini ayrı olarak ölçmenizi sağlar. Dağıtım süresini ölçmek ve iyileştirmek için önemlidir.

Nereden alınır?

Dağıtım işi olarak yapılandırılmış bir CI/CD işinin 'started_at' zaman damgasından alınır. Bu, GitLab’in Environments and Deployments özelliğinin bir parçasıdır.

Kaydedin

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

Olay türü explicit
Geliştirme başladı
Bu etkinlik, sorun üzerinde etkin kodlama çalışmalarının başladığını gösterir. GitLab’de açık bir 'geliştirmeyi başlat' düğmesi bulunmadığından, başlangıç genellikle sorunla ilişkili bir dala gönderilen ilk kod commit’inden çıkarılır.
Neden önemli?

Değer yaratan geliştirme çalışmalarının tam başlangıç noktasını belirler. Böylece yalnızca kodlama aşamasının süresini doğru ölçebilir, planlama ve kuyrukta bekleme sürelerini bu süreden ayırabilirsiniz.

Nereden alınır?

Sorunla bağlantılı özellik dalındaki ilk commit’in zaman damgası bulunarak belirlenir. Bunun için sorunların dallarla ilişkilendirilmesi gerekir; bu işlem genellikle adlandırma kuralları veya üst verilerle yapılır.

Kaydedin

Sorun kimliğiyle ilişkili bir daldaki ilk commit’in zaman damgasını bulun.

Olay türü inferred
Kod incelemesi başladı
Bir Merge Request için eşler arası inceleme sürecinin başlangıcını gösterir. Yazar dışındaki birinin ilk yorumu veya ilk ileti dizisi gibi incelemeyle ilgili ilk işlemden çıkarılır.
Neden önemli?

MR’nin oluşturulmasıyla incelemenin başlaması arasındaki süreyi ölçmek, kuyrukta bekleme gecikmelerini ortaya çıkarır. Bu bekleme süresini azaltmak, genel kod inceleme döngüsünü kısaltmanın önemli bir yoludur.

Nereden alınır?

MR yazarından başka birinin Merge Request’e eklediği ilk yorumun veya inceleme ileti dizisinin zaman damgasından çıkarılır. Bu veriler sistem notlarında veya Notes API üzerinden bulunabilir.

Kaydedin

MR yazarından başka bir kullanıcının MR’ye yaptığı ilk yorumun zaman damgasını bulun.

Olay türü inferred
Onay eklendi
Bir inceleyicinin Merge Request’teki kod değişikliklerini resmen onaylamasını gösterir. Kullanıcı 'Approve' düğmesine tıkladığında GitLab bu olayı açıkça kaydeder.
Neden önemli?

Onaylar, kalite kontrolünün önemli aşamalarıdır. Bunları izlemek, gerekli onayların alınma süresini analiz etmeye ve inceleme politikalarına uyumluluğu sağlamaya yardımcı olur.

Nereden alınır?

Merge Request onay olaylarından alınır. Bu olaylara Approvals API üzerinden erişilebilir veya MR geçmişinde görülebilir.

Kaydedin

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

Olay türü explicit
Pipeline başarısız oldu
Derleme hatası veya başarısız bir test gibi herhangi bir aşamada CI/CD pipeline çalıştırması başarısız olduğunda bu etkinlik gerçekleşir. GitLab her pipeline’ın son durumunu açıkça kaydettiğinden başarısızlıklar kolayca belirlenebilir.
Neden önemli?

Pipeline başarısızlıkları, yeniden çalışmanın başlıca nedenlerindendir. Sıklıklarını, sürelerini ve nedenlerini analiz etmek; kalite sorunlarını, kararsız testleri ve geliştiricilere geri bildirim akışındaki darboğazları belirlemeye yardımcı olur.

Nereden alınır?

'ci_pipelines' tablosundaki pipeline kaydının 'failed' durumunda olmasıyla belirlenir. 'finished_at' zaman damgası, başarısızlığın ne zaman gerçekleştiğini gösterir.

Kaydedin

'failed' durumundaki pipeline kayıtlarını filtreleyin ve 'finished_at' zaman damgasını kullanın.

Olay türü explicit
Pipeline başladı
Genellikle derleme, test ve güvenlik taramalarını çalıştıran otomatik bir CI/CD hattının başlatılmasını gösterir. Örneğin bir commit veya MR oluşturulmasıyla hat tetiklendiğinde GitLab, başlangıç zaman damgasını içeren bir pipeline kaydı oluşturur.
Neden önemli?

Pipeline çalıştırmalarını izlemek, otomatik test ve entegrasyon süreçlerinin durumunu ve verimliliğini takip etmek için önemlidir. Otomatik doğrulama için ne kadar zaman harcandığını görmenizi sağlar.

Nereden alınır?

'ci_pipelines' tablosundaki bir pipeline kaydının 'created_at' veya 'started_at' zaman damgasından ya da Pipelines API üzerinden alınır.

Kaydedin

MR’nin dalıyla ilişkili pipeline çalıştırma kaydındaki zaman damgasını kullanın.

Olay türü explicit
Sorun atandı
Bir sorunun belirli bir geliştiriciye veya ekibe atanmasını gösterir ve işin sorumluluğunun belirlendiğini ifade eder. GitLab, bir sorunun atanan kişi alanı doldurulduğunda veya değiştirildiğinde bu olayı açıkça kaydeder.
Neden önemli?

Atamaları izlemek; kaynak dağılımını, ekip iş yükünü ve devir teslim sürelerini analiz etmek için önemlidir. İşin oluşturulmasıyla ele alınması arasındaki gecikmeleri belirlemeye yardımcı olur.

Nereden alınır?

Soruna ait GitLab sistem notlarından alınır. Bu notlarda 'assignee' eklendiğinde veya değiştirildiğinde kayıt tutulur. Olayın zaman damgası da notta yer alır.

Kaydedin

Sorunun sistem notlarından 'assignee changed' olaylarını çıkarın.

Olay türü explicit
Sorun kapatıldı
İş öğesinin, genellikle değişiklikleri dağıtılıp doğrulandıktan sonra, idari olarak kapatılmasını gösterir. Kullanıcı GitLab’de sorunu kapattığında bu olay açıkça kaydedilir.
Neden önemli?

Bir sorunun kapatılması, ilgili tüm çalışmaların sona erdiğini gösterir. Kapatılma zamanını 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 olay, 'issues' tablosundaki 'closed_at' zaman damgasından veya ilgili sistem notundan açıkça kaydedilir.

Kaydedin

Sorunun 'closed_at' zaman damgasını kullanın.

Olay türü explicit
Önerilen İsteğe bağlı

Veri çıkarma rehberleri

GitLab’dan verilerinizi nasıl alabilirsiniz?

Başlamaya hazır mısınız?

Verilerinizi hazırlamak ve yazılım geliştirme yaşam döngünüzü iyileştirmeye başlamak için bu Templateten yararlanın. Sürecinizi bugün iyileştirmeye başlayın!

Yazılım geliştirme yaşam döngünüzü iyileştirin: optimizasyona hemen başlayın

SDLC darboğazlarını ortadan kaldırın, çevrim süresini %30 azaltın ve kaliteyi artırın.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez. Optimizasyona hemen başlayın.