Yazılım geliştirme yaşam döngünüz için Veri Şablonu

GitLab
Yazılım geliştirme yaşam döngünüz için Veri Şablonu

Yazılım geliştirme yaşam döngünüz için Veri Şablonu

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ında size yol gösterir. Toplanması gereken önemli öznitelikleri ve takip edilecek temel etkinlikleri açıklar, ayrıca bu bilgileri doğrudan GitLab'dan çıkarmak için pratik yönlendirmeler sunar. Bu kaynakla verilerinizi anlamlı Process Mining analizine güvenle hazırlayabilirsiniz.
  • Toplanması önerilen öznitelikler
  • Takip edilecek temel etkinlikler
  • Veri çıkarma yönlendirmeleri
Event Loglarına yeni misiniz? Öğrenin Process Mining Event Logu oluşturmayı öğrenin.

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

Yazılım geliştirme yaşam döngünüzü kapsamlı biçimde analiz edip optimize etmek için Event Logunuza eklemeniz önerilen veri alanları aşağıdadır.
3 Gerekli 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ıdır.
Açıklama

StartTime, belirli bir etkinliğin gerçekleştiği kesin tarih ve saati gösterir. GitLab olaylarında bu bilgi çeşitli zaman damgası alanlarından alınır. Örneğin 'Issue Created' etkinliğinin StartTime değeri sorunun 'created_at' zaman damgası, 'Merge Request Merged' etkinliğinin StartTime değeri ise merge request'in 'merged_at' zaman damgasıdır.

Bu zaman damgası, Process Mining içindeki temel zamansal unsurdur. Olayları kronolojik olarak sıralamak, etkinlikler arasındaki süreleri hesaplamak, döngü 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ı sağlar. Bu sıra, zamana dayalı tüm metrikleri hesaplamak ve süreç akışını anlamak için gereklidir.

Nereden alınır?

GitLab'daki 'created_at', 'updated_at' ve 'closed_at' gibi sorun zaman damgası alanlarından ve merge request'lerdeki 'merged_at' alanından çıkarılır.

Örnekler
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Etkinlik
Activity
'Issue Created' veya 'Merge Request Merged' gibi gerçekleşen belirli süreç adımının ya da olayın adıdır.
Açıklama

Etkinlik özniteliği, bir Geliştirme Öğesine uygulanan farklı olayları kaydeder. Bunlar GitLab’de 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 bir issue oluşturulması, commit gönderilmesi, bir pipelineın başarısız olması veya merge requestin onaylanması farklı etkinliklerdir.

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 temel niteliktedir. Sapmaları, adımlar arasındaki darboğazları ve yaygın süreç yollarını belirlemek için kullanılır.

Neden önemli?

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

Nereden alınır?

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

Örnekler
Sorun oluşturulduGeliştirme başladıMerge Request birleştirildiPipeline başarısız olduProduction'a 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 birincil vaka kimliği olarak kullanılır.
Açıklama

Geliştirme Öğesi, yazılım geliştirme yaşam döngüsünden geçen, izlenebilir tek bir iş parçasını ifade eder. Oluşturulmasından son dağıtıma kadar ilgili tüm etkinlikleri tek bir tutarlı vakada birleştirir. GitLab'da bu öğe genellikle bir proje içinde benzersiz olan Issue iç kimliğiyle (IID) temsil edilir.

Geliştirme Öğesi bazında analiz yapmak, uçtan uca döngü süresini ölçmenize, darboğazları belirlemenize ve süreç uyumluluğunu kontrol etmenize olanak tanır. İşin fikir aşamasından production ortamına ne kadar verimli ulaştırıldığını anlamanın temelini oluşturur.

Neden önemli?

Bu, tüm süreç olaylarını birbirine bağlayan temel vaka kimliğidir. Böylece belirli bir iş öğesinin tüm yaşam döngüsünü izleyebilirsiniz.

Nereden alınır?

Bu genellikle bir GitLab Issue'sunun iç kimliğidir (IID). Issues API yanıtında '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ıdır.
Açıklama

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

Atanana göre analiz, "Geliştirici iş yükü ve dağılımı" Dashboardı için büyük önem taşır. Kaynak kullanımını anlamanıza, aşırı yüklenmiş kişi veya ekipleri belirlemenize ve farklı kişiler arasındaki devir teslimleri analiz etmenize yardımcı olur.

Neden önemli?

İşi kimin yaptığını izler; iş yükü analizine, kaynak dağılımının verimliliğini değerlendirmeye ve devirlerden kaynaklanan gecikmeleri belirlemeye olanak tanır.

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ıdır.
Açıklama

EndTime, bir etkinliğin tamamlandığı kesin tarih ve saati gösterir. GitLab'daki 'Issue Created' gibi birçok atomik olay için EndTime, StartTime ile aynıdır. 'Code Review' gibi süreye sahip etkinliklerde ise son onayın verildiği an gibi tamamlanma zaman damgasını gösterir.

Bu öznitelik, tek tek etkinliklerin süresini (İşleme Süresi) doğru biçimde hesaplamak için gereklidir. Bir göreve aktif olarak harcanan süreyi görevler arasındaki bekleme süresinden ayırarak ayrıntılı darboğaz analizi yapmanıza yardımcı olur.

Neden önemli?

Kesin etkinlik sürelerini, yani işleme sürelerini hesaplamanızı sağlar. Bu, süreçteki verimsiz adımları belirlemek için önemlidir.

Nereden alınır?

Atomik olaylarda StartTime ile aynıdır. Süreye sahip etkinliklerde ise verilerdeki ilgili tamamlanma olayı bulunarak türetilmelidir.

Örnekler
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Geliştirme öğesi türü
DevelopmentItemType
'Feature', 'Bug', 'Task' veya 'Maintenance' gibi geliştirme öğesinin sınıflandırmasıdır.
Açıklama

Bu öznitelik, yürütülen işin niteliğini sınıflandırır. GitLab'da genellikle bir sorun üzerindeki etiketlerle uygulanır. Ekipler, yeni işlevleri, hata çözümünü, teknik borcu ve diğer iş türlerini ayırmak için etiketleri kullanır.

Geliştirme Öğesi Türü bazında analiz yapmak, farklı iş türlerinin süreç akışlarını ve döngü sürelerini karşılaştırmanıza olanak tanır. Örneğin hataların Özellikler'den 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 segmentlere 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 Issue'suna uygulanan 'labels' alanından türetilir. Belirli etiketleri standart türlere dönüştürmek için bir eşleme mantığı gerekir.

Örnekler
ÖzellikHataGörevTeknik Borç
Önem derecesi
Severity
Genellikle hatalar veya olaylar için kullanılan, geliştirme öğesinin önem derecesidir.
Açıklama

Önem derecesi, bir hatanın veya sorunun etkisini kritik ile küçük arasında gösterir. GitLab’de yerleşik bir önem derecesi alanı bulunmadığından bu bilgi neredeyse her zaman etiketlerle uygulanır, örneğin 'severity::1' ve 'severity::2'.

Bu öznitelik, "Önem derecesi yükselme eğilimleri" Dashboardı ve ilgili KPI için gereklidir. Yaşam döngüsü boyunca önem derecesindeki değişiklikleri analiz etmek, başlangıçta düşük tahmin edilen sorunları veya sorunları büyüten süreçleri ortaya çıkarabilir.

Neden önemli?

İşleri önceliklendirmenize ve önem derecesi yüksek öğelerin daha hızlı ele alınıp alınmadığını analiz etmenize yardımcı olur. Değişiklikleri izlemek, 'Önem Derecesi Eskalasyon Sıklığı' KPI'ını destekler.

Nereden alınır?

Bir GitLab Issue'suna uygulanan 'labels' alanından türetilir. 'S1' ve 'S2' gibi etiketleri önem derecesi seviyeleri olarak yorumlamak için eşleme gerekir.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Proje adı
ProjectName
Geliştirme öğesinin ait olduğu GitLab projesinin adıdır.
Açıklama

Bu öznitelik, çalışmanın yürütüldüğü belirli kod deposunu veya projeyi tanımlar. GitLab’de her issue ve merge request bir proje içinde yer alır.

Proje adına göre analiz yapmak, farklı ürünler, bileşenler veya hizmetler arasındaki performansı karşılaştırmanıza olanak tanır. Bazı projelerin diğerlerinden daha sağlıklı SDLC süreçlerine sahip olup olmadığını belirlemenize yardımcı olabilir ve Dashboardları belirli bir ilgi alanına göre filtrelemek için kullanılabilir.

Neden önemli?

Süreç analizini ürün, uygulama veya bileşen bazında segmentlere ayırmanızı sağlar ve hedefli iyileştirme çalışmalarını kolaylaştırır.

Nereden alınır?

Project API'deki 'name' veya 'path_with_namespace' alanlarından alınır; Issues ve Merge Requests içindeki 'project_id' üzerinden ilişkilendirilir.

Ö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 ile, örneğin 'Issue Created', son olay, örneğin 'Deployed to Production', arasındaki zaman farkı olarak hesaplanır.

Bu, genel süreç verimliliğini ölçmek için temel bir KPI’dır. "SDLC uçtan uca çevrim süresi" gibi Dashboardlarda başlıca metriktir ve iyileştirmeleri izlemek, sistemik sorunlara işaret edebilecek uzun süren vakaları 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ı, 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 bekleme süresi
HandoffWaitTime
Farklı sorumlular tarafından gerçekleştirilen ardışık iki etkinlik arasındaki hesaplanmış boşta geçen süre.
Açıklama

Bu metrik, özellikle sorumlu değiştiğinde bir etkinliğin tamamlanması ile sonraki etkinliğin başlaması arasındaki boşluğun süresini hesaplar. Örneğin bir geliştiricinin çalışmasını tamamlaması ile gözden geçiren kişinin kod incelemesine başlaması arasındaki süreyi ölçer.

Bu, 'Ortalama Devir Bekleme Süresi' KPI'ı için temel metriktir. Kaynak tahsisi ve ekipler ya da kişiler arasındaki iletişimdeki gizli verimsizlikleri ortaya çıkarmaya yardımcı olur. Aktif çalışmanın parçası olmayan gecikmeleri görünür kılar.

Neden önemli?

Farklı kişiler veya ekipler arasındaki devirlerde geçen boşta süreyi ölçerek gizli gecikmeleri ve iletişim darboğazlarını ortaya çıkarır.

Nereden alınır?

Process Mining aracı tarafından hesaplanır. Bir vaka içindeki ardışık olayların analiz edilmesi, 'Assignee' değerlerinin farklı olup olmadığının kontrol edilmesi ve ardından zaman farkının hesaplanması gerekir.

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

Ekip adı, geliştirme öğesinden sorumlu grup veya ekibi ifade eder. Bu bilgi genellikle GitLab’de standart bir alan değildir; çoğunlukla proje adlandırma kurallarından, grup yapılarından veya harici bir referans tablosu kullanılarak atananların ilgili ekiplerle eşleştirilmesinden türetilir.

Bu öznitelik, süreç performansını ekip düzeyinde analiz etmek için kullanılır. Farklı ekiplerin verimliliğini, iş yükünü ve süreç uyumunu karşılaştırmanıza yardımcı olur. Ayrıca "Aşamaya özel darboğaz analizi" gibi Dashboardları ekip bakış açısıyla destekler.

Neden önemli?

Farklı ekipler arasında performans analizi ve süreç karşılaştırması yapmanızı sağlar; ekibe özgü darboğazları veya iyi uygulamaları belirlemenize 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 belirlenir.

Örnekler
Frontend-AlphaBackend-ServicesPlatform-Infra
Geliştirme öğesi durumu
DevelopmentItemStatus
Olayın gerçekleştiği sırada geliştirme öğesinin 'Open', 'In Progress' veya 'Closed' gibi durumudur.
Açıklama

Bu öznitelik, temel iş öğesinin, genellikle GitLab’deki bir Issue öğesinin durumunu gösterir. GitLab Issues için state değeri 'opened' veya 'closed' olabilir. Daha ayrıntılı durumlar çoğunlukla kapsamlı etiketlerle yönetilir, örneğin 'Status::Triage' ve 'Status::In-Dev'.

Durum değişikliklerini izlemek, vaka yaşam döngüsünü anlamak için önemlidir. Öğelerin her durumda ne kadar kaldığını belirlemenize ve "SDLC uçtan uca çevrim süresi" gibi Dashboardlarda etkin veya tamamlanmış işleri filtrelemenize yardımcı olur.

Neden önemli?

Vakanın durumuna ilişkin anlık bir görünüm sunar. Böylece farklı aşamalarda geçirilen süreyi analiz edebilir ve devam eden işleri tamamlanan işlerden ayırarak filtreleyebilirsiniz.

Nereden alınır?

Birincil durum, GitLab Issue'sunun 'state' alanından ('opened', 'closed') alınır. Daha ayrıntılı durumlar çoğu zaman etiketlerden türetilir.

Örnekler
açıldıkapatıldıDevam ediyorİncelemede
Hedef dal
TargetBranch
Bir merge request'in değişiklikleri göndereceği hedef dalın adıdır.
Açıklama

Hedef Dal, değişikliklerin birleştirilmek istendiği 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 Dal bazında analiz yapmak, farklı hedeflere birleştirilen kodların farklı süreç davranışlarını ortaya çıkarabilir. Örneğin 'main' dalına yapılan birleştirmelerde onay süreci daha sıkı ve döngü süreleri bir özellik dalına yapılan birleştirmelerden daha uzun olabilir. Ayrıca production dağıtımlarını diğer kod entegrasyonu türlerinden ayırmanıza yardımcı olur.

Neden önemli?

Hedef branch’e bağlı olarak süreçler önemli ölçüde değişebildiğinden, farklı 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ınır.

Örnekler
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Kaynak sistem
SourceSystem
Verinin hangi sistemden alındığını belirler.
Açıklama

Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu veri modeli için değer her zaman 'GitLab' olur.

Süreç verilerinin Jira gibi planlama, GitLab gibi yürütme sistemlerinden bir araya getirilebildiği ortamlarda bu özniteliğin eklenmesi önemlidir. Filtreleme ve segmentasyon yapmanıza yardımcı olur, ayrıca veri soyunun korunmasını sağlar.

Neden önemli?

Verinin kaynağını netleştirir. Bu, veri yönetişimi ve birden fazla kurumsal sistemden veri entegre edilirken önemlidir.

Nereden alınır?

Veri dönüştürme sürecinde eklenen statik 'GitLab' değeridir.

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

GitLab'da kilometre taşı, sprint veya sürüm gibi belirli bir hedef ya da zaman kutusuna göre çalışmaları takip etmek için kullanılır. Bu öznitelik, söz konusu kilometre taşının adını veya başlığını içerir.

Bu öznitelik, belirli sprintler veya planlama dönemleri bağlamında süreç performansını analiz etmenizi sağlar. Çevrim sürelerinin bir sprintten diğerine iyileşip iyileşmediğini görmek veya süreç görünümünü yalnızca yaklaşan sürümle ilgili çalışmaları gösterecek şekilde filtrelemek için kullanılabilir.

Neden önemli?

Geliştirme çalışmalarını sprint veya sürüm gibi planlama döngülerine bağlayarak performansın planlanan zaman kutularına göre analiz edilmesini 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üSprint 23.11Aşama 1: MVP
Merge Request durumu
MergeRequestStatus
Olayla ilişkilendirilmiş merge request'in 'Opened', 'Merged' veya 'Closed' gibi durumudur.
Açıklama

Bu öznitelik, bir olay gerçekleştiği sırada Merge Request (MR) durumunu kaydeder. GitLab MRları için 'opened', 'closed', 'merged' veya 'locked' gibi farklı durumlar bulunur. Bu bilgi, genel Geliştirme Öğesi Durumundan ayrıdır.

MR durumunu izlemek, SDLCnin 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, onaylama ve birleştirme arasındaki gecikmeleri belirlemenize yardımcı olur.

Neden önemli?

Kod inceleme ve birleştirme sürecini görünür kılar. Bu süreç, SDLC içinde çoğu zaman önemli bir darboğaz oluşturur.

Nereden alınır?

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

Örnekler
açıldıbirleştirildikapatıldıkilitlendi
Pipeline durumu
PipelineStatus
'Success', 'Failed' veya 'Running' gibi CI/CD pipeline çalıştırmasının durumudur.
Açıklama

Bu öznitelik, bir commit veya merge request ile ilişkili CI/CD pipeline yürütmesinin sonucunu gösterir. GitLab’de yaygın durumlar arasında 'running', 'pending', 'success', 'failed', 'canceled' ve 'skipped' bulunur.

Bu veri, "Yeniden çalışma ve yeniden çalıştırma analizi" Dashboardı için gereklidir. Sık pipeline hataları önemli bir yeniden çalışma ve gecikme kaynağı olabilir. Bunların sıklığını, konumunu ve etkisini analiz etmek, geliştirme verimliliğini ve kod kalitesini artırmanın temel yollarından biridir.

Neden önemli?

Otomatik derlemelerin ve testlerin başarı ve başarısızlık durumlarını izler; yeniden çalışma döngülerini ve kod kalitesi veya test otomasyonuyla ilgili sorunları görünür kılar.

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
Son veri güncellemesi
LastDataUpdate
Bu olaya ait verilerin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgasıdır.
Açıklama

Bu öznitelik, olay verilerinin Process Mining Veri Setinden 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 senkronize edildiğini gösterir.

Bu bilgi, verilerin güncelliğini anlamak ve süreç analizinin zamanında yapıldığını doğrulamak için önemlidir. Dashboardların ve KPI’ların güncel verilere dayandığına güvenmenize yardımcı olur ve kaynak sistem ile analiz arasındaki olası gecikme hakkında bilgi verir.

Neden önemli?

Verilerin güncelliği konusunda şeffaflık sağlar ve kullanıcıların süreç analizinin ne kadar güncel olduğunu bilmesine yardımcı olur.

Nereden alınır?

Bu zaman damgası, veri yenilendiği sırada 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
ReleaseVersion
Dağıtımla ilişkilendirilen 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 sürüm bir Milestone, korumalı bir etiket veya Releases özelliğindeki bir girişle ilişkilendirilebilir.

Bu bilgi, "Sürüm takvimine uyum takibi" Dashboardı için gereklidir. Kuruluşlar, gerçek dağıtım tarihini sürümle ilişkilendirilmiş planlanan tarihle karşılaştırarak takvimlere uyma becerilerini ölçebilir ve sürüm gecikmelerinin nedenlerini belirleyebilir.

Neden önemli?

Geliştirme öğelerini belirli bir yazılım sürümüne bağlar. Bu, sürüm ilerlemesini ve takvime uyumluluğu takip etmek için önemlidir.

Nereden alınır?

GitLab Releases, bir git etiketinin adı 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
Yeniden işleme mi
IsRework
Bir etkinliğin yeniden işleme döngüsünün parçası olup olmadığını belirten boolean işareti.
Açıklama

Bu hesaplanmış öznitelik, test başladıktan sonra geliştirmeye geri dönmek gibi süreçte geriye doğru bir adımı temsil eden etkinlikleri işaretler. Bu işaretin mantığı genellikle belirli etkinlik sıralarını algılamaya dayanır. Örneğin aynı vaka için 'Pipeline Failed' veya 'QA Testing Started' olayından sonra 'Development Started' olayının gerçekleşmesi.

Bu öznitelik doğrudan "Yeniden çalışma ve yeniden çalıştırma analizi" Dashboardını ve "Test sonrası yeniden çalışma oranı" KPI’ını destekler. Yeniden çalışmayı kolayca filtrelemenizi ve ölçmenizi sağlar. Böylece ekipler sıklığını, nedenlerini ve proje takvimine etkisini anlayabilir.

Neden önemli?

Yeniden işlemeyi doğrudan işaretleyip ölçer; süreç verimsizliklerinin ve kalite sorunlarının nedenlerini ve etkisini analiz etmeyi kolaylaştırır.

Nereden alınır?

Process Mining aracı, her vakadaki etkinlik dizisini analiz ederek yeniden işlemeye işaret eden örüntüleri belirler.

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

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

Doğru süreç keşfi ve darboğaz tespiti için Event Logunuzda kaydetmeniz gereken temel süreç adımları ve kilometre taşları aşağıdadır.
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. Bir kullanıcı merge request dalını hedef dala birleştirdiğinde gerçekleşen açık bir olaydır.
Neden önemli?

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

Nereden alınır?

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

Yakalayın

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

Olay türü explicit
Merge Request oluşturuldu
İlk geliştirme çalışmasının tamamlandığını ve kodun inceleme ile entegrasyona hazır olduğunu gösterir. Bu, geliştiricinin yeni bir merge request (MR) açmasıyla kaydedilen, GitLab iş akışındaki açık ve temel bir olaydır.
Neden önemli?

Bu önemli kilometre taşı, geliştirmeden inceleme ve test aşamasına geçişi gösterir. Tüm kod inceleme ve CI/CD pipeline döngüsünü analiz etmenin başlangıç noktasıdır.

Nereden alınır?

Bu, 'merge_requests' tablosundaki 'created_at' zaman damgasından veya Merge Requests API üzerinden alınan açık bir olaydır.

Yakalayın

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

Olay türü explicit
Production'a dağıtıldı
Bu etkinlik, kodun canlı production 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, değerin teslim edildiğini gösteren birincil bitiş olayıdır. Uçtan uca toplam SDLC döngü süresini ve sürüm sıklığını ölçmek için gereklidir.

Nereden alınır?

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

Yakalayın

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

Olay türü explicit
Sorun oluşturuldu
Bu etkinlik, yeni bir Özellik, hata veya görev gibi bir iş öğesinin oluşturulmasını ifade ederek geliştirme yaşam döngüsünün başlangıcını işaretler. GitLab'da bir kullanıcı yeni bir sorun oluşturduğunda açıkça kaydedilir ve oluşturma zaman damgası tutulur.
Neden önemli?

Bu, uçtan uca sürecin birincil başlangıç olayıdır. Sorun oluşturma ile dağıtım arasındaki süreyi analiz etmek, SDLC döngü süresinin tamamını görmenizi sağlar.

Nereden alınır?

Bu, 'issues' tablosundaki 'created_at' zaman damgasından veya Issues API üzerinden alınan açık bir olaydır. Sistem notları da oluşturma olayını kaydeder.

Yakalayın

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

Olay türü explicit
Dağıtım başladı
Kodun staging veya production gibi belirli bir ortama yayımlanması sürecinin başlangıcını ifade eder. GitLab'da bu, bir CI/CD pipeline içindeki '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çmenize yardımcı olur. Dağıtım teslim süresini ölçmek ve optimize etmek 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 bilgi, GitLab'ın Environments ve Deployments Özellikleri'nin bir parçasıdır.

Yakalayın

Bir 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 aktif kodlama çalışmasının başladığını gösterir. GitLab'da açık bir 'start development' düğmesi bulunmadığından genellikle sorunla ilişkilendirilmiş bir dala gönderilen ilk kod commit'inden çıkarılır.
Neden önemli?

Değer üreten geliştirme çalışmasının tam başlangıcını belirler. Böylece yalnızca kodlama aşamasını doğru biçimde ölçebilir ve bu süreyi planlama veya kuyrukta bekleme süresinden ayırabilirsiniz.

Nereden alınır?

Sorunla ilişkilendirilmiş bir özellik dalındaki ilk commit'in zaman damgası bulunarak çıkarılır. Bunun için sorunların dallarla ilişkilendirilmesi gerekir; bu işlem çoğu zaman adlandırma kuralları veya meta verilerle yapılır.

Yakalayın

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

Olay türü inferred
Kod incelemesi başladı
Bir merge request için ekip arkadaşları tarafından yapılan inceleme sürecinin başlangıcını gösterir. Genellikle yazar dışındaki bir kişinin yazdığı ilk yorum veya açtığı ilk thread gibi incelemeyle ilgili ilk işlemden çıkarılır.
Neden önemli?

MR oluşturulmasından incelemenin başlamasına kadar geçen süreyi ölçmek, kuyrukta bekleme kaynaklı gecikmeleri görünür kılar. Bu bekleme süresini azaltmak, genel kod inceleme döngüsünü kısaltmak için önemlidir.

Nereden alınır?

Merge request üzerinde MR yazarına ait olmayan ilk yorumun veya inceleme thread'inin zaman damgasından çıkarılır. Bu veri sistem notları veya Notes API üzerinden alınabilir.

Yakalayın

Bir MR üzerindeki yazar dışındaki bir kullanıcıya ait ilk yorumun zaman damgasını bulun.

Olay türü inferred
Onay eklendi
Bir inceleyenin merge request'teki kod değişikliklerini resmi olarak onaylamasını ifade eder. GitLab, kullanıcı 'Approve' düğmesine tıkladığında bu açık olayı kaydeder.
Neden önemli?

Onaylar önemli kalite kontrol noktalarıdır. Bunları izlemek, gerekli onayların alınmasının ne kadar sürdüğünü analiz etmenize ve inceleme politikalarına uyumluluğu sağlamanıza 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.

Yakalayın

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

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

Pipeline başarısızlıkları, yeniden çalışmanın başlıca nedenlerinden 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ının 'failed' durumuyla belirlenir. 'finished_at' zaman damgası başarısızlığın ne zaman gerçekleştiğini gösterir.

Yakalayın

'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 pipeline'ının başlatılmasını ifade eder. GitLab, örneğin bir commit veya MR oluşturulmasıyla pipeline tetiklendiğinde 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 gereklidir. Otomatik doğrulama aşamasında ne kadar zaman harcandığını belirlemenize yardımcı olur.

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.

Yakalayın

MR'ın dalıyla ilişkilendirilmiş 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ı ifade eder ve işin sorumluluğunun belirlendiğini gösterir. GitLab, bir sorunun assignee alanı doldurulduğunda veya değiştirildiğinde bu açık olayı kaydeder.
Neden önemli?

Atamaları izlemek, kaynak dağılımını, ekip iş yükünü ve devir sürelerini analiz etmek için önemlidir. İş oluşturulduğunda ne zaman ele alındığına kadar geçen gecikmeleri belirlemenize yardımcı olur.

Nereden alınır?

GitLab'ın sorunla ilgili sistem notlarından alınır. Bu notlar bir 'assignee' eklendiğinde veya değiştirildiğinde kayda geçer. Olayın zaman damgası notta tutulur.

Yakalayın

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

Olay türü explicit
Sorun kapatıldı
Genellikle değişiklikler dağıtılıp doğrulandıktan sonra iş öğesinin idari olarak kapatılmasını ifade eder. Kullanıcı GitLab'da sorunu kapattığında kaydedilen açık bir olaydır.
Neden önemli?

Bir sorunun kapatılması çoğu zaman ilgili tüm çalışmaların sona erdiğini gösterir. Bu zamanı 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 alınan açık bir olaydır.

Yakalayın

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

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

Veri çıkarma rehberleri

Verilerinizi GitLab'dan nasıl alırsınız

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

Verilerinizi hazırlamak ve Yazılım Geliştirme Yaşam Döngünüzü optimize etmeye başlamak için bu Templateten yararlanın. Sürecinizi bugün dönüştürmeye başlayın!

Yazılım geliştirme yaşam döngünüzü iyileştirin: Şimdi optimize etmeye başlayın

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

Ücretsiz denemenizi başlatın

Kredi kartı gerekmez, optimizasyona hemen başlayın.