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

GitHub
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 template, GitHub'dan Yazılım Geliştirme Yaşam Döngüsü verilerinizi toplamak ve hazırlamak için kapsamlı bir rehber sunar. Dahil edilecek önerilen nitelikleri, izlenecek temel etkinlikleri ve veri çıkarımı için pratik rehberliği bulacaksınız. Etkili süreç analizi ve optimizasyonu için doğru bir event log'u oluşturmak amacıyla bu kaynağı kullanın.
  • 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ü Nitelikleri

Kapsamlı Yazılım Geliştirme Yaşam Döngüsü analizi ve süreç keşfi için event log'unuza eklemeniz önerilen veri alanlarıdır.
3 Gerekli 5 Önerilen 16 İsteğe Bağlı
Ad Açıklama
Aktivite
ActivityName
Yazılım geliştirme yaşam döngüsü içinde gerçekleşen belirli bir event veya görevin adı.
Açıklama

Etkinlik Adı, geliştirme sürecindeki tek bir adımı tanımlar; örneğin 'Sorun Oluşturuldu', 'Kodu PR'a Yüklendi', 'Çekme İsteği Onaylandı' veya 'Dağıtım Başarılı Oldu'. Bu event'ler, bir geliştirme öğesi için uçtan uca süreci oluşturan adım dizisini oluşturur.

Bu öznitelik, süreç madenciliğinin temelini oluşturur ve süreç haritasını oluşturmak için kullanılır. Bu etkinliklerin dizisini, sıklığını ve süresini analiz etmek, gerçek süreç akışını ortaya çıkarır, ortak yolları belirler, sapmaları vurgular ve darboğazları tespit eder.

Neden önemli

Bu öznitelik, süreç haritasının bel kemiğini oluşturur ve geliştirme yaşam döngüsündeki event'lerin dizisinin görselleştirilmesine ve analiz edilmesine olanak tanır.

Nereden alınır

Webhook olay yüklerinin 'action' alanından (örn. bir sorun için 'açıldı', 'kapandı') veya olayın türünden (örn. 'PushEvent', 'PullRequestReviewEvent') türetilir.

Örnekler
Sorun OluşturulduÇekme İsteği AçıldıKoda PR'a Gönderildiİnceleme Talep EdildiÇekme İsteği Birleştirildi
Başlangıç Zamanı
EventTimestamp
Belirli bir geliştirme etkinliğinin veya event'inin gerçekleştiği kesin tarih ve saat.
Açıklama

Bu timestamp, bir etkinliğin başlangıcını işaret eder. Her geliştirme öğesi için süreç akışını yeniden yapılandırmak amacıyla event'leri kronolojik olarak sıralamak için hayati öneme sahiptir. Bu timestamp'ler arasındaki dizi ve zaman farkı, süreç performansını analiz etmek için kullanılır.

Analizde, bu öznitelik döngü süreleri, işlem süreleri ve bekleme süreleri dahil tüm zamana dayalı metrikleri hesaplamak için esastır. Adımlar arasındaki gecikmelerin belirlenmesine olanak tanır ve darboğaz analizi ile performans izleme Dashboard'ları için gerekli verileri sağlar.

Neden önemli

Bu timestamp, event'leri doğru şekilde sıralamak ve döngü süreleri ve darboğaz süreleri gibi tüm performans metriklerini hesaplamak için kritiktir.

Nereden alınır

Genellikle GitHub API'lerinden ve webhook'lardan gelen JSON payload'larında sorunlar, çekme istekleri ve commit'ler gibi çeşitli nesneler için 'created_at' veya 'updated_at' alanları olarak bulunur.

Örnekler
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Geliştirme Öğesi
DevelopmentItemId
Bir özellik, hata düzeltmesi veya görev gibi tek bir geliştirme iş birimi için benzersiz tanımlayıcı. Bu, birincil case tanımlayıcısı olarak hizmet eder.
Açıklama

Geliştirme Öğe Kimliği, bir iş öğesini oluşturulmasından nihai dağıtımına kadar takip eder. Dal oluşturma, commit'ler, çekme istekleri, incelemeler ve dağıtımlar gibi tüm ilişkili etkinlikleri tek, tutarlı bir süreç örneğine bağlar.

Analizde, bu Kimlik bir geliştirme görevinin uçtan uca döngü süresini hesaplamak için kullanılır. Bir özelliğin veya hata düzeltmesinin tüm yolculuğunun yeniden yapılandırılmasına olanak tanıyarak, darboğazların, yeniden çalışma döngülerinin ve bireysel iş öğeleri için süreç varyasyonlarının ayrıntılı analizini sağlar.

Neden önemli

Proses madenciliği için temel anahtardır; ilgili tüm geliştirme olaylarını tek bir olaya bağlayarak uçtan uca yazılım geliştirme yaşam döngüsünü doğru bir şekilde görselleştirmeyi ve analiz etmeyi sağlar.

Nereden alınır

Bu genellikle GitHub'dan gelen Sorun Numarası veya Çekme İsteği Numarasıdır. Sorun veya çekme isteğiyle ilgili webhook event'lerinin veya API yanıtlarının payload'ındaki 'number' alanından çıkarılabilir.

Örnekler
101PR-2345TASK-812
Atanan Kullanıcı
Assignee
Geliştirme öğesini veya çekme isteği incelemesi gibi belirli bir görevi ele almak üzere atanan kullanıcı veya geliştirici.
Açıklama

Bu öznitelik, belirli bir aşamada işten sorumlu kişiyi tanımlar. Bu, bir sorunun atananı, bir çekme isteğinin yazarı veya kod incelemesi için talep edilen gözden geçiren olabilir. Atananı izlemek, kaynak tahsisi ve iş yükünü anlamak için anahtardır.

Analizde, bu öznitelik geliştirici iş yükünü izlemek, kaynak darboğazlarını belirlemek ve farklı ekip üyeleri arasındaki devir teslim verimliliğini analiz etmek için kullanılır. Dashboard'lar, bireysel veya ekip performansını değerlendirmek ve dengeli bir iş dağılımı sağlamak için atanana göre filtrelenebilir.

Neden önemli

Geliştirici iş yükü, ekip performansı ve farklı ekip üyeleri arasındaki devirlerin verimliliğini analiz etmek için çok önemlidir.

Nereden alınır

GitHub API'sinden sorunlar, çekme istekleri ve inceleme olayları için JSON yükleri içindeki 'assignee' veya 'user' nesnesinde mevcuttur.

Örnekler
john.doejane.smithdev-team-lead
Bitiş Saati
EndTimestamp
Belirli bir geliştirme etkinliğinin veya event'inin tamamlandığı kesin tarih ve saat.
Açıklama

Bitiş zaman damgası, bir etkinliğin tamamlandığını işaret eder. GitHub'daki birçok event anlıktır (örn. 'Sorun Oluşturuldu'), ancak bazı etkinliklerin ölçülebilir bir süresi vardır (örn. çalışan bir CI kontrolü). Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark, bir etkinliğin işlem süresini verir.

Bu öznitelik, 'İşlem Süresi' metriğini hesaplamak için kullanılır; bu, kod incelemeleri veya otomatik kontroller gibi farklı görevlere ne kadar aktif çaba harcandığını anlamak için hayati önem taşır. İşlem sürelerini analiz etmek, çok fazla zaman tüketen verimsiz etkinlikleri belirlemeye yardımcı olur.

Neden önemli

Etkinlikler için hassas işlem sürelerinin hesaplanmasını sağlayarak, aktif çalışma süresi ile boşta bekleme süresi arasında ayrım yapmaya yardımcı olur.

Nereden alınır

Kontrol çalıştırma nesnelerinde 'completed_at' olarak bulunabilir veya sonraki, mantıksal olarak sonuçlandıran bir olayın zaman damgasından türetilebilir.

Örnekler
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Depo
RepositoryName
Geliştirme etkinliğinin gerçekleştiği kod deposunun adı.
Açıklama

Depo, belirli bir uygulama veya bileşen için tüm kodu, sorunları ve çekme isteklerini içeren bir proje veya ürün tanımlayıcısı görevi görür. Farklı ürünler veya ekipler arasındaki geliştirme süreçlerini segmentlere ayırma ve karşılaştırma olanağı sağlar.

Analizde, bu öznitelik farklı projelerdeki süreç performansını filtrelemeye ve karşılaştırmaya olanak tanır. 'Hangi projenin döngü süresi en uzun?' veya 'Proje A'daki hata düzeltme süreci Proje B ile nasıl karşılaştırılır?' gibi soruları yanıtlamaya yardımcı olur. 'Proje ve Türe Göre Verimlilik' Dashboard'u için hayati öneme sahiptir.

Neden önemli

Farklı projeler, ürünler veya ekipler arasında geliştirme süreçlerinin segmentlere ayrılmasına ve karşılaştırılmasına olanak tanıyarak daha hedefli analizler yapılmasını sağlar.

Nereden alınır

Neredeyse tüm GitHub webhook ve API yüklerindeki 'repository' nesnesinde mevcuttur. Spesifik alan genellikle 'repository.full_name' veya 'repository.name' şeklindedir.

Örnekler
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Geliştirme Öğesi Türü
DevelopmentItemType
Bir özellik, hata, görev veya epik gibi geliştirme iş öğesinin sınıflandırması.
Açıklama

Bu öznitelik, yapılan işin doğasını kategorize eder. Bu bilgi genellikle GitHub içindeki etiketler veya belirli sorun şablonları aracılığıyla yönetilir. İş türünü anlamak, uygun performans beklentilerini belirlemek için çok önemlidir, çünkü bir hata düzeltmesi yeni bir özellikten çok daha kısa beklenen döngü süresine sahip olabilir.

Bu öznitelik, farklı iş türleri arasında karşılaştırmalı analiz yapılmasını sağlar. Hata düzeltmelerinin yeni özelliklerden daha hızlı işlenip işlenmediğini analiz etmeye veya teknik borca karşı yeni geliştirme için kaynak tahsisini anlamaya yardımcı olur. 'Proje ve Türe Göre Verimlilik' Dashboard'unda kilit bir boyuttur.

Neden önemli

İş öğelerini kategorize eder, farklı iş türlerinin (örn. hatalar ve özellikler) süreç boyunca nasıl aktığını karşılaştırmalı olarak analiz etmeyi ve performans karşılaştırmaları yapmayı sağlar.

Nereden alınır

Genellikle sorunlara veya çekme isteklerine uygulanan GitHub etiketlerinden türetilir. Tutarlı bir etiketleme kuralı gerektirir (örn. 'type:bug', 'type:feature').

Örnekler
HataÖzellikGörevTeknik Borç
Öncelik
Priority
Bir geliştirme öğesine atanan öncelik seviyesi, örneğin 'Yüksek', 'Orta' veya 'Düşük'.
Açıklama

Öncelik, bir iş öğesinin aciliyetini veya iş önemini gösterir. GitHub'da öncelik yerel bir alan değildir ve genellikle etiketler (örn. 'P1-Yüksek', 'P2-Orta') kullanılarak yönetilir. Bu bilgiyi güvenilir bir şekilde çıkarmak için tutarlı bir etiketleme şeması gereklidir.

Bu öznitelik, 'Öncelik Tabanlı Akış Analizi' için çok önemlidir. Analistlerin, yüksek öncelikli öğelerin gerçekten düşük öncelikli öğelerden daha hızlı işlenip işlenmediğini doğrulamasına ve önceliğe dayalı döngü süresi varyansını ölçmesine olanak tanır. Önceliklendirme sürecinin etkinliğini değerlendirmeye yardımcı olur.

Neden önemli

Yüksek öncelikli öğelerin düşük öncelikli öğelerden daha hızlı işlenip işlenmediğinin analizini sağlar, böylece önceliklendirme stratejisinin etkinliğini doğrular.

Nereden alınır

GitHub'da sorunlara veya çekme isteklerine uygulanan etiketlerden türetilir. Öncelik etiketleri için standartlaştırılmış bir kural gerektirir.

Örnekler
YüksekOrtaDüşükKritik
Çekme İsteği Numarası
PullRequestNumber
Geliştirme öğesiyle ilişkili bir çekme isteği için benzersiz tanımlayıcı.
Açıklama

Bir çekme isteği (PR), bir dizi kod değişikliğini belirli bir dala birleştirmek için yapılan bir öneridir. Çekme İsteği Numarası, kod göndermeler ve incelemeler gibi geliştirme etkinliklerini birincil geliştirme öğesine veya soruna bağlar.

Bu kimlik, daha geniş geliştirme yaşam döngüsü içindeki kod entegrasyonu ve inceleme alt sürecini izlemek için hayati öneme sahiptir. İnceleme süreleri, inceleme sırasında tespit edilen yeniden işleme döngüleri ve birleştirme oranları dahil olmak üzere kod inceleme sürecinin ayrıntılı analizine olanak tanır. Planlama aşamasını (sorun) uygulama aşamasına (PR) bağlar.

Neden önemli

Sorunları belirli kod değişikliklerine ve inceleme süreçlerine bağlayarak, kod inceleme döngüsünün ve bunun genel teslim süresi üzerindeki etkisinin ayrıntılı analizini sağlar.

Nereden alınır

Birçok GitHub API yanıtında 'pull_request' nesnesi içindeki 'number' alanı olarak veya Çekme İstekleri API'sinden ana tanımlayıcı olarak mevcuttur.

Örnekler
12345678910
CI Kontrol Durumu
CiCheckStatus
Otomatik Sürekli Entegrasyon (CI) kontrolünün durumu, örneğin 'geçti' veya 'başarısız oldu'.
Açıklama

Bu öznitelik, bir çekme isteğindeki kod değişikliklerine karşı çalışan otomatik derlemelerin, testlerin ve taramaların sonucunu yansıtır. CI kontrolleri, modern geliştirme workflow'larında kritik bir kalite kapısıdır.

Bu özniteliği analiz etmek, otomatik testin etkinliğini anlamaya yardımcı olur. Yüksek bir hata oranı, kod kararlılığı, test paketi veya geliştirme ortamıyla ilgili sorunları gösterebilir. 'CI Kontrolleri Başarılı' ve 'CI Kontrolleri Başarısız' etkinliklerini destekler ve bozuk derlemelerden kaynaklanan gecikmeleri analiz etmeye yardımcı olur.

Neden önemli

Otomatik kalite kapılarının başarısını veya başarısızlığını göstererek kod kalitesi ve CI pipeline'ının etkinliği hakkında içgörü sağlar.

Nereden alınır

GitHub Checks veya Statuses API aracılığıyla kontrol çalıştırma veya durum objelerinin 'state' veya 'conclusion' alanından elde edilir.

Örnekler
başarılıfailurependingerror
Commit Hash
CommitHash
Belirli bir kod commit'i için benzersiz tanımlayıcı (SHA).
Açıklama

Bir commit hash'i, Git'te bir commit'i benzersiz bir şekilde tanımlayan 40 karakterlik bir SHA-1 hash'idir. Kodun belirli bir sürümü için kalıcı bir kimlik görevi görür. Commit'ler, geliştirme sürecindeki atomik değişim birimleridir.

Son derece ayrıntılı olmasına rağmen, commit hash'i en üst düzeyde izlenebilirlik sağlar. Analistlerin bir süreç olayını doğrudan yapılan tam kod değişikliğine geri bağlamasına olanak tanır. Bu, denetim, uyumluluk veya üretimdeki olayların ayrıntılı kök neden analizi için paha biçilmez olabilir.

Neden önemli

Bir süreç adımı ile tam kod değişikliği arasında en ayrıntılı bağlantıyı sağlayarak denetimler ve hata ayıklama için tam izlenebilirlik sunar.

Nereden alınır

Push olay yüklerinde ('head_commit.id') veya bir çekme isteği ya da dal için Commit API'si aracılığıyla mevcuttur.

Örnekler
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Dağıtım Ortamı
DeploymentEnvironment
Bir dağıtım için hedef ortam, örneğin 'Staging' veya 'Production'.
Açıklama

Bu öznitelik, kodun nereye dağıtıldığını belirtir. Farklı ortamlara yapılan dağıtımları izlemek, geliştirmeden üretim yayınına kadar tüm yaşam döngüsünü anlamak için anahtardır.

Bu öznitelik, dağıtım alt sürecini analiz etmeye olanak tanır. Kodu staging'den production'a yükseltmenin ne kadar sürdüğünü ölçmek ve farklı ortamlara yapılan dağıtımların başarı oranını takip etmek için kullanılabilir. Bir geliştirme öğesinin ne zaman gerçekten 'tamamlandığını' ve kullanıcılara teslim edildiğini bilmek için hayati öneme sahiptir.

Neden önemli

Üretim öncesi ve üretim sürümleri arasında ayrım yapar; bu, gerçek 'pazara sunma süresini' ölçmek ve dağıtım modellerini analiz etmek için kritik öneme sahiptir.

Nereden alınır

Bu bilgi, genellikle CI/CD pipeline'ları veya diğer otomasyonlar tarafından tetiklenen GitHub Dağıtım API'sinden alınır.

Örnekler
developmentstagingüretim
Dal Adı
BranchName
Geliştirme öğesi için kod değişikliklerinin yapıldığı Git dalının adı.
Açıklama

Bir dal, ana kod tabanını etkilemeden yeni bir özellik veya hata düzeltmesi üzerinde çalışmak için oluşturulan bağımsız bir geliştirme hattıdır. Dal adı genellikle sorun numarası veya işin kısa bir açıklaması gibi faydalı bilgiler içerir.

Dal adlarını analiz etmek, dallanma stratejilerini ve geliştirme kurallarına uygunluğu anlamaya yardımcı olabilir. Ayrıca belirli kod commit'lerini bir geliştirme öğesine bağlayarak kodlama etkinliğinin eksiksiz bir resmini sunar.

Neden önemli

Geliştirmenin belirli hattı hakkında bağlam sağlar ve dallanma stratejileri ile adlandırma kurallarının uygulanmasına ve analiz edilmesine yardımcı olur.

Nereden alınır

Push olayları için 'ref' alanında veya bir çekme isteği API yanıtı içindeki 'head' ve 'base' nesnelerinde mevcuttur.

Örnekler
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Devir Bekleme Süresi
HandoffWaitingTime
Bir geliştirme öğesinin farklı kişiler tarafından gerçekleştirilen etkinlikler arasında bekleyerek geçirdiği hesaplanmış boş zaman.
Açıklama

Bu metrik, bir etkinliğin tamamlanması ile bir sonrakinin başlaması arasındaki süreyi ölçer, ancak yalnızca sorumlu kişi değiştiğinde. Örneğin, 'İnceleme Talep Edildi' event'i ile farklı bir kullanıcı tarafından 'İncelemede Değişiklik Talep Edildi' event'i arasındaki süre.

Bu, iletişim boşluklarını ve koordinasyon sorunlarını belirlemek için kritik bir metriktir. 'Kritik Devir Teslim Verimliliği' dashboard'unu ve 'Ortalama Devir Teslim Bekleme Süresi' KPI'ını destekler. Devir teslim noktalarındaki yüksek bekleme süreleri, genellikle kaynak kısıtlamalarının veya verimsiz bildirim süreçlerinin bir işaretidir.

Neden önemli

Farklı ekipler veya roller arasındaki geçişlerde (handoffs) zayıf koordinasyon veya kaynak yetersizliğinden kaynaklanan gecikmeleri tespit eder; bunlar genellikle başlıca verimsizlik kaynaklarıdır.

Nereden alınır

Sıralı etkinliklerde 'Atanan' veya 'Kullanıcı' özniteliğinin değiştiği durumları belirleyerek ve aralarındaki zaman farkını ölçerek hesaplanır.

Örnekler
PT1H15MP2DT4HPT25M
Etiketler
Labels
Bir sorunu veya çekme isteğini kategorize etmek için uygulanan etiketlerin veya işaretlerin bir listesi.
Açıklama

GitHub'daki etiketler, sorunlara ve çekme isteklerine meta veri eklemenin esnek bir yoludur. Öncelik, iş türü, bileşenler, ekipler veya durumu belirtmek için kullanılabilirler. Ham etiket listesi, zengin, yapılandırılmamış bir bağlam sağlar.

Öncelik ve Tür gibi belirli öznitelikler etiketlerden türetilse de, tam listeyi korumak geçici analizler ve diğer süreç modellerini keşfetmek için faydalı olabilir. Bu, herhangi bir etiket kombinasyonuna göre olayların esnek bir şekilde filtrelenmesine ve bölümlendirilmesine olanak tanır.

Neden önemli

İş öğelerini kategorize etmek için esnek, zengin bir metadata kaynağı sunar, derinlemesine ve çeşitli boyutlu analizlere olanak tanır.

Nereden alınır

GitHub API'sinden sorunlar ve çekme istekleri için JSON yükündeki 'labels' dizisi olarak mevcuttur. Dizideki her öğe, 'name' alanına sahip bir nesnedir.

Örnekler
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Geliştirme Döngü Süresi
DevelopmentCycleTime
Bir geliştirme öğesinin oluşturulmasından nihai dağıtımına veya kapatılmasına kadar geçen toplam süre.
Açıklama

Bu, tek bir geliştirme öğesi için en ilk event (örn. 'Sorun Oluşturuldu') ile son event (örn. 'Dağıtım Başarılı' veya 'Sorun Kapatıldı') arasındaki zaman farkı olarak hesaplanan case düzeyinde bir metriktir.

Bu, geliştirme sürecinin genel verimliliğini ölçmek için en önemli KPI'lardan biridir. 'Genel Geliştirme Döngü Süresi' dashboard'unu ve 'Ortalama Geliştirme Döngü Süresi' KPI'ını doğrudan destekler. Bu metriği azaltmak, genellikle süreç iyileştirme girişimlerinin birincil hedefidir.

Neden önemli

Bir geliştirme öğesi için uçtan uca 'piyasaya sürüm süresini' temsil eder, bu da genel süreç hızını ve verimliliğini ölçmek için kritik bir KPI'dır.

Nereden alınır

İlk etkinliğin zaman damgasını son etkinliğin zaman damgasından çıkararak olay düzeyinde hesaplanır.

Örnekler
P5DT6H30MP14DT12HP1DT2H
İnceleme Durumu
ReviewState
Bir çekme isteğindeki kod incelemesinin sonucu, örneğin 'Onaylandı' veya 'Değişiklik Talep Edildi'.
Açıklama

Bu öznitelik, bir gözden geçiren tarafından alınan kararı yakalar. Yaygın durumlar arasında kodun birleştirilmeye hazır olduğunu gösteren 'ONAYLANDI' ve yeniden çalışma gerektiğini gösteren 'DEĞİŞİKLİK TALEP EDİLDİ' bulunur. Diğer durumlar 'YORUM YAPILDI' veya 'BEKLEMEDE' olabilir.

Bu, yeniden çalışma ve kaliteyi analiz etmek için kritik bir özniteliktir. Yüksek sıklıkta 'DEĞİŞİKLİK TALEP EDİLDİ' event'leri, başlangıçtaki kod kalitesi sorunlarını veya belirsiz gereksinimleri gösterebilir. Bir geliştirme öğesinin ne zaman değişiklik için geri gönderildiğini belirleyerek 'Yeniden Çalışma ve Regresyon Döngüleri' dashboard'unu doğrudan destekler.

Neden önemli

Kod inceleme sürecindeki yeniden işleme döngülerini ve kalite kapılarını doğrudan göstererek, verimsizlik ve kalite sorunlarının kaynaklarını belirlemeye yardımcı olur.

Nereden alınır

GitHub API'sinden bir çekme isteği inceleme nesnesi içindeki 'state' alanı olarak mevcuttur. Örneğin, bir 'PullRequestReviewEvent' yükünde.

Örnekler
ONAYLANDICHANGES_REQUESTEDCOMMENTED
İnceleyen
Reviewer
Bir çekme isteğinde kod incelemesi yapması istenen kullanıcı.
Açıklama

Bir inceleyici, bir çekme isteğindeki kod değişikliklerini kalite, doğruluk ve standartlara uygunluk açısından denetlemekle görevlendirilmiş bir geliştirici veya ekip üyesidir. Bir çekme isteği birden fazla inceleyiciye sahip olabilir.

Bu öznitelik, kod inceleme sürecini analiz etmek için çok önemlidir. Belirli inceleyicilerle ilgili darboğazları belirlemeye, inceleme iş yükü dağılımını anlamaya ve inceleyicilerin isteklere yanıt verme süresini ölçmeye yardımcı olur. 'Ortalama Kod İnceleme Döngü Süresi' KPI'ını hesaplamak için temel bir bileşendir.

Neden önemli

Kalite güvence sürecine dahil olan bireyleri belirleyerek, inceleme iş yüklerinin, gecikmelerin ve kod incelemelerinin genel verimliliğinin analiz edilmesini sağlar.

Nereden alınır

GitHub API'sinden bir çekme isteği inceleme olayının 'requested_reviewers' dizisinde veya 'user' nesnesinde mevcuttur.

Örnekler
alex.chenmaria.garciasenior-dev-team
İşlem Süresi
ProcessingTime
Bir etkinliğin hesaplanan süresi, aktif çalışma süresini temsil eder.
Açıklama

İşlem Süresi, bir etkinliğin başlangıcı ile bitişi arasındaki geçen süredir. 'EndTimestamp' eksi 'EventTimestamp' olarak hesaplanır. Bu metrik, bir görevin tamamlanması için ne kadar sürdüğünü, görevin başlamasını bekleyerek geçirilen süre hariç olmak üzere ölçer.

İşlem süresini analiz etmek, aktif çaba açısından hangi etkinliklerin en çok zaman aldığını belirlemeye yardımcı olur. Bu, bekleme süresini içeren döngü süresinden farklıdır. Örneğin, bir kod incelemesi uzun bir döngü süresine ancak kısa bir işlem süresine sahip olabilir, bu da gözden geçirenin meşgul olduğunu ve PR'ın bir kuyrukta beklediğini gösterir.

Neden önemli

Aktif çalışma süresini ölçer, bir görev üzerinde harcanan süre ile onu bekleyerek geçen süre arasındaki farkı ayırt etmeye yardımcı olur, bu da hedefe yönelik verimlilik iyileştirmeleri için kilit noktadır.

Nereden alınır

Tek bir etkinlik kaydı için 'EventTimestamp' değerini 'EndTimestamp' değerinden çıkararak hesaplanır.

Örnekler
PT5M15SPT2H30MP1DT12H
Kaynak Sistem
SourceSystem
Geliştirme süreç verilerinin çıkarıldığı sistem.
Açıklama

Bu öznitelik, event verilerinin kaynağını tanımlar. Bu süreç için değer sürekli olarak 'GitHub' olacaktır. Geliştirme etkinliklerinin birden fazla sistemi kapsadığı daha karmaşık bir ortamda (örn. planlama için Jira, kod için GitHub, dağıtım için Jenkins), bu alan her event'in kaynağını ayırt etmek için kullanılır.

Analizde, verilerin doğrulanması ve sorun giderme için kaynağına geri izlenmesine yardımcı olur. Ayrıca, farklı platformları kapsayan süreçlerin analiz edilmesine olanak tanıyarak her etkinlik için net bir bağlam sağlar.

Neden önemli

Verinin kaynağını belirler; bu, veri doğrulaması ve birden fazla entegre sistemi kapsayabilecek süreçleri analiz etmek için temeldir.

Nereden alınır

Bu, genellikle kayıtların kaynağını etiketlemek için veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında eklenen statik bir değerdir.

Örnekler
GitHubGitHub Enterprise
Öğe Durumu
State
Bir sorun veya çekme isteğinin mevcut durumu, örneğin 'açık', 'kapalı' veya 'birleştirildi'.
Açıklama

Bu öznitelik, bir geliştirme öğesinin üst düzey durumunu gösterir. Sorunlar için tipik durumlar 'açık' ve 'kapalı'dır. Çekme istekleri için durumlar 'açık', 'kapalı' ve 'birleştirildi' içerir. Bu, öğenin ilerlemesinin bir anlık görüntüsünü sağlar.

Analizde, durum aktif ve tamamlanmış işi belirlemek için kullanılır. Devam eden işleri izleyen 'Aktif Geliştirme İlerlemesi' gibi Dashboard'lar için hayati öneme sahiptir. Ayrıca, bir sürecin sonunu tanımlamak için de kullanılır; örneğin, 'birleştirildi' veya 'kapalı' durumu bir case'in tamamlandığını işaret edebilir.

Neden önemli

Bir iş öğesinin şu anda devam edip etmediğine veya tamamlanıp tamamlanmadığına dair net bir gösterge sağlar; bu, yaşam döngüsü analizi ve aktif işin izlenmesi için temeldir.

Nereden alınır

GitHub API'sinden sorunlar ve çekme istekleri için JSON yüklerindeki 'state' alanı olarak doğrudan mevcuttur.

Örnekler
openkapalıbirleştirildi
Son Veri Güncellemesi
LastDataUpdate
Bu kayda ait verilerin kaynak sistemden en son ne zaman güncellendiğini gösteren zaman damgası.
Açıklama

Bu öznitelik, en son veri çıkarımının veya güncellemesinin tarih ve saatini kaydeder. Analiz edilen verinin tazeliği hakkında metadata sağlar. Bu, iş event'inin ne zaman gerçekleştiğini kaydeden event timestamp'inden farklıdır.

Analizde, bu alan süreç görünümünün güncelliğini anlamak için çok önemlidir. Kullanıcıların gerçek zamanlı verilere mi yoksa belirli bir zaman noktasından alınmış bir anlık görüntüye mi baktıklarını bilmelerine yardımcı olur, bu da operasyonel Dashboard'lar ve izleme için önemlidir.

Neden önemli

Verilerin güncelliğini gösterir; bu, analizlerin ve Dashboardların güncel bilgilere dayanmasını sağlamak için kritiktir.

Nereden alınır

Bu timestamp, veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında oluşturulur ve eklenir.

Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Yazar
Author
Sorunu, çekme isteğini veya commit'i oluşturan kullanıcı.
Açıklama

Yazar, geliştirme sürecindeki belirli bir yapıtın yaratıcısıdır. Örneğin, bir sorunun yazarı hatayı bildiren veya özelliği talep eden kişidir. Bir çekme isteğinin yazarı kodu yazan geliştiricidir.

Analizde, yazar işin kaynaklarını anlamak için kullanılabilir. Örneğin, hata raporlarının yazarlarını analiz etmek, belirli ekipler veya özelliklerle ilgili kalıpları ortaya çıkarabilir. Ayrıca, devir teslim modellerini analiz etmek için atanan kişiyle birlikte de kullanılabilir.

Neden önemli

Bir iş öğesinin veya kod değişikliğinin kaynağını belirler; bu, yeniden işleme kaynaklarını, hata raporlarını veya özellik taleplerini analiz etmek için faydalı olabilir.

Nereden alınır

Sorunlar, çekme istekleri ve commit'ler için API yanıtlarının ana nesnesi içindeki 'user' nesnesinde mevcuttur. Alan genellikle 'user.login' şeklindedir.

Örnekler
sara.jonesmike.leeautomation-bot
Yeniden İşleme mi?
IsRework
Bir etkinliğin önceki bir süreç aşamasına geri dönüşü temsil etmesi durumunda doğru olan bir boolean bayrağıdır.
Açıklama

Bu bayrak, bir geliştirme öğesi süreçte geriye doğru hareket ettiğinde (örneğin, bir çekme isteği 'Değişiklik Talep Edildi' incelemesi aldığında veya bir sorun kapatıldıktan sonra yeniden açıldığında) doğru olarak ayarlanır. Etkinliklerin dizisi analiz edilerek elde edilir.

Bu öznitelik, israfı ve verimsizliği nicelendirmek için hayati öneme sahiptir. 'Yeniden Çalışma ve Regresyon Döngüleri' dashboard'unu ve 'Yeniden Çalışma Oranı' KPI'ını doğrudan destekler. 'IsRework = true' filtresiyle, analistler yeniden çalışma nedenlerini izole edebilir ve araştırabilir.

Neden önemli

Yeniden işleme oluşturan etkinlikleri açıkça işaretleyerek, süreç verimsizliklerinin nedenlerini nicelendirmeyi, görselleştirmeyi ve analiz etmeyi kolaylaştırır.

Nereden alınır

Bu, türetilmiş bir özniteliktir. Mantık, standart bir süreç akışı tanımlamayı ve ardından daha önceki mantıksal bir aşamaya dönerek sapan herhangi bir etkinliği işaretlemeyi içerir.

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

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

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.
6 Önerilen 7 İsteğe Bağlı
Aktivite Açıklama
Çekme İsteği Açıldı
Bir ilk kod bloğunun inceleme ve entegrasyon için hazır olduğunu gösterir. Bir geliştirici, özellik dalından ana dal'a değişiklikler önermek için bir çekme isteği (PR) oluşturur. Bu, GitHub'da açık bir event'tir.
Neden önemli

Bu, ilk geliştirme aşamasının sonunu ve inceleme ve entegrasyon pipeline'ının başlangıcını işaret eden kritik bir dönüm noktasıdır. Geliştirme ve inceleme döngü sürelerini ayrı ayrı analiz etmek için anahtardır.

Nereden alınır

GitHub Çekme İsteği API olay akışından veya webhook'lardan alınır. Olay eylemi 'açıldı' şeklindedir.

Yakala

Bir çekme isteği için 'opened' eylemini webhook'lar veya API sorgulama yoluyla dinleyin.

Event tipi explicit
Çekme İsteği Birleştirildi
Çekme isteğinden onaylanan kod değişiklikleri, main veya develop gibi hedef dala resmi olarak entegre edilir. Bu, yeni kodu içeren bir çekme isteği üzerindeki açık, son bir eylemdir.
Neden önemli

Bu, geliştirme ve incelemenin tamamlanmasını temsil eden kritik bir dönüm noktasıdır. Birçok ekip için bu, otomatik dağıtımdan önceki son adımdır.

Nereden alınır

GitHub Çekme İsteği API olay akışından veya webhook'lardan alınır. Olay eylemi 'kapalı' ve çekme isteği yükünün 'merged' özniteliği doğru (true) şeklindedir.

Yakala

Çekme isteğindeki 'closed' eylemini dinleyin ve 'merged' bayrağının doğru olup olmadığını kontrol edin.

Event tipi explicit
Çekme İsteği Onaylandı
Bir inceleyici, bir çekme isteğindeki değişiklikleri resmi olarak onaylayarak kalite ve işlevsel standartları karşıladığını belirtir. Bu, bir inceleyicinin 'onaylandı' durumuyla incelemesini gönderdiğinde kaydedilir.
Neden önemli

Bu, birleştirmeden önce önemli bir kalite kapısı ve önemli bir dönüm noktasıdır. PR oluşturmadan bu duruma ulaşmak için geçen süre, inceleme süreç verimliliği için kritik bir KPI'dır.

Nereden alınır

Bir inceleme 'ONAYLANDI' durumuyla gönderildiğinde GitHub Çekme İsteği API'sinden veya webhook'lardan alınır.

Yakala

Onaylandı (APPROVED) durumu için çekme isteği inceleme gönderim olaylarını filtreleyin.

Event tipi explicit
CI Kontrolleri Başarılı Oldu
Bir çekme isteğindeki koda karşı çalıştırılan derlemeler, birim testleri veya statik analiz gibi otomatik kontrollerin başarılı bir şekilde tamamlanmasını temsil eder. Bu event, GitHub Actions gibi sistemler tarafından bildirilen kontrollerin durumundan çıkarılır.
Neden önemli

Bu otomatik kalite kapısı, kod kararlılığını sağlamak için hayati önem taşır. Başarısızlıklar veya uzun çalışma süreleri, teslimat pipeline'ında önemli darboğazlar olabilir.

Nereden alınır

GitHub Checks API veya Statuses API'sinden çıkarılır. Bir kontrol çalıştırması veya durum güncellemesi, 'başarı' veya 'tamamlandı' durumuyla 'başarı' sonucunu raporlar.

Yakala

İlgili kontrol paketlerinde 'success' (başarılı) sonucu için Checks API'yi izleyin.

Event tipi inferred
Sorun Kapatıldı
Geliştirme öğesi tamamlanmış sayılır ve ilgili sorun resmi olarak kapatılır. Bu, bağlantılı bir çekme isteği birleştirildiğinde otomatik olarak gerçekleşebilir veya bir ekip üyesi tarafından manuel olarak yapılabilir.
Neden önemli

Bu etkinlik, bir geliştirme öğesi için sürecin kesin sonu olarak hizmet eder. Uçtan uca döngü sürelerini hesaplamak için kritiktir.

Nereden alınır

Bu, GitHub Sorunları API event akışından yakalanan açık bir event'tir. Event türü 'closed' (kapatıldı)dır.

Yakala

Bir konu üzerindeki 'closed' event'ini webhook'lar veya API sorgulama yoluyla dinleyin.

Event tipi explicit
Sorun Oluşturuldu
Bir geliştirme öğesinin yaşam döngüsünün başlangıcını işaret eder; bir görev, hata veya özellik isteğinin resmi olarak oluşturulmasını temsil eder. Bu event, bir kullanıcı GitHub deposunda yeni bir sorun oluşturduğunda açıkça yakalanır.
Neden önemli

Bu, sürecin birincil başlangıç etkinliğidir, toplam geliştirme döngü süresini ölçmek ve işin ilk kaynaklarını anlamak için hayati öneme sahiptir.

Nereden alınır

Bu, GitHub Sorunları API event akışından yakalanan açık bir event'tir. Event türü genellikle belirli bir sorun numarası için 'opened' (açıldı)dır.

Yakala

Bir konu üzerindeki 'opened' event'ini webhook'lar veya API sorgulama yoluyla dinleyin.

Event tipi explicit
CI Kontrolleri Başarısız Oldu
Bir çekme isteğindeki koda karşı çalıştırılan bir derleme hatası veya başarısız birim testi gibi otomatik bir kontrolün başarısızlığını temsil eder. Bu, GitHub Actions gibi bir sistem tarafından bildirilen bir hata durumundan çıkarılır.
Neden önemli

Bu etkinlik, geliştirici müdahalesi gerektiren teknik kalite sorunlarını vurgulayarak bir yeniden çalışma döngüsü oluşturur. Hata sıklığını analiz etmek, yerel test veya kod kalitesinde iyileştirmelere rehberlik edebilir.

Nereden alınır

GitHub Checks API veya Statuses API'sinden çıkarılır. Bir kontrol çalıştırması veya durum güncellemesi, 'başarısızlık' veya 'tamamlandı' durumuyla 'başarısızlık' sonucunu raporlar.

Yakala

İlgili kontrol paketlerinde 'failure' (başarısızlık) sonucu için Checks API'yi izleyin.

Event tipi inferred
Dağıtım Başarılı Oldu
Kod değişiklikleri, staging veya production gibi belirli bir ortama başarıyla dağıtıldı. Bu event genellikle GitHub Deployments API aracılığıyla yakalanır ve çoğu zaman bir birleştirmeden sonra bir GitHub Action tarafından tetiklenir.
Neden önemli

Kodun depodan canlı ortama geçişini işaret eder. Bunu takip etmek, fikirden üretime kadar olan toplam teslim süresini ölçmek için hayati önem taşır.

Nereden alınır

Dağıtım API'si aracılığıyla yakalanır. Harici bir hizmet veya GitHub Action, bir dağıtım oluşturur ve ardından durumunu 'başarılı' olarak günceller.

Yakala

Dağıtım durumu event'lerini webhook'lar aracılığıyla 'success' (başarılı) durumu için izleyin.

Event tipi inferred
Dal Oluşturuldu
Bir geliştiricinin ana kod tabanından yeni bir dal oluşturduğu, bir sorun için aktif geliştirme çalışmasının başlangıcını temsil eder. Bu, genellikle sorun numarasını içeren yeni bir dal depoya yüklendiğinde yakalanan açık bir event'tir.
Neden önemli

Planlamadan aktif kodlamaya geçişi gösterir. Sorun oluşturma ile bu olay arasındaki süreyi ölçmek, geliştirici teslim süresini ve ilk birikim gecikmelerini analiz etmeye yardımcı olur.

Nereden alınır

GitHub Git API'si veya 'dal' türündeki 'oluşturma' olaylarını dinleyen webhook'lar aracılığıyla yakalanır. Genellikle dal adını 'feature/issue-123' gibi adlandırma kuralları aracılığıyla bir soruna bağlamak gerekir.

Yakala

Yeni dallar için 'create' webhook event'lerini ayrıştırın ve bunları bir sorunla ilişkilendirin.

Event tipi explicit
İnceleme Talep Edildi
Bir çekme isteğinin yazarı, belirli ekip üyelerinden veya ekiplerden kodlarını incelemelerini resmi olarak talep eder. Bu, GitHub UI veya API içinde istenen gözden geçirenlere bildirimleri tetikleyen açık bir eylemdir.
Neden önemli

Bu etkinlik, kod inceleme sürecine devir teslimin resmi başlangıcını işaret eder. Bununla bir inceleme gönderimi arasındaki süre, gözden geçirenin yanıt verme hızını ve potansiyel darboğazları ölçmeye yardımcı olur.

Nereden alınır

GitHub Çekme İsteği API olay akışından veya webhook'lardan alınır. Olay eylemi 'inceleme talep edildi' şeklindedir.

Yakala

Bir çekme isteği için 'review_requested' eylemini dinleyin.

Event tipi explicit
İncelemede Değişiklik Talep Edildi
Bir inceleyici, kod incelemesini tamamladı ve çekme isteğinin onaylanmasından önce değişikliklerin gerekli olduğuna karar verdi. İnceleyici, 'değişiklik talebi' durumuyla incelemesini resmi olarak gönderir.
Neden önemli

Bu event, bir yeniden çalışma döngüsünü açıkça işaret eder. Sıklığını analiz etmek, kalite sorunlarını, belirsiz gereksinimleri veya geliştirici eğitimi için alanları belirlemeye yardımcı olur.

Nereden alınır

Bir inceleme 'DEĞİŞİKLİK TALEP EDİLDİ' durumuyla gönderildiğinde GitHub Çekme İsteği API'sinden veya webhook'lardan alınır.

Yakala

Değişiklik Talep Edildi (CHANGES_REQUESTED) durumu için çekme isteği inceleme gönderim olaylarını filtreleyin.

Event tipi explicit
Koda PR'a Gönderildi
İnceleme için gönderilen kodda, ilk PR'ın bir parçası olarak veya inceleme geri bildirimine yanıt olarak yapılan bir güncellemeyi temsil eder. Bu event, açık bir çekme isteğiyle ilişkili dal'a yeni bir commit yüklendiğinde her seferinde yakalanır.
Neden önemli

Bu event'leri izlemek, yeniden çalışma döngülerini belirlemek için hayati önem taşır. Bir incelemeden sonra birden fazla yükleme, değişikliklerin gerekli olduğunu gösterir ve genel döngü süresini etkiler.

Nereden alınır

Bu, çekme isteği zaman çizelgesinde, genellikle bir commit'in eklendiği olarak etiketlenen açık bir event'tir. 'Push' webhook'undan veya bir PR ile ilişkili commit'ler izlenerek yakalanabilir.

Yakala

Açık bir çekme isteğiyle ilişkili bir daldaki 'push' event'lerini izleyin.

Event tipi explicit
Sorun Yeniden Açıldı
Daha önce kapatılmış bir sorun, genellikle düzeltmenin yetersiz olması veya bir gerileme tespit edilmesi nedeniyle yeniden etkinleştirilir. Bu, geliştirme öğesi için yaşam döngüsünü yeniden başlatan açık bir olaydır.
Neden önemli

Bu, potansiyel bir 'üretim hata kaçışı' veya eksik düzeltmeyi gösteren önemli bir yeniden çalışma döngüsünü işaret eder. Sıklığını izlemek, genel yazılım kalitesinin önemli bir ölçüsüdür.

Nereden alınır

Bu, GitHub Sorunları API event akışından yakalanan açık bir event'tir. Event türü 'reopened' (yeniden açıldı)dır.

Yakala

Bir konu üzerindeki 'reopened' event'ini webhook'lar veya API sorgulama yoluyla dinleyin.

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

Veri Çekim Kılavuzları

GitHub'dan verilerinizi nasıl alırsınız?