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
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
Yazılım Geliştirme Yaşam Döngüsü Nitelikleri
| 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
Nereden alınır
Bu
Ö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
|
|||
Yazılım Geliştirme Yaşam Döngüsü Etkinlikleri
| 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
|
|||