Yazılım Geliştirme Yaşam Döngüsü Veri Template'inuz
Yazılım Geliştirme Yaşam Döngüsü Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Veri Çekim Kılavuzu
Yazılım Geliştirme Yaşam Döngüsü Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Yazılım geliştirme süreç döngüsü içinde gerçekleşen belirli bir olayı veya görevin adı. | ||
|
Açıklama
Aktivite 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?dir?
Bu öznitelik, süreç haritasının temelini oluşturur ve geliştirme süreç döngüsündeki olayların dizisinin görselleştirilmesine ve analiz edilmesine sunar.
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 olayınin gerçekleştiği tam tarih ve saat. | ||
|
Açıklama
Bu zaman damgası (zaman damgası), 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 olayları kronolojik olarak sıralamak için büyük önem taşır. Bu zaman damgası (zaman damgası)'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 gereklidir. Adımlar arasındaki gecikmelerin belirlenmesine sunar ve darboğaz analizi ile performans izleme Dashboard'ları için gerekli verileri sunar.
Neden Önemli?dir?
Bu zaman damgası (zaman damgası), olayları doğru şekilde sıralamak ve döngü süreleri ve darboğaz süreleri gibi tüm performans metriklerini hesaplamak için büyük önem taşır.
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 vaka tanımlayıcısı olarak olarak kullanılır. | ||
|
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 sunar.
Neden Önemli?dir?
Proses madenciliği için temel büyük önem taşır; ilgili tüm geliştirme olaylarını tek bir olaya bağlayarak uçtan uca yazılım geliştirme süreç döngüsünü doğru bir şekilde görselleştirmeyi ve analiz etmeyi sunar.
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 olaylarınin 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 temel rol oynar. 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ı güçlüak için atanana göre filtrelenebilir.
Neden Önemli?dir?
Geliştirici iş yükü, ekip performansı ve farklı ekip üyeleri arasındaki devirlerin verimliliğini analiz etmek için büyük önem taşır.
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ş Zamanı
EndTimestamp
|
Belirli bir geliştirme etkinliğinin veya olayınin tamamlandığı tam tarih ve saat. | ||
|
Açıklama
Bitiş zaman damgası (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 önemlidir. İşlem sürelerini analiz etmek, çok fazla zaman tüketen verimsiz etkinlikleri belirlemeye yardımcı olur.
Neden Önemli?dir?
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ı (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ğı sunar. Analizde, bu öznitelik farklı projelerdeki süreç performansını filtrelemeye ve karşılaştırmaya sunar. '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 büyük önem taşır.
Neden Önemli?dir?
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ı sunar.
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 büyük önem taşır, çü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ı sunar. 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?dir?
İş öğ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ı sunar.
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 büyük önem taşır. 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 sunar. Önceliklendirme sürecinin etkinliğini değerlendirmeye yardımcı olur.
Neden Önemli?dir?
Yüksek öncelikli öğelerin düşük öncelikli öğelerden daha hızlı işlenip işlenmediğinin analizini sunar, 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 süreç döngüsü içindeki kod entegrasyonu ve inceleme alt sürecini izlemek için büyük önem taşır. İ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 sunar. Planlama aşamasını (sorun) uygulama aşamasına (PR) bağlar.
Neden Önemli?dir?
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 sunar.
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 iş akışlarını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?dir?
Otomatik kalite kapılarının başarısını veya başarısızlığını göstererek kod kalitesi ve CI veri hattının etkinliği hakkında önemli bilgi sunar.
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 sunar. Analistlerin bir süreç olayını doğrudan yapılan tam kod değişikliğine geri bağlamasına sunar. Bu, denetim, uyumluluk veya üretimdeki olayların ayrıntılı kök neden analizi için çok değerli olabilir.
Neden Önemli?dir?
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 süreç döngüsünü anlamak için temel rol oynar. Bu öznitelik, dağıtım alt sürecini analiz etmeye sunar. 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 büyük önem taşır.
Neden Önemli?dir?
Ü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 büyük önem taşır.
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?dir?
Geliştirmenin belirli hattı hakkında bağlam sunar 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' kontrol paneli'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?dir?
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 sunar. Ö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 sunar.
Neden Önemli?dir?
İş öğelerini kategorize etmek için esnek, zengin bir metaveri kaynağı sunar, derinlemesine ve çeşitli boyutlu analizlere sunar.
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 vaka 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' kontrol paneli'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?dir?
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ı (zaman damgası)nı son etkinliğin zaman damgası (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İ' olayları, 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ışanşma ve Regresyon Döngüleri' kontrol paneli'unu doğrudan destekler.
Neden Önemli?dir?
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 büyük önem taşır. 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?dir?
Kalite güvence sürecine dahil olan bireyleri belirleyerek, inceleme iş yüklerinin, gecikmelerin ve kod incelemelerinin genel verimliliğinin analiz edilmesini sunar.
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
|
|||
|
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 olayın 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 sunar.
Neden Önemli?dir?
Verinin kaynağını belirler; bu, veri doğrulaması ve birden fazla entegre sistemi kapsayabilecek süreçleri analiz etmek için büyük önem taşır.
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 güncel durumunu gösterir. 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 büyük önem taşır. 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?dir?
Bir iş öğesinin şu anda devam edip etmediğine veya tamamlanıp tamamlanmadığına dair net bir gösterge sunar; bu, süreç döngüsü analizi ve aktif işin izlenmesi için büyük önem taşır.
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ı (zaman damgası)dır. | ||
|
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 meta veri sunar. Bu, iş olayınin ne zaman gerçekleştiğini kaydeden event zaman damgası (zaman damgası)'inden farklıdır. Analizde, bu alan süreç görünümünün güncelliğini anlamak için büyük önem taşır. 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?dir?
Verilerin güncelliğini gösterir; bu, analizlerin ve
Nereden Alınır??
Bu zaman damgası (zaman damgası), veri çıkarma, dönüştürme ve yükleme (
Ö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?dir?
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 mantıksal (boolean) değerdir. | ||
|
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 büyük önem taşır. 'Yeniden Çalışanşma ve Regresyon Döngüleri' kontrol paneli'unu ve 'Yeniden Çalışanşma Oranı' KPI'ını doğrudan destekler. 'IsRework = true' filtresiyle, analistler yeniden çalışma nedenlerini izole edebilir ve araştırabilir.
Neden Önemli?dir?
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ü Faaliyetleri
| 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?dir?
Bu, ilk geliştirme aşamasının sonunu ve inceleme ve entegrasyon veri hattı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 temel rol oynar.
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?dir?
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
|
|||
|
CI Kontrolleri Geçti
|
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?dir?
Bu otomatik kalite kapısı, kod kararlılığını güçlüak için önemlidir. Başarısızlıklar veya uzun çalışma süreleri, teslimat veri hattı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
|
|||
|
Pull Request 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?dir?
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
|
|||
|
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?dir?
Bu etkinlik, bir geliştirme öğesi için sürecin kesin sonu olarak olarak kullanılır. Uçtan uca döngü sürelerini hesaplamak için büyük önem taşır.
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' olayıni webhook'lar veya API sorgulama yoluyla dinleyin.
Event tipi
explicit
|
|||
|
Sorun Oluşturuldu
|
Bir geliştirme öğesinin süreç 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?dir?
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 büyük önem taşır.
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' olayıni 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?dir?
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
|
|||
|
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?dir?
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 olaylarıni 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?dir?
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?dir?
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?dir?
Bu olayları izlemek, yeniden çalışma döngülerini belirlemek için önemlidir. 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' olaylarıni 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 süreç döngüsünü yeniden başlatan açık bir olaydır. | ||
|
Neden Önemli?dir?
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' olayıni webhook'lar veya API sorgulama yoluyla dinleyin.
Event tipi
explicit
|
|||
|
Yayınlama 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?dir?
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 önemlidir.
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 olaylarıni webhook'lar aracılığıyla 'success' (başarılı) durumu için izleyin.
Event tipi
inferred
|
|||