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

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

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

Bu Template, GitHub verilerinizi yazılım geliştirme yaşam döngüsü analizi için toplama ve hazırlama konusunda ayrıntılı bir rehber sunar. Eklenmesi önerilen öznitelikleri, izlenmesi gereken temel etkinlikleri ve veri çıkarma adımlarını bulabilirsiniz. Etkili süreç analizi ve iyileştirme için doğru bir Event Log oluştururken bu kaynaktan yararlanın.
  • Toplanması önerilen öznitelikler
  • İzlenecek temel etkinlikler
  • Veri çıkarma rehberi
Olay günlüklerine yeni misiniz? Process Mining için nasıl Event Log oluşturacağınızı öğrenin.

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

Yazılım geliştirme yaşam döngüsünü ayrıntılı biçimde analiz etmek ve süreçleri keşfetmek için Event Loga eklemeniz önerilen veri alanları şunlardır.
3 Zorunlu 5 Önerilen 15 İsteğe bağlı
Ad Açıklama
Başlangıç zamanı
EventTimestamp
Belirli bir geliştirme etkinliğinin veya olayının gerçekleştiği kesin tarih ve saat.
Açıklama

Bu zaman damgası, bir etkinliğin başlangıcını gösterir. Her geliştirme işi için süreç akışını yeniden oluşturmak üzere olayları kronolojik sıraya koymak açısından önemlidir. Süreç performansını analiz ederken bu zaman damgalarının sırası ve aralarındaki süre kullanılır.

Analizde bu öznitelik; çevrim süreleri, işlem süreleri ve bekleme süreleri dâhil zamana dayalı tüm metrikleri hesaplamak için gereklidir. Adımlar arasındaki gecikmeleri belirlemenizi sağlar ve darboğaz analizi ile performans izleme Dashboardları için gereken verileri sunar.

Neden önemli?

Bu zaman damgası, olayları doğru sıraya koymak ve çevrim süreleri ile darboğaz süreleri gibi tüm performans metriklerini hesaplamak için önemlidir.

Nereden alınır?

GitHub API’lerinden ve webhooklardan gelen; sorun, pull request ve commit gibi çeşitli nesnelere ait JSON verilerinde genellikle 'created_at' veya 'updated_at' alanı olarak bulunur.

Örnekler
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Etkinlik
ActivityName
Yazılım geliştirme yaşam döngüsünde gerçekleşen belirli bir olayın veya görevin adı.
Açıklama

Etkinlik adı, geliştirme sürecindeki 'Sorun oluşturuldu', 'PR’ye kod gönderildi', 'Pull request onaylandı' veya 'Dağıtım başarılı' gibi tek bir adımı tanımlar. Bu olaylar, bir geliştirme işinin uçtan uca sürecini oluşturan adımların sırasını belirler.

Bu öznitelik, süreç haritasını oluşturmak için kullanıldığından Process Mining açısından temel niteliktedir. Etkinliklerin sırasını, sıklığını ve süresini analiz ederek gerçek süreç akışını görebilir, yaygın yolları belirleyebilir, sapmaları ortaya çıkarabilir ve darboğazları tespit edebilirsiniz.

Neden önemli?

Bu öznitelik, geliştirme yaşam döngüsündeki olayların sırasını görselleştirmeyi ve analiz etmeyi sağlayarak süreç haritasının temelini oluşturur.

Nereden alınır?

Webhook olay verilerindeki 'action' alanından (örneğin, bir sorun için 'opened' veya 'closed') ya da doğrudan olay türünden (örneğin, 'PushEvent' veya 'PullRequestReviewEvent') alınır.

Örnekler
Sorun oluşturulduPull request açıldıPR’ye kod gönderildiİnceleme talep edildiPull request birleştirildi
Geliştirme işi
DevelopmentItemId
Özellik, hata düzeltmesi veya görev gibi tek bir geliştirme işinin benzersiz tanımlayıcısıdır. Bu değer, birincil vaka kimliği olarak kullanılır.
Açıklama

Geliştirme işi kimliği, iş öğesini oluşturulmasından son dağıtımına kadar izler. Dal oluşturma, commitler, pull requestler, incelemeler ve dağıtımlar gibi ilişkili tüm etkinlikleri tek bir süreç örneğinde bir araya getirir.

Analizde bu kimlik, bir geliştirme görevinin uçtan uca çevrim süresini hesaplamak için kullanılır. Özellik veya hata düzeltmesi sürecinin tamamını yeniden oluşturmanızı; tek tek iş öğelerindeki darboğazları, yeniden çalışma döngülerini ve süreç farklılıklarını ayrıntılı biçimde incelemenizi sağlar.

Neden önemli?

Process Mining için temel anahtardır. İlgili tüm geliştirme olaylarını tek bir vakada birleştirerek yazılım geliştirme yaşam döngüsünü uçtan uca doğru biçimde görselleştirmenizi ve analiz etmenizi sağlar.

Nereden alınır?

Bu değer genellikle GitHub’daki sorun numarası veya pull request numarasıdır. Sorun ya da pull request ile ilgili webhook olaylarının veya API yanıtlarının verilerindeki 'number' alanından alınabilir.

Örnekler
101PR-2345TASK-812
Atanan kullanıcı
Assignee
Geliştirme işini veya pull request incelemesi gibi belirli bir görevi üstlenen kullanıcı ya da geliştirici.
Açıklama

Bu öznitelik, belirli bir aşamadaki işten sorumlu kişiyi belirtir. Bu kişi, bir soruna atanan kullanıcı, pull request yazarı veya kod incelemesi için talep edilen incelemeci olabilir. Kaynak dağılımını ve iş yükünü anlamak için atanan kişiyi izlemek önemlidir.

Analizde bu öznitelik, geliştirici iş yükünü izlemek, kaynak darboğazlarını belirlemek ve ekip üyeleri arasındaki devir teslim verimliliğini incelemek için kullanılır. Dashboardları atanan kişiye göre filtreleyerek bireysel veya ekip performansını değerlendirebilir ve işlerin dengeli dağıtılmasını sağlayabilirsiniz.

Neden önemli?

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

Nereden alınır?

GitHub API’sinden alınan sorun, pull request ve inceleme olaylarına ait JSON verilerindeki 'assignee' veya 'user' nesnesinde bulunur.

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

Bitiş zaman damgası, bir etkinliğin tamamlandığını gösterir. GitHub’daki birçok olay anlık gerçekleşir (örneğin, 'Sorun oluşturuldu'), ancak bazı etkinliklerin ölçülebilir bir süresi vardır (örneğin, çalışan bir CI kontrolü). Bitiş zamanı ile başlangıç zamanı arasındaki fark, etkinliğin işlem süresini verir.

Bu öznitelik, kod incelemesi veya otomatik kontroller gibi görevlerde harcanan etkin çalışma süresini anlamak için önemli olan 'ProcessingTime' metriğini hesaplamada kullanılır. İşlem sürelerini analiz ederek gereğinden fazla zaman alan verimsiz etkinlikleri belirleyebilirsiniz.

Neden önemli?

Etkinliklerin işlem sürelerini hassas biçimde hesaplamayı sağlar. Böylece etkin çalışma süresiyle boşta bekleme süresini birbirinden ayırabilirsiniz.

Nereden alınır?

Kontrol çalıştırma nesnelerinde 'completed_at' alanı olarak bulunabilir veya mantıksal olarak etkinliği tamamlayan sonraki olayın zaman damgasından çıkarılabilir.

Örnekler
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Depo
RepositoryName
Geliştirme etkinliğinin yürütüldüğü kod deposunun adı.
Açıklama

Depo, belirli bir uygulama veya bileşene ait tüm kodları, sorunları ve pull requestleri içerir; proje ya da ürün tanımlayıcısı olarak işlev görür. Farklı ürünler veya ekipler arasındaki geliştirme süreçlerini gruplandırıp karşılaştırmanızı sağlar.

Analizde bu öznitelik, farklı projelerin süreç performansını filtrelemeye ve karşılaştırmaya yardımcı olur. 'Hangi projede çevrim süresi en uzun?' veya 'A projesindeki hata düzeltme süreci, B projesininkiyle nasıl karşılaştırılır?' gibi soruları yanıtlamanızı sağlar. 'Projeye ve türe göre işlem hacmi' Dashboardu için gereklidir.

Neden önemli?

Geliştirme süreçlerini farklı projelere, ürünlere veya ekiplere göre gruplandırıp karşılaştırmanızı ve analizi belirli alanlara odaklamanızı sağlar.

Nereden alınır?

Neredeyse tüm GitHub webhook ve API verilerindeki 'repository' nesnesinde bulunur. İlgili alan genellikle 'repository.full_name' veya 'repository.name' olur.

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

Bu öznitelik, yapılan işin türünü sınıflandırır. Bu bilgi genellikle GitHub etiketleri veya belirli sorun şablonlarıyla yönetilir. İş türünü anlamak, uygun performans beklentileri belirlemek için önemlidir; bir hata düzeltmesinin beklenen çevrim süresi, yeni bir özelliğinkinden çok daha kısa olabilir.

Bu öznitelik, farklı iş türlerini karşılaştırmalı olarak analiz etmenizi sağlar. Hata düzeltmelerinin yeni özelliklerden daha hızlı tamamlanıp tamamlanmadığını inceleyebilir veya teknik borç ile yeni geliştirme işleri arasındaki kaynak dağılımını anlayabilirsiniz. 'Projeye ve türe göre işlem hacmi' Dashboardunun temel boyutlarından biridir.

Neden önemli?

İş öğelerini sınıflandırır; performansı karşılaştırmanızı ve farklı iş türlerinin (örneğin, hatalar ve özellikler) süreçte nasıl ilerlediğini analiz etmenizi sağlar.

Nereden alınır?

Genellikle sorunlara veya pull requestlere eklenen GitHub etiketlerinden alınır. Tutarlı bir etiketleme kuralı (örneğin, 'type:bug', 'type:feature') gerektirir.

Örnekler
HataÖzellikGörevTeknik borç
Öncelik
Priority
Geliştirme öğesine atanan öncelik düzeyi; örneğin 'Yüksek', 'Orta' veya 'Düşük'.
Açıklama

Öncelik, bir iş öğesinin aciliyetini veya iş açısından önemini belirtir. GitHub’da öncelik yerleşik bir alan değildir; genellikle etiketlerle (ör. 'P1-Yüksek', 'P2-Orta') yönetilir. Bu bilgiyi güvenilir biçimde çıkarmak için tutarlı bir etiketleme düzeni gerekir.

Bu öznitelik, 'Önceliğe Dayalı Akış Analizi' için gereklidir. Analistlerin yüksek öncelikli öğelerin düşük öncelikli öğelerden gerçekten daha hızlı işlenip işlenmediğini doğrulamasına ve önceliğe göre çevrim süresi farkını ölçmesine imkân verir. Önceliklendirme sürecinin ne kadar etkili olduğunu değerlendirmeye yardımcı olur.

Neden önemli?

Yüksek öncelikli öğelerin düşük öncelikli öğelerden daha hızlı işlenip işlenmediğini analiz etmeyi ve önceliklendirme stratejisinin etkinliğini doğrulamayı sağlar.

Nereden alınır?

Sorunlara veya pull request’lere uygulanan GitHub etiketlerinden elde edilir. Öncelik etiketleri için standart bir adlandırma kuralı gerekir.

Örnekler
YüksekOrtaDüşükKritik
CI kontrol durumu
CiCheckStatus
'Başarılı' veya 'başarısız' gibi otomatik Sürekli Entegrasyon (CI) kontrolünün durumu.
Açıklama

Bu öznitelik, pull request’teki kod değişiklikleri üzerinde çalışan otomatik derleme, test ve taramaların sonucunu gösterir. CI kontrolleri, günümüz geliştirme iş akışlarında önemli bir kalite kapısıdır.

Bu özniteliği analiz etmek, otomatik testlerin ne kadar etkili olduğunu anlamaya yardımcı olur. Yüksek başarısızlık oranı; kod kararlılığı, test paketi veya geliştirme ortamıyla ilgili sorunlara işaret edebilir. 'CI Kontrolleri Başarılı' ve 'CI Kontrolleri Başarısız' etkinliklerini destekler, başarısız derlemelerin yol açtığı gecikmelerin analizine yardımcı olur.

Neden önemli?

Otomatik kalite kapılarının başarılı veya başarısız olduğunu göstererek kod kalitesi ve CI hattının etkinliği hakkında bilgi sağlar.

Nereden alınır?

GitHub Checks veya Statuses API’si üzerinden alınan check run ya da status nesnelerinin 'state' veya 'conclusion' alanından elde edilir.

Örnekler
successfailurependingerror
Commit özeti
CommitHash
Belirli bir kod commit’inin benzersiz tanımlayıcısı (SHA).
Açıklama

Commit özeti, Git’teki bir commit’i benzersiz biçimde tanımlayan 40 karakterlik bir SHA-1 özetidir. Kodun belirli bir sürümü için kalıcı bir kimlik görevi görür. Commit’ler, geliştirme sürecindeki en küçük değişiklik birimleridir.

Commit özeti çok ayrıntılı bir izleme olanağı sunar. Analistlerin bir süreç olayını doğrudan yapılan kod değişikliğine bağlamasını sağlar. Denetim, uyumluluk veya üretim olaylarının ayrıntılı kök neden analizi için büyük fayda sağlayabilir.

Neden önemli?

Bir süreç adımıyla belirli kod değişikliği arasında en ayrıntılı bağlantıyı kurar; denetim ve hata ayıklama için tam izlenebilirlik sağlar.

Nereden alınır?

Push olaylarının yüklerinde ('head_commit.id') veya bir pull request ya da dala ait Commits API üzerinden bulunur.

Örnekler
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Dağıtım ortamı
DeploymentEnvironment
'Hazırlık' veya 'Üretim' gibi dağıtımın hedef ortamı.
Açıklama

Bu öznitelik, kodun hangi ortama dağıtıldığını belirtir. Geliştirmeden üretim sürümüne kadar tüm yaşam döngüsünü anlamak için farklı ortamlara yapılan dağıtımları izlemek önemlidir.

Dağıtım alt sürecini analiz etmeyi sağlar. Kodun hazırlık ortamından üretim ortamına alınma süresini ölçmek ve farklı ortamlara yapılan dağıtımların başarı oranını izlemek için kullanılabilir. Bir geliştirme öğesinin ne zaman gerçekten tamamlanıp kullanıcılara sunulduğunu belirlemek açısından gereklidir.

Neden önemli?

Üretim öncesi sürümlerle üretim sürümlerini birbirinden ayırır. Gerçek pazara çıkış süresini ölçmek ve dağıtım örüntülerini analiz etmek için önemlidir.

Nereden alınır?

Bu bilgi, genellikle CI/CD hatları veya başka otomasyonlar tarafından tetiklenen GitHub Deployments API’sinden alınır.

Örnekler
geliştirmehazırlıküretim
Dal adı
BranchName
Geliştirme öğesine ait kod değişikliklerinin yapıldığı Git dalının adı.
Açıklama

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 yapılan işi kısaca açıklayan bir ifade gibi yararlı bilgiler içerir.

Dal adlarını analiz etmek, dallanma stratejilerini ve geliştirme kurallarına uyumu anlamaya yardımcı olabilir. Ayrıca belirli kod commit’lerini bir geliştirme öğesine bağlayarak kodlama etkinliğinin bütününü görmenizi sağlar.

Neden önemli?

Belirli geliştirme hattı hakkında bağlam sağlar; dallanma stratejilerinin ve adlandırma kurallarının uygulanmasına ve analiz edilmesine yardımcı olur.

Nereden alınır?

Push olaylarında 'ref' alanında veya pull request API yanıtındaki 'head' ve 'base' nesnelerinde bulunur.

Örnekler
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Devir teslim bekleme süresi
HandoffWaitingTime
Bir geliştirme öğesinin farklı kişilerce gerçekleştirilen etkinlikler arasında beklediği hesaplanmış boş süre.
Açıklama

Bu metrik, bir etkinliğin tamamlanmasıyla sonraki etkinliğin başlaması arasındaki süreyi ölçer; ancak yalnızca sorumlu kişi değiştiğinde. Örneğin 'İnceleme istendi' olayıyla başka bir kullanıcının gerçekleştirdiği 'İncelemede değişiklik istendi' olayı arasındaki süre.

İletişim kopukluklarını ve koordinasyon sorunlarını belirlemek için bu metrik büyük önem taşır. 'Kritik Devir Teslim Verimliliği' Dashboardını ve 'Ortalama Devir Teslim Bekleme Süresi' KPI’ını destekler. Devir teslim noktalarındaki uzun bekleme süreleri genellikle kaynak kısıtlarına veya bildirim süreçlerindeki verimsizliğe işaret eder.

Neden önemli?

Farklı ekipler veya roller arasındaki devir teslimlerde koordinasyon eksikliğinden ya da kaynakların müsait olmamasından kaynaklanan gecikmeleri belirler. Bu gecikmeler çoğu zaman verimsizliğin başlıca nedenlerindendir.

Nereden alınır?

'Assignee' veya 'User' özniteliğinin değiştiği ardışık etkinlikler belirlenir ve bu etkinlikler arasındaki süre ölçülür.

Örnekler
PT1H15MP2DT4HPT25M
Etiketler
Labels
Bir sorunu veya pull request’i sınıflandırmak için uygulanan etiketlerin listesi.
Açıklama

GitHub’daki etiketler, sorunlara ve pull request’lere meta veri eklemenin esnek bir yoludur. Önceliği, iş türünü, bileşenleri, ekipleri veya durumu belirtmek için kullanılabilir. Etiketlerin ham listesi, yapılandırılmamış ancak zengin bir bağlam sunar.

Öncelik ve Tür gibi belirli öznitelikler etiketlerden elde edilse de listenin tamamını saklamak, anlık analizler yapmak ve başka süreç örüntülerini keşfetmek için yararlı olabilir. Etiketlerin herhangi bir bileşimine göre vakaları esnek biçimde filtrelemeyi ve gruplandırmayı sağlar.

Neden önemli?

İş öğelerini sınıflandırmak için esnek ve zengin bir meta veri kaynağı sunar; farklı boyutlarda ayrıntılı analiz yapılmasını sağlar.

Nereden alınır?

GitHub API’sinden alınan sorun ve pull request JSON yüklerinde 'labels' dizisi olarak bulunur. Dizideki her öğe, 'name' alanı bulunan bir nesnedir.

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

Bu, tek bir geliştirme öğesinin ilk olayı (ör. 'Sorun oluşturuldu') ile son olayı (ör. 'Dağıtım başarılı' veya 'Sorun kapatıldı') arasındaki süre farkı olarak hesaplanan vaka düzeyinde bir metriktir.

Geliştirme sürecinin genel verimliliğini ölçen en önemli KPI’lardan biridir. 'Genel Geliştirme Çevrim Süresi' Dashboardını ve 'Ortalama Geliştirme Çevrim Süresi' KPI’ını doğrudan destekler. Süreç iyileştirme çalışmalarında bu metriği düşürmek çoğu zaman temel hedeflerden biridir.

Neden önemli?

Bir geliştirme öğesinin baştan sona pazara çıkış süresini gösterir; sürecin genel hızını ve verimliliğini ölçen önemli bir KPI’dır.

Nereden alınır?

Vaka düzeyinde, ilk etkinliğin zaman damgasından son etkinliğin zaman damgası çıkarılarak hesaplanır.

Örnekler
P5DT6H30MP14DT12HP1DT2H
İnceleme durumu
ReviewState
Pull request üzerindeki kod incelemesinin sonucu; örneğin 'Onaylandı' veya 'Değişiklik istendi'.
Açıklama

Bu öznitelik, inceleyenin verdiği kararı kaydeder. Yaygın durumlar arasında kodun birleştirilmeye hazır olduğunu belirten 'APPROVED' ve yeniden çalışma gerektiğini belirten 'CHANGES_REQUESTED' bulunur. Diğer durumlar 'COMMENTED' veya 'PENDING' olabilir.

Yeniden çalışmayı ve kaliteyi analiz etmek için bu öznitelik büyük önem taşır. 'CHANGES_REQUESTED' olaylarının sık görülmesi, ilk kod kalitesiyle ilgili sorunlara veya gereksinimlerin net olmamasına işaret edebilir. Geliştirme öğesinin ne zaman değişiklik yapılması için geri gönderildiğini belirleyerek 'Yeniden Çalışma ve Gerileme Döngüleri' Dashboardını doğrudan destekler.

Neden önemli?

Kod inceleme sürecindeki yeniden çalışma 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 alınan pull request inceleme nesnesinin 'state' alanında bulunur. Örneğin 'PullRequestReviewEvent' yükünde yer alır.

Örnekler
APPROVEDCHANGES_REQUESTEDCOMMENTED
İnceleyen
Reviewer
Pull request üzerinde kod incelemesi yapması istenen kullanıcı.
Açıklama

İnceleyen, pull request’teki kod değişikliklerini kalite, doğruluk ve standartlara uygunluk açısından denetlemekle görevlendirilen geliştirici veya ekip üyesidir. Bir pull request için birden fazla inceleyen atanabilir.

Bu öznitelik, kod inceleme sürecini analiz etmek için gereklidir. Belirli inceleyenlerle ilgili darboğazları belirlemeye, inceleme iş yükünün dağılımını anlamaya ve inceleyenlerin taleplere yanıt verme süresini ölçmeye yardımcı olur. 'Ortalama Kod İnceleme Çevrim Süresi' KPI’ını hesaplamanın temel bileşenlerinden biridir.

Neden önemli?

Kalite güvence sürecine katılan kişileri göstererek inceleme iş yüklerinin, gecikmelerin ve kod incelemelerinin genel verimliliğinin analiz edilmesini sağlar.

Nereden alınır?

GitHub API’sinden alınan pull request inceleme olayının 'requested_reviewers' dizisinde veya 'user' nesnesinde bulunur.

Örnekler
alex.chenmaria.garciasenior-dev-team
İş öğesi durumu
State
Bir sorunun veya pull requestin 'open', 'closed' ya da 'merged' gibi mevcut durumu.
Açıklama

Bu öznitelik, geliştirme işinin genel durumunu gösterir. Sorunlar için yaygın durumlar 'open' ve 'closed'; pull requestler içinse 'open', 'closed' ve 'merged' değerleridir. Böylece iş öğesinin ilerleme durumu anlık olarak görülebilir.

Analizde durum bilgisi, devam eden işleri tamamlananlardan ayırmak için kullanılır. Devam eden işleri izleyen 'Etkin geliştirme ilerlemesi' gibi Dashboardlar için gereklidir. Ayrıca sürecin bitişini tanımlamakta da kullanılır; örneğin 'merged' veya 'closed' durumu bir vakanın tamamlandığını gösterebilir.

Neden önemli?

Bir iş öğesinin devam edip etmediğini veya tamamlanıp tamamlanmadığını açıkça gösterir. Bu bilgi, yaşam döngüsü analizi ve devam eden işlerin izlenmesi için temel niteliktedir.

Nereden alınır?

GitHub API’sinden alınan sorun ve pull request JSON verilerindeki 'state' alanında doğrudan bulunur.

Örnekler
openclosedmerged
Kaynak sistem
SourceSystem
Geliştirme süreci verilerinin alındığı sistem.
Açıklama

Bu öznitelik, olay verilerinin kaynağını belirtir. Bu süreçte değeri her zaman 'GitHub' olur. Geliştirme etkinliklerinin birden fazla sisteme yayıldığı daha karmaşık ortamlarda (örneğin planlama için Jira, kod için GitHub, dağıtım için Jenkins), her olayın kaynağını ayırt etmek için bu alan kullanılır.

Analizde, doğrulama ve sorun giderme amacıyla verilerin kaynağına kadar izlenmesine yardımcı olur. Ayrıca farklı platformları kapsayan süreçleri analiz etmenizi ve her etkinliğin bağlamını netleştirmenizi sağlar.

Neden önemli?

Verilerin kaynağını belirtir. Bu bilgi, verileri doğrulamak ve birden fazla entegre sisteme yayılan süreçleri analiz etmek için gereklidir.

Nereden alınır?

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

Örnekler
GitHubGitHub Enterprise
Pull request numarası
PullRequestNumber
Geliştirme öğesiyle ilişkili pull request’in benzersiz tanımlayıcısı.
Açıklama

Pull request (PR), bir dizi kod değişikliğini belirli bir dala birleştirme önerisidir. Pull request numarası, kod gönderme ve inceleme gibi geliştirme etkinliklerini ana geliştirme öğesine veya soruna bağlar.

Bu kimlik, genel geliştirme yaşam döngüsü içindeki kod entegrasyonu ve inceleme alt sürecini izlemek için önemlidir. İnceleme süreleri, inceleme sırasında belirlenen yeniden çalışma döngüleri ve birleştirme oranları dâhil olmak üzere kod inceleme sürecinin ayrıntılı analizini sağlar. 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üresine etkisinin ayrıntılı analizini sağlar.

Nereden alınır?

Birçok GitHub API yanıtında 'pull_request' nesnesinin içindeki 'number' alanında veya Pull Requests API’den alınan ana tanımlayıcı olarak bulunur.

Örnekler
12345678910
Verilerin son güncellenme zamanı
LastDataUpdate
Bu kaydın verilerinin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası.
Açıklama

Bu öznitelik, verilerin en son çıkarıldığı veya güncellendiği tarih ve saati kaydeder. Analiz edilen verilerin ne kadar güncel olduğunu gösteren üst verileri sağlar. İş olayının gerçekleştiği zamanı kaydeden olay zaman damgasından farklıdır.

Analizde bu alan, süreç görünümünün ne kadar güncel olduğunu anlamak için önemlidir. Gerçek zamanlı verileri mi yoksa belirli bir andaki anlık görüntüyü mü incelediğinizi gösterir. Bu bilgi, operasyonel Dashboardlar ve izleme için önem taşır.

Neden önemli?

Verilerin güncelliğini gösterir. Analizlerin ve Dashboardların güncel bilgilere dayanmasını sağlamak için bu bilgi önemlidir.

Nereden alınır?

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

Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Yazar
Author
Sorunu, pull request’i veya commit’i oluşturan kullanıcı.
Açıklama

Yazar, geliştirme sürecindeki belirli bir artefaktı oluşturan kişidir. Örneğin bir sorunun yazarı, hatayı bildiren veya özellik talebinde bulunan kişidir. Pull request’in yazarı ise kodu yazan geliştiricidir.

Analizde yazar bilgisi, işin hangi kaynaklardan geldiğini anlamak için kullanılabilir. Örneğin hata bildirimlerinin yazarlarını incelemek, belirli ekiplerle veya özelliklerle ilgili örüntüleri ortaya çıkarabilir. Devir teslim örüntülerini analiz etmek için atanan kişi bilgisiyle birlikte de kullanılabilir.

Neden önemli?

Bir iş öğesini veya kod değişikliğini kimin oluşturduğunu gösterir. Yeniden çalışma kaynaklarını, hata bildirimlerini veya özellik taleplerini analiz ederken yararlı olabilir.

Nereden alınır?

Sorunlar, pull request’ler ve commit’lere ait API yanıtlarının ana nesnesindeki 'user' nesnesinde bulunur. Alanın adı genellikle 'user.login’dir.

Örnekler
sara.jonesmike.leeautomation-bot
Yeniden çalışma mı
IsRework
Bir etkinliğin sürecin önceki bir aşamasına geri dönüşü gösterip göstermediğini belirten boole değeri.
Açıklama

Bir geliştirme öğesi süreçte geriye gittiğinde bu işaret true olarak ayarlanır. Örneğin pull request incelemesinde 'Değişiklik istendi' kararı alınması veya kapatılan bir sorunun yeniden açılması bu duruma örnektir. Değer, etkinlik sırası analiz edilerek elde edilir.

Bu öznitelik, kaybı ve verimsizliği ölçmek için gereklidir. 'Yeniden Çalışma ve Gerileme Döngüleri' Dashboardını ve 'Yeniden Çalışma Oranı' KPI’ını doğrudan destekler. Analistler 'IsRework = true' filtresini kullanarak yeniden çalışma vakalarını ayırabilir ve nedenlerini inceleyebilir.

Neden önemli?

Yeniden çalışma sayılan etkinlikleri açıkça işaretleyerek süreç verimsizliklerinin ölçülmesini, görselleştirilmesini ve nedenlerinin analiz edilmesini kolaylaştırır.

Nereden alınır?

Türetilmiş bir özniteliktir. Önce standart bir süreç akışı tanımlanır, ardından daha önceki bir mantıksal aşamaya dönen etkinlikler işaretlenir.

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

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

Süreçleri doğru biçimde keşfetmek ve darboğazları belirlemek için Event Logda kaydetmeniz gereken temel adımlar ve kilometre taşları şunlardır.
6 Önerilen 7 İsteğe bağlı
Aktivite Açıklama
CI kontrolleri başarılı
Pull request’teki kod üzerinde çalışan derleme, birim testleri veya statik analiz gibi otomatik kontrollerin başarıyla tamamlandığını gösterir. Bu olay, GitHub Actions gibi sistemlerin bildirdiği kontrol durumlarından çıkarılır.
Neden önemli?

Bu otomatik kalite kontrolü, kodun kararlılığını sağlamak için önemlidir. Başarısız kontroller veya uzun çalışma süreleri, teslimat sürecinde önemli darboğazlar oluşturabilir.

Nereden alınır?

GitHub Checks API veya Statuses API verilerinden çıkarılır. Bir kontrol çalıştırması ya da durum güncellemesi, 'success' veya 'completed' bildirimiyle birlikte 'success' sonucunu verir.

Kaydedin

İlgili kontrol paketlerinde 'success' sonucu olup olmadığını Checks API üzerinden izleyin.

Olay türü inferred
Pull request açıldı
İlk kod bloğunun incelemeye ve birleştirmeye hazır olduğunu gösterir. Geliştirici, özellik dalındaki değişiklikleri ana dala önermek için bir pull request (PR) oluşturur. Bu, GitHub’da açıkça kaydedilen bir olaydır.
Neden önemli?

Bu önemli kilometre taşı, ilk geliştirme aşamasının sonunu ve inceleme ile entegrasyon sürecinin başlangıcını gösterir. Geliştirme ve inceleme çevrim sürelerini ayrı ayrı analiz etmek için temel bir ölçüttür.

Nereden alınır?

GitHub Pull Request API olay akışından veya webhooklardan alınır. Olay eylemi 'opened' olur.

Kaydedin

Webhook veya API yoklaması aracılığıyla bir pull request için 'opened' eylemini dinleyin.

Olay türü explicit
Pull request birleştirildi
Pull request’te onaylanan kod değişiklikleri, main veya develop gibi hedef dala resmî olarak eklenir. Yeni kodu içeren bu işlem, pull request üzerinde açıkça kaydedilen son adımdır.
Neden önemli?

Bu önemli kilometre taşı, geliştirme ve inceleme aşamalarının tamamlandığını gösterir. Birçok ekipte otomatik dağıtımdan önceki son adımdır.

Nereden alınır?

GitHub Pull Request API olay akışından veya webhooklardan alınır. Olay eylemi 'closed' olur ve pull request verisindeki 'merged' özniteliği true değerini alır.

Kaydedin

Bir pull request için 'closed' eylemini dinleyin ve 'merged' işaretinin true olup olmadığını kontrol edin.

Olay türü explicit
Pull request onaylandı
İncelemeci, pull request’teki değişiklikleri resmî olarak onaylamıştır. Bu, değişikliklerin kalite ve işlev standartlarını karşıladığını gösterir. İncelemeci, incelemesini 'approve' durumuyla gönderdiğinde kaydedilir.
Neden önemli?

Bu, birleştirme öncesindeki önemli bir kalite kontrol aşaması ve kilometre taşıdır. PR oluşturulduktan sonra bu duruma ulaşma süresi, inceleme sürecinin verimliliğini ölçen temel bir KPI’dır.

Nereden alınır?

İnceleme 'APPROVED' durumuyla gönderildiğinde GitHub Pull Request API veya webhooklar üzerinden kaydedilir.

Kaydedin

Pull request inceleme gönderim olaylarını 'APPROVED' durumuna göre filtreleyin.

Olay türü explicit
Sorun kapatıldı
Geliştirme işi tamamlanmış sayılır ve ilgili sorun resmî olarak kapatılır. Bağlantılı bir pull request birleştirildiğinde bu işlem otomatik olarak gerçekleşebilir veya bir ekip üyesi tarafından elle yapılabilir.
Neden önemli?

Bu etkinlik, geliştirme işi için sürecin kesin bitiş noktasıdır. Uçtan uca çevrim sürelerini hesaplamak için gereklidir.

Nereden alınır?

Bu, GitHub Issues API olay akışından alınan açık bir olaydır. Olay türü 'closed' olur.

Kaydedin

Webhook veya API yoklaması aracılığıyla bir sorundaki 'closed' olayını dinleyin.

Olay türü explicit
Sorun oluşturuldu
Bir geliştirme işinin yaşam döngüsünü başlatır; görev, hata veya özellik talebinin resmî olarak oluşturulduğunu gösterir. Kullanıcı bir GitHub deposunda yeni bir sorun oluşturduğunda bu olay açıkça kaydedilir.
Neden önemli?

Bu, sürecin başlangıç etkinliğidir. Toplam geliştirme çevrim süresini ölçmek ve işin ilk kaynaklarını anlamak için gereklidir.

Nereden alınır?

Bu, GitHub Issues API olay akışından alınan açık bir olaydır. Belirli bir sorun numarası için olay türü genellikle 'opened' olur.

Kaydedin

Webhook veya API yoklaması aracılığıyla bir sorundaki 'opened' olayını dinleyin.

Olay türü explicit
CI kontrolleri başarısız
Pull request’teki kod üzerinde çalışan derleme hatası veya başarısız birim testi gibi otomatik bir kontrolün başarısız olduğunu gösterir. Bu durum, GitHub Actions gibi bir sistemin bildirdiği başarısızlık durumundan çıkarılır.
Neden önemli?

Bu etkinlik, geliştiricinin müdahalesini gerektiren teknik kalite sorunlarını ve bunların yol açtığı yeniden çalışma döngüsünü ortaya çıkarır. Başarısızlık sıklığını analiz ederek yerel testleri veya kod kalitesini iyileştirebilirsiniz.

Nereden alınır?

GitHub Checks API veya Statuses API verilerinden çıkarılır. Bir kontrol çalıştırması ya da durum güncellemesi, 'failure' veya 'completed' bildirimiyle birlikte 'failure' sonucunu verir.

Kaydedin

İlgili kontrol paketlerinde 'failure' sonucu olup olmadığını Checks API üzerinden izleyin.

Olay türü inferred
Dağıtım başarılı
Kod değişiklikleri, hazırlık veya üretim gibi belirli bir ortama başarıyla dağıtılmıştır. Bu olay genellikle GitHub Deployments API üzerinden alınır ve çoğu zaman birleştirme sonrasında GitHub Action tarafından başlatılır.
Neden önemli?

Kodun depodan canlı ortama geçişini gösterir. Fikirden üretime kadar geçen toplam süreyi ölçmek için bu olayı izlemek önemlidir.

Nereden alınır?

Deployments API üzerinden alınır. Harici bir hizmet veya GitHub Action dağıtımı oluşturur ve ardından durumunu 'success' olarak günceller.

Kaydedin

Webhooklar üzerinden dağıtım durumu olaylarını izleyin ve 'success' durumunu kontrol edin.

Olay türü inferred
Dal oluşturuldu
Bir geliştiricinin ana kod tabanından yeni bir dal oluşturmasıyla sorun için etkin geliştirme çalışmasının başladığını gösterir. Depoya yeni bir dal gönderildiğinde bu olay açıkça kaydedilir. Dal adında genellikle sorun numarası bulunur.
Neden önemli?

Planlamadan etkin kodlamaya geçişi gösterir. Sorunun oluşturulmasıyla bu olay arasındaki süreyi ölçerek geliştiricinin işe başlama süresini ve başlangıç aşamasındaki birikme gecikmelerini analiz edebilirsiniz.

Nereden alınır?

GitHub Git API üzerinden veya 'branch' türündeki 'create' olaylarını dinleyen webhooklarla kaydedilir. Dal adını, 'feature/issue-123' gibi adlandırma kurallarıyla bir sorunla eşleştirmek çoğu zaman gerekir.

Kaydedin

Yeni dallara ait 'create' webhook olaylarını ayrıştırın ve dalları ilgili sorunla eşleştirin.

Olay türü explicit
İnceleme talep edildi
Pull request yazarı, belirli ekip üyelerinden veya ekiplerden kodunu incelemelerini resmî olarak ister. GitHub arayüzünde veya API’de yapılan bu işlem, talep edilen incelemecilere bildirim gönderir.
Neden önemli?

Bu etkinlik, kod inceleme sürecine devir teslimin resmî başlangıcını gösterir. Bu etkinlikle incelemenin gönderilmesi arasındaki süre, incelemecilerin yanıt hızını ve olası darboğazları ölçmeye yardımcı olur.

Nereden alınır?

GitHub Pull Request API olay akışından veya webhooklardan alınır. Olay eylemi 'review_requested' olur.

Kaydedin

Bir pull request için 'review_requested' eylemini dinleyin.

Olay türü explicit
İncelemede değişiklik istendi
İncelemeci kod incelemesini tamamlamış ve pull request onaylanmadan önce değişiklik yapılması gerektiğine karar vermiştir. İncelemeci, incelemesini 'request_changes' durumuyla resmî olarak gönderir.
Neden önemli?

Bu olay, yeniden çalışma döngüsünü açıkça gösterir. Sıklığını analiz ederek kalite sorunlarını, belirsiz gereklilikleri veya geliştirici eğitimi gereken alanları belirleyebilirsiniz.

Nereden alınır?

İnceleme 'CHANGES_REQUESTED' durumuyla gönderildiğinde GitHub Pull Request API veya webhooklar üzerinden kaydedilir.

Kaydedin

Pull request inceleme gönderim olaylarını 'CHANGES_REQUESTED' durumuna göre filtreleyin.

Olay türü explicit
PR’ye kod gönderildi
İlk PR kapsamında veya inceleme geri bildirimlerine yanıt olarak incelemeye sunulan kodun güncellendiğini gösterir. Açık bir pull request ile ilişkili dala her yeni commit gönderildiğinde bu olay kaydedilir.
Neden önemli?

Bu olayları izlemek, yeniden çalışma döngülerini belirlemek için önemlidir. İnceleme sonrasında birden fazla kod gönderimi yapılması, değişiklik gerektiğini gösterir ve toplam çevrim süresini etkiler.

Nereden alınır?

Pull request zaman çizelgesinde açıkça kaydedilen bu olay, genellikle commit eklenmesi olarak gösterilir. 'push' webhookundan veya PR ile ilişkili commitler izlenerek alınabilir.

Kaydedin

Açık bir pull request ile ilişkili dala gönderilen 'push' olaylarını izleyin.

Olay türü explicit
Sorun yeniden açıldı
Daha önce kapatılmış bir sorun, genellikle düzeltme yetersiz kaldığı veya gerileme tespit edildiği için yeniden etkinleştirilir. Bu açık olay, geliştirme işinin yaşam döngüsünü yeniden başlatır.
Neden önemli?

Bu olay, önemli bir yeniden çalışma döngüsüne işaret eder; üretimde fark edilmeyen bir hata veya eksik bir düzeltme söz konusu olabilir. Sıklığını izlemek, genel yazılım kalitesini ölçmenin önemli bir yoludur.

Nereden alınır?

Bu, GitHub Issues API olay akışından alınan açık bir olaydır. Olay türü 'reopened' olur.

Kaydedin

Webhook veya API yoklaması aracılığıyla bir sorundaki 'reopened' olayını dinleyin.

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

Veri çıkarma rehberleri

GitHub verilerinizi nasıl alabilirsiniz?

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

Verilerinizi hazırlamak ve yazılım geliştirme yaşam döngünüzü iyileştirmeye başlamak için bu Templateten yararlanın. Verimsizlikleri keşfedin ve sürümlerinizi bugün daha hızlı, daha sorunsuz yayımlayın.

SDLC’nizi iyileştirin: Verimsizlikleri hemen belirleyin

Çevrim süresini %30 azaltın ve GitHub geliştirme sürecinizi daha verimli hâle getirin.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez, kurulum birkaç dakika sürer.