Yazılım geliştirme yaşam döngünüz için veri şablonu
Yazılım geliştirme yaşam döngünüz için veri şablonu
- Toplanması önerilen öznitelikler
- İzlenecek temel faaliyetler
- Veri çıkarma rehberi
Yazılım Geliştirme Yaşam Döngüsü Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç zamanı
EventTimestamp
|
Belirli bir geliştirme etkinliğinin veya olayının gerçekleştiği kesin tarih ve saattir. | ||
|
Açıklama
Bu zaman damgası bir etkinliğin başlangıcını gösterir. Her geliştirme öğesinin süreç akışını yeniden oluşturmak için olayları kronolojik sıraya koymak açısından önemlidir. Bu zaman damgaları arasındaki sıra ve zaman farkı, süreç performansını analiz etmek için kullanılır. Analizde bu öznitelik, çevrim süreleri, işlem süreleri ve bekleme süreleri dahil olmak üzere 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 veriyi 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?
Genellikle GitHub API'lerinden ve çeşitli nesnelere, örneğin issue'lara, pull request'lere ve commit'lere ait webhook'ların JSON yüklerinde 'created_at' veya 'updated_at' alanları 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ü içinde gerçekleşen belirli bir olayın veya görevin adıdır. | ||
|
Açıklama
Etkinlik Adı, geliştirme sürecindeki tek bir adımı açıklar. Örnek olarak 'Issue oluşturuldu', 'PR'ye kod gönderildi', 'Pull request onaylandı' veya 'Dağıtım başarılı oldu' verilebilir. Bu olaylar, bir geliştirme öğesi için uçtan uca süreci oluşturan adımların sırasını meydana getirir. Bu öznitelik, süreç haritasını oluşturmak için kullanıldığı için Process Mining açısından temel öneme sahiptir. Etkinliklerin sırasını, sıklığını ve süresini analiz etmek gerçek süreç akışını ortaya çıkarır, yaygın yolları belirler, sapmaları görünür kılar ve darboğazları saptar.
Neden önemli?
Bu öznitelik, geliştirme yaşam döngüsündeki olayların sırasını görselleştirmenizi ve analiz etmenizi sağlayan süreç haritasının temelini oluşturur.
Nereden alınır?
Webhook olay yüklerindeki 'action' alanından, örneğin bir issue için 'opened' veya 'closed' değerlerinden ya da olay türünün kendisinden, örneğin 'PushEvent' veya 'PullRequestReviewEvent', türetilir.
Örnekler
Issue oluşturulduPull request açıldıPR'ye kod gönderildiİnceleme istendiPull request birleştirildi
|
|||
|
Geliştirme öğesi
DevelopmentItemId
|
Özellik, hata düzeltmesi veya görev gibi tek bir geliştirme çalışması biriminin benzersiz tanımlayıcısıdır. Bu, temel vaka tanımlayıcısı olarak kullanılır. | ||
|
Açıklama
Geliştirme Öğesi Kimliği, bir iş öğesini oluşturulmasından son dağıtıma kadar izler. Branch oluşturma, commit'ler, pull request'ler, incelemeler ve dağıtımlar gibi ilişkili tüm etkinlikleri tek ve tutarlı bir süreç örneğinde birleştirir. Analizde bu kimlik, bir geliştirme görevinin uçtan uca çevrim süresini hesaplamak için kullanılır. Bir Özelliğin veya hata düzeltmesinin tüm yolculuğunu yeniden oluşturmanızı sağlar; böylece tek tek iş öğeleri için darboğazları, yeniden çalışma döngülerini ve süreç farklılıklarını ayrıntılı biçimde analiz edebilirsiniz.
Neden önemli?
Process Mining için temel anahtardır. İlgili tüm geliştirme olaylarını tek bir vakada birleştirerek uçtan uca yazılım geliştirme yaşam döngüsünü doğru biçimde görselleştirmenizi ve analiz etmenizi sağlar.
Nereden alınır?
Bu genellikle GitHub'daki Issue Numarası veya Pull Request Numarasıdır. Issue ya da pull request ile ilgili webhook olaylarının veya API yanıtlarının yükündeki 'number' alanından çıkarılabilir.
Örnekler
101PR-2345TASK-812
|
|||
|
Atanan kullanıcı
Assignee
|
Geliştirme öğesini veya pull request incelemesi gibi belirli bir görevi yürütmekle görevlendirilen kullanıcı ya da geliştiricidir. | ||
|
Açıklama
Bu öznitelik, belirli bir aşamadaki işten sorumlu kişiyi tanımlar. Bu kişi bir issue atanan kişi, bir pull request yazarı veya kod incelemesi için talep edilen inceleyici olabilir. Atanan kişiyi izlemek, kaynak tahsisini ve iş yükünü anlamanın temel yollarından biridir. 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. Dashboardlar, bireysel veya ekip performansını değerlendirmek ve işin dengeli dağıtıldığından emin olmak için atanan kişiye göre filtrelenebilir.
Neden önemli?
Geliştirici iş yükünü, ekip performansını ve farklı ekip üyeleri arasındaki devir teslimlerin verimliliğini analiz etmek için önemlidir.
Nereden alınır?
GitHub API'sinden alınan issue, pull request ve inceleme olaylarının JSON yüklerindeki '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 saattir. | ||
|
Açıklama
Bitiş zaman damgası bir etkinliğin tamamlandığını gösterir. GitHub'daki birçok olay anlık gerçekleşirken, 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, bir etkinliğin işlem süresini verir. Bu öznitelik, farklı görevlerde, örneğin kod incelemelerinde veya otomatik kontrollerde, harcanan aktif çabayı anlamak için önemli olan 'ProcessingTime' metriğini hesaplamak üzere kullanılır. İşlem sürelerini analiz etmek, gereğinden fazla zaman alan verimsiz etkinlikleri belirlemeye yardımcı olur.
Neden önemli?
Etkinlikler için kesin işlem sürelerini hesaplamanızı sağlar ve aktif çalışma süresi ile boşta bekleme süresini ayırt etmenize yardımcı olur.
Nereden alınır?
Kontrol çalıştırması nesnelerinde 'completed_at' olarak bulunabilir veya mantıksal olarak sonucu belirleyen sonraki 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ıdır. | ||
|
Açıklama
Repository, belirli bir uygulama veya bileşene ait tüm kodu, issue kayıtlarını ve pull requestleri içeren bir proje veya ürün tanımlayıcısıdır. Farklı ürünler veya ekipler arasındaki geliştirme süreçlerini bölümlere ayırıp karşılaştırmanızı sağlar. Analizde bu öznitelik, süreç performansını farklı projelere göre filtrelemenize ve karşılaştırmanıza imkan verir. 'Hangi projenin çevrim süresi en uzun?' veya 'Project A içindeki hata düzeltme süreci Project B ile karşılaştırıldığında nasıl?' gibi soruları yanıtlamaya yardımcı olur. 'Throughput by Project and Type' Dashboardu için gereklidir.
Neden önemli?
Geliştirme süreçlerini farklı projeler, ürünler veya ekipler arasında bölümlere ayırmanızı ve karşılaştırmanızı sağlar. Böylece daha hedefli analiz yapabilirsiniz.
Nereden alınır?
Neredeyse tüm GitHub webhook ve API yüklerindeki 'repository' nesnesinde bulunur. Belirli alan genellikle 'repository.full_name' veya 'repository.name' olur.
Örnekler
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Geliştirme öğesi türü
DevelopmentItemType
|
Özellik, hata, görev veya epic gibi geliştirme iş öğesinin sınıflandırmasıdır. | ||
|
Açıklama
Bu öznitelik, gerçekleştirilen işin niteliğini sınıflandırır. Bu bilgi genellikle GitHub içindeki etiketler veya belirli issue Templateleri aracılığıyla yönetilir. İş türünü anlamak, uygun performans beklentileri belirlemek için önemlidir. Bir hata düzeltmesinin beklenen çevrim süresi, yeni bir özellikten çok daha kısa olabilir. Bu öznitelik, farklı iş türleri arasında karşılaştırmalı analiz yapmanızı sağlar. Hata düzeltmelerinin yeni özelliklerden daha hızlı işlenip işlenmediğini analiz etmenize veya teknik borç ile yeni geliştirme arasındaki kaynak tahsisini anlamanıza yardımcı olur. 'Throughput by Project and Type' Dashboardunun temel boyutlarından biridir.
Neden önemli?
İş öğelerini kategorilere ayırarak performans karşılaştırmalarına ve farklı iş türlerinin, örneğin hatalar ile özelliklerin, süreçte nasıl ilerlediğinin analizine olanak tanır.
Nereden alınır?
Genellikle sorunlara veya pull request'lere uygulanan GitHub etiketlerinden elde edilir. Tutarlı bir etiketleme kuralı gerektirir, örneğin 'type:bug', 'type:feature'.
Örnekler
HataÖzellikGörevTeknik Borç
|
|||
|
Öncelik
Priority
|
Bir geliştirme öğesine atanan 'High', 'Medium' veya 'Low' gibi öncelik düzeyi. | ||
|
Açıklama
Öncelik, bir iş öğesinin aciliyetini veya iş açısından önemini gösterir. GitHub'da öncelik yerleşik bir alan değildir ve genellikle etiketlerle yönetilir, örneğin 'P1-High', 'P2-Medium'. Bu bilgiyi güvenilir biçimde çıkarmak için tutarlı bir etiketleme düzeni gerekir. Bu öznitelik, 'Priority-Based Flow Analysis' için gereklidir. Analistlerin yüksek öncelikli öğelerin düşük öncelikli öğelere göre 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 olanak tanır. Önceliklendirme sürecinin ne kadar etkili olduğunu değerlendirmeye yardımcı olur.
Neden önemli?
Yüksek öncelikli öğelerin düşük öncelikli öğelere göre daha hızlı işlenip işlenmediğini analiz etmeye ve önceliklendirme stratejisinin etkinliğini doğrulamaya olanak tanır.
Nereden alınır?
Sorunlara veya pull request'lere uygulanan GitHub etiketlerinden elde edilir. Öncelik etiketleri için standartlaştırılmış bir kural gerektirir.
Örnekler
YüksekOrtaDüşükKritik
|
|||
|
CI kontrol durumu
CiCheckStatus
|
'passed' veya 'failed' gibi otomatik bir Continuous Integration (CI) kontrolünün durumu. | ||
|
Açıklama
Bu öznitelik, pull request içindeki kod değişiklikleri üzerinde çalışan otomatik build, test ve taramaların sonuçlarını gösterir. CI kontrolleri, modern 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 Checks Passed' ve 'CI Checks Failed' etkinliklerini destekler, ayrıca başarısız buildlerin neden olduğu gecikmeleri analiz etmeye 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 aracılığıyla check run ya da status nesnelerinin 'state' veya 'conclusion' alanından alınır.
Örnekler
başarılıbaşarısızbeklemedehata
|
|||
|
Commit hash'i
CommitHash
|
Belirli bir kod commit'inin benzersiz tanımlayıcısı (SHA). | ||
|
Açıklama
Commit hash'i, Git'teki bir commit'i benzersiz biçimde tanımlayan 40 karakterlik bir SHA-1 hash'idir. Kodun belirli bir sürümü için kalıcı kimlik görevi görür. Commit'ler, geliştirme sürecindeki en küçük değişim birimleridir. Commit hash'i ayrıntı düzeyi yüksek bir bilgi olsa da en kapsamlı izlenebilirliği sağlar. Bir süreç olayını doğrudan yapılan kesin kod değişikliğine bağlamanıza olanak tanır. Denetim, uyumluluk veya production olaylarının ayrıntılı kök neden analizi için çok değerlidir.
Neden önemli?
Bir süreç adımı ile kesin kod değişikliği arasındaki en ayrıntılı bağlantıyı sağlayarak denetimler ve hata ayıklama için tam izlenebilirlik sunar.
Nereden alınır?
Push olaylarının yüklerinde ('head_commit.id') veya bir pull request ya da dal için Commits API aracılığıyla bulunur.
Örnekler
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Dağıtım ortamı
DeploymentEnvironment
|
'Staging' veya 'Production' gibi dağıtımın hedef ortamı. | ||
|
Açıklama
Bu öznitelik, kodun nereye dağıtıldığını belirtir. Farklı ortamlara yapılan dağıtımları izlemek, geliştirmeden üretim sürümüne kadar tüm yaşam döngüsünü anlamak için önemlidir. Bu öznitelik, dağıtım alt sürecinin analiz edilmesini sağlar. Kodun staging ortamından production ortamına geçirilmesi için gereken süreyi ölçmek ve farklı ortamlara yapılan dağıtımların başarı oranını izlemek için kullanılabilir. Bir geliştirme öğesinin gerçekten 'done' olduğunu ve kullanıcılara teslim edildiğini belirlemek için gereklidir.
Neden önemli?
Üretim öncesi ve üretim sürümlerini birbirinden ayırarak gerçek 'time-to-market' süresinin ölçülmesini ve dağıtım kalıplarının analiz edilmesini sağlar.
Nereden alınır?
Bu bilgi, genellikle CI/CD hatları veya diğer 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 çalışmanın kısa açıklaması 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 faaliyetinin 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ı için '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 bekleme süresi
HandoffWaitingTime
|
Bir geliştirme öğesinin farklı kişiler tarafından gerçekleştirilen faaliyetler arasında beklerken geçirdiği hesaplanmış boşta kalma süresi. | ||
|
Açıklama
Bu metrik, yalnızca sorumlu kişi değiştiğinde bir etkinliğin tamamlanması ile sonraki etkinliğin başlaması arasındaki süreyi ölçer. Örneğin 'Review Requested' olayı ile farklı bir kullanıcı tarafından gerçekleştirilen 'Changes Requested in Review' olayı arasındaki süreyi gösterir. Bu metrik, iletişim boşluklarını ve koordinasyon sorunlarını belirlemek için önemlidir. 'Critical Handoff Efficiency' Dashboardunu ve 'Average Handoff Waiting Time' KPI’ını destekler. Devir teslim noktalarındaki uzun bekleme süreleri genellikle kaynak kısıtlarına veya verimsiz bildirim süreçlerine işaret eder.
Neden önemli?
Farklı ekipler veya roller arasındaki devirlerde yetersiz koordinasyonun ya da kaynak bulunamamasının neden olduğu gecikmeleri belirler. Bu gecikmeler, çoğu zaman verimsizliğin başlıca kaynaklarıdır.
Nereden alınır?
'Assignee' veya 'User' özniteliğinin değiştiği ardışık faaliyetleri belirleyerek ve aralarındaki zaman farkını ölçerek hesaplanır.
Örnekler
1 saat 15 dakika2 gün 4 saat25 dakika
|
|||
|
Etiketler
Labels
|
Bir sorunu veya pull request'i kategorilere ayı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ılabilirler. Etiketlerin ham listesi, yapılandırılmamış ve zengin bir bağlam sağlar. Priority ve Type gibi belirli öznitelikler etiketlerden türetilse de tam listenin korunması, geçici analizler ve diğer süreç kalıplarının keşfi için yararlı olabilir. Herhangi bir etiket bileşimine göre vakaları esnek biçimde filtrelemenize ve segmentlere ayırmanıza olanak tanır.
Neden önemli?
İş öğelerini kategorilere ayırmak için esnek ve zengin bir meta veri kaynağı sunarak ayrıntılı ve farklı boyutlarda 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ına sahip bir nesnedir.
Örnekler
hata, arayüz, yüksek önceliközellik, backend, belge gerekliteknik borç, yeniden düzenleme
|
|||
|
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 öğesi için ilk olay, örneğin 'Issue Created', ile son olay, örneğin 'Deployment Succeeded' veya 'Issue Closed', arasındaki zaman farkı olarak hesaplanan vaka düzeyinde bir metriktir. Bu metrik, geliştirme sürecinin genel verimliliğini ölçen en önemli KPI’lardan biridir. 'Overall Development Cycle Time' Dashboardunu ve 'Average Development Cycle Time' KPI’ını doğrudan destekler. Bu metriği azaltmak, süreç iyileştirme çalışmalarının başlıca hedeflerinden biridir.
Neden önemli?
Bir geliştirme öğesinin uçtan uca 'time-to-market' süresini temsil eder. Bu nedenle genel süreç hızını ve verimliliğini ölçmek için önemli bir KPI'dır.
Nereden alınır?
Vaka düzeyinde, ilk faaliyetin zaman damgasından son faaliyetin zaman damgası çıkarılarak hesaplanır.
Örnekler
5 gün 6 saat 30 dakika14 gün 12 saat1 gün 2 saat
|
|||
|
İnceleme durumu
ReviewState
|
Bir pull request üzerindeki kod incelemesinin 'Approved' veya 'Changes Requested' gibi sonucu. | ||
|
Açıklama
Bu öznitelik, bir inceleyicinin verdiği kararı kaydeder. Yaygın durumlar arasında kodun birleştirilmeye hazır olduğunu gösteren 'APPROVED' ve yeniden çalışma gerektiğini gösteren 'CHANGES_REQUESTED' bulunur. Diğer durumlar 'COMMENTED' veya 'PENDING' olabilir. Bu öznitelik, yeniden çalışmayı ve kaliteyi analiz etmek için önemlidir. 'CHANGES_REQUESTED' olaylarının sık görülmesi, ilk kod kalitesiyle veya gereksinimlerin net olmamasıyla ilgili sorunlara işaret edebilir. Geliştirme öğesinin değişiklik yapılması için geri gönderildiği anı belirleyerek 'Rework and Regression Loops' Dashboardunu 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 alınan pull request review nesnesindeki 'state' alanında bulunur. Örneğin 'PullRequestReviewEvent' yükünde yer alır.
Örnekler
ONAYLANDIDEĞİŞİKLİK TALEP EDİLDİYORUM YAPILDI
|
|||
|
İnceleyen
Reviewer
|
Pull request üzerinde kod incelemesi yapması istenen kullanıcı. | ||
|
Açıklama
İnceleyen, bir pull request'teki kod değişikliklerini kalite, doğruluk ve standartlara uygunluk açısından denetlemek üzere görevlendirilen geliştirici veya ekip üyesidir. Bir pull request'in birden fazla inceleyeni olabilir. Bu öznitelik, kod inceleme sürecini analiz etmek için gereklidir. Belirli inceleyenlerle ilişkili 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. 'Average Code Review Cycle Time' KPI'sının hesaplanmasında temel bir bileşendir.
Neden önemli?
Kalite güvence sürecine katılan kişileri belirleyerek 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ında 'requested_reviewers' dizisinde veya 'user' nesnesinde bulunur.
Örnekler
alex.chenmaria.garciasenior-dev-team
|
|||
|
İş öğesi durumu
State
|
Bir sorunun veya pull request'in 'open', 'closed' ya da 'merged' gibi mevcut durumu. | ||
|
Açıklama
Bu öznitelik, bir geliştirme öğesinin üst düzey durumunu gösterir. Issue kayıtları için tipik durumlar 'open' ve 'closed' şeklindedir. Pull requestler için durumlar 'open', 'closed' ve 'merged' olabilir. Bu bilgi, öğenin ilerleme durumunun anlık görünümünü sunar. Analizde durum, etkin ve tamamlanmış işleri belirlemek için kullanılır. Devam eden işleri izleyen 'Active Development Progress' gibi Dashboardlar için gereklidir. Ayrıca sürecin sonunu tanımlamak için de 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 oluşturur.
Nereden alınır?
GitHub API'sinden alınan sorun ve pull request JSON yüklerinde 'state' alanında doğrudan bulunur.
Örnekler
açıkkapalıbirleştirildi
|
|||
|
Kaynak sistem
SourceSystem
|
Geliştirme süreci verilerinin çıkarıldığı sistemdir. | ||
|
Açıklama
Bu öznitelik, olay verilerinin kaynağını belirler. Bu süreçte değer sürekli olarak 'GitHub' olur. Geliştirme etkinliklerinin birden fazla sisteme yayıldığı daha karmaşık ortamlarda, örneğin planlama için Jira, kod için GitHub ve dağıtım için Jenkins kullanıldığında, bu alan her olayın kaynağını ayırt etmek için kullanılır. Analizde verileri doğrulama ve sorun giderme amacıyla kaynağına kadar izlemeye yardımcı olur. Ayrıca farklı platformları kapsayan süreçleri analiz etmenizi ve her etkinlik için net bir bağlam oluşturmanızı sağlar.
Neden önemli?
Verilerin kaynağını belirler. Veri doğrulaması ve birden fazla entegre sisteme yayılabilen süreçlerin analizi için gereklidir.
Nereden alınır?
Bu, kayıtların kaynağını etiketlemek için veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen genellikle 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 Number, kod gönderimleri ve incelemeler gibi geliştirme faaliyetlerini ana 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 büyük önem taşır. İnceleme süreleri, inceleme sırasında belirlenen yeniden işleme döngüleri ve birleştirme oranları dahil 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 teslimat süresine etkisinin ayrıntılı biçimde analiz edilmesini sağlar.
Nereden alınır?
Birçok GitHub API yanıtında 'pull_request' nesnesindeki 'number' alanında veya Pull Requests API'sinden alınan ana tanımlayıcı olarak bulunur.
Örnekler
12345678910
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Bu kayda ait verilerin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgasıdır. | ||
|
Açıklama
Bu öznitelik, en son veri çıkarma veya güncelleme işleminin tarih ve saatini kaydeder. Analiz edilen verilerin güncelliği hakkında üst veri sağlar. Bu bilgi, iş 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ı verilere mi yoksa belirli bir andaki görüntüye mi baktığınızı anlamanıza yardımcı olur. Bu ayrım, operasyonel Dashboardlar ve izleme için önemlidir.
Neden önemli?
Verilerin güncelliğini gösterir. Analizlerin ve Dashboardların güncel bilgilere dayanmasını sağlamak için önemlidir.
Nereden alınır?
Bu zaman damgası, veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde 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 özelliği talep eden kişidir. Pull request'in yazarı ise kodu yazan geliştiricidir. Analizde yazar bilgisi, işin kaynağını anlamak için kullanılabilir. Örneğin hata raporlarının yazarlarını analiz etmek, belirli ekiplerle veya özelliklerle ilişkili kalıpları ortaya çıkarabilir. Ayrıca atanan kişiyle birlikte kullanılarak devir kalıpları analiz edilebilir.
Neden önemli?
Bir iş öğesini veya kod değişikliğini oluşturan kişiyi belirler. Yeniden işleme, hata raporları veya özellik taleplerinin kaynaklarını analiz etmek için yararlı olabilir.
Nereden alınır?
GitHub API'sinin sorunlar, pull request'ler ve commit'ler için döndürdüğü yanıtların ana nesnesindeki 'user' nesnesinde bulunur. Alan genellikle 'user.login' şeklindedir.
Örnekler
sara.jonesmike.leeautomation-bot
|
|||
|
Yeniden işleme mi
IsRework
|
Bir faaliyetin önceki bir süreç aşamasına geri dönüşü temsil etmesi durumunda true değerini alan boolean işareti. | ||
|
Açıklama
Bu işaret, bir geliştirme öğesi süreçte geriye doğru ilerlediğinde true olarak ayarlanır. Örneğin bir pull request 'Changes Requested' incelemesi aldığında veya bir issue kapatıldıktan sonra yeniden açıldığında bu durum oluşur. Değer, etkinlik sırası analiz edilerek türetilir. Bu öznitelik, israfı ve verimsizliği ölçmek için gereklidir. 'Rework and Regression Loops' Dashboardunu ve 'Rework Rate' KPI’ını doğrudan destekler. Analistler 'IsRework = true' filtresini kullanarak yeniden çalışmanın nedenlerini ayırıp inceleyebilir.
Neden önemli?
Yeniden işlemeyi oluşturan faaliyetleri açıkça işaretleyerek süreç verimsizliklerinin kolayca ölçülmesini, görselleştirilmesini ve nedenlerinin analiz edilmesini sağlar.
Nereden alınır?
Türetilmiş bir özniteliktir. Mantık, standart bir süreç akışı tanımlamayı ve daha önceki bir mantıksal aşamaya dönen faaliyetleri işaretlemeyi içerir.
Örnekler
truefalse
|
|||
Yazılım Geliştirme Yaşam Döngüsü Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
CI kontrolleri geçti
|
Pull request'teki kod üzerinde çalıştırılan 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 durumundan çıkarılır. | ||
|
Neden önemli?
Bu otomatik kalite kapısı, kodun kararlılığını sağlamak için önemlidir. Başarısızlıklar veya uzun çalışma süreleri, teslimat hattında önemli darboğazlar oluşturabilir.
Nereden alınır?
GitHub Checks API veya Statuses API'den çıkarılır. Bir kontrol çalıştırması veya durum güncellemesi 'success' ya da 'completed' ve 'success' sonucu bildirir.
Yakalayın
İlgili kontrol paketlerinde 'success' sonucunu görmek için Checks API'yi izleyin.
Olay türü
inferred
|
|||
|
Issue kapatıldı
|
Geliştirme öğesi tamamlanmış kabul edilir ve ilgili issue resmî olarak kapatılır. Bu işlem, bağlantılı bir pull request birleştirildiğinde otomatik olarak gerçekleşebilir veya bir ekip üyesi tarafından manuel yapılabilir. | ||
|
Neden önemli?
Bu etkinlik, bir geliştirme öğesi için sürecin kesin bitişini gösterir. Uçtan uca çevrim sürelerini hesaplamak için önemlidir.
Nereden alınır?
Bu, GitHub Issues API olay akışından alınan açık bir olaydır. Olay türü 'closed' olur.
Yakalayın
Webhook'lar veya API yoklaması aracılığıyla bir issue üzerindeki 'closed' olayını dinleyin.
Olay türü
explicit
|
|||
|
Issue oluşturuldu
|
Bir geliştirme öğesinin yaşam döngüsünün başlangıcını gösterir. Bir görevin, hatanın veya Özellik talebinin resmî olarak oluşturulmasını ifade eder. Bu olay, bir kullanıcı GitHub deposunda yeni bir issue oluşturduğunda açıkça kaydedilir. | ||
|
Neden önemli?
Bu, sürecin temel 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 issue numarası için olay türü genellikle 'opened' olur.
Yakalayın
Webhook'lar veya API yoklaması aracılığıyla bir issue üzerindeki 'opened' olayını dinleyin.
Olay türü
explicit
|
|||
|
Pull request açıldı
|
İlk kod bloğunun inceleme ve entegrasyona hazır olduğunu gösterir. Geliştirici, Özellik branch'inden ana branch'e değişiklik ö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 sona erdiğini ve inceleme ile entegrasyon hattının başladığını gösterir. Geliştirme ve inceleme çevrim sürelerini ayrı ayrı analiz etmek için önemlidir.
Nereden alınır?
GitHub Pull Request API olay akışından veya webhook'lardan alınır. Olay eylemi 'opened' olur.
Yakalayın
Webhook'lar veya API yoklaması aracılığıyla bir pull request için 'opened' eylemini dinleyin.
Olay türü
explicit
|
|||
|
Pull request birleştirildi
|
Pull request'teki onaylanmış kod değişiklikleri main veya develop gibi hedef branch'e resmî olarak entegre edilir. Bu, yeni kodu içeren pull request üzerindeki açık ve son eylemdir. | ||
|
Neden önemli?
Bu önemli kilometre taşı, geliştirme ve incelemenin tamamlandığını gösterir. Birçok ekip için otomatik dağıtımdan önceki son adımdır.
Nereden alınır?
GitHub Pull Request API olay akışından veya webhook'lardan alınır. Olay eylemi 'closed' olur ve pull request yükündeki 'merged' özniteliği true değerini taşır.
Yakalayın
Bir pull request üzerindeki 'closed' eylemini dinleyin ve 'merged' işaretinin true olup olmadığını kontrol edin.
Olay türü
explicit
|
|||
|
Pull request onaylandı
|
Bir incelemeci, 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 kalite kapılarından ve kilometre taşlarından biridir. PR oluşturulmasından bu duruma ulaşılana kadar geçen süre, inceleme sürecinin verimliliği için önemli bir KPI'dır.
Nereden alınır?
Bir inceleme 'APPROVED' durumuyla gönderildiğinde GitHub Pull Request API veya webhook'lardan alınır.
Yakalayın
Pull request inceleme gönderim olaylarını 'APPROVED' durumu için filtreleyin.
Olay türü
explicit
|
|||
|
Branch oluşturuldu
|
Bir geliştiricinin ana kod tabanından yeni bir branch oluşturduğu ve bir issue için aktif geliştirme çalışmasının başladığını gösterir. Bu, yeni bir branch depoya gönderildiğinde açıkça kaydedilen bir olaydır. Branch adı çoğu zaman issue numarasını içerir. | ||
|
Neden önemli?
Planlamadan aktif kodlamaya geçişi gösterir. Issue oluşturma ile bu olay arasındaki süreyi ölçmek, geliştiricinin işe başlama süresini ve başlangıç backlog gecikmelerini analiz etmeye yardımcı olur.
Nereden alınır?
GitHub Git API veya 'branch' türündeki 'create' olaylarını dinleyen webhook'lar aracılığıyla kaydedilir. Branch adını 'feature/issue-123' gibi adlandırma kurallarıyla bir issue'ya bağlamak çoğu zaman gerekir.
Yakalayın
Yeni branch'ler için 'create' webhook olaylarını ayrıştırın ve bunları bir issue ile ilişkilendirin.
Olay türü
explicit
|
|||
|
CI kontrolleri başarısız oldu
|
Pull request'teki kod üzerinde çalıştırılan derleme hatası veya başarısız birim testi gibi otomatik bir kontrolün başarısız olduğunu gösterir. Bu olay, GitHub Actions gibi bir sistemin bildirdiği başarısızlık durumundan çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, geliştirici müdahalesi gerektiren teknik kalite sorunlarını görünür kılar ve bir yeniden çalışma döngüsü oluşturur. Başarısızlık sıklığını analiz etmek, yerel testlerde veya kod kalitesinde yapılacak iyileştirmelere yön verebilir.
Nereden alınır?
GitHub Checks API veya Statuses API'den çıkarılır. Bir kontrol çalıştırması veya durum güncellemesi 'failure' ya da 'completed' ve 'failure' sonucu bildirir.
Yakalayın
İlgili kontrol paketlerinde 'failure' sonucunu görmek için Checks API'yi izleyin.
Olay türü
inferred
|
|||
|
Dağıtım başarılı oldu
|
Kod değişiklikleri staging veya production gibi belirli bir ortama başarıyla dağıtılmıştır. Bu olay genellikle GitHub Deployments API aracılığıyla, çoğu zaman birleştirme sonrasında GitHub Action tarafından tetiklenerek kaydedilir. | ||
|
Neden önemli?
Kodun depodan canlı ortama geçişini gösterir. Bunu izlemek, fikirden üretime kadar geçen toplam teslim süresini ölçmek için gereklidir.
Nereden alınır?
Deployments API aracılığıyla alınır. Harici bir hizmet veya GitHub Action bir dağıtım oluşturur ve ardından durumunu 'success' olarak günceller.
Yakalayın
Dağıtım durumu olaylarını webhook'lar aracılığıyla 'success' durumu için izleyin.
Olay türü
inferred
|
|||
|
İnceleme istendi
|
Pull request'in yazarı, kodunu incelemeleri için belirli ekip üyelerinden veya ekiplerden resmî olarak talepte bulunur. Bu, GitHub kullanıcı arayüzünde veya API'sinde gerçekleştirilen ve seçilen incelemecilere bildirim gönderen açık bir eylemdir. | ||
|
Neden önemli?
Bu etkinlik, kod inceleme sürecine resmî devir teslimin başladığını gösterir. Bu etkinlik ile incelemenin gönderilmesi arasındaki süre, incelemecilerin yanıt verme hızını ve olası darboğazları ölçmeye yardımcı olur.
Nereden alınır?
GitHub Pull Request API olay akışından veya webhook'lardan alınır. Olay eylemi 'review_requested' olur.
Yakalayın
Bir pull request için 'review_requested' eylemini dinleyin.
Olay türü
explicit
|
|||
|
İncelemede değişiklik istendi
|
Bir incelemeci kod incelemesini tamamlamış ve pull request'in onaylanabilmesi için 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 etmek, kalite sorunlarını, belirsiz gereksinimleri veya geliştirici eğitimi gerektiren alanları belirlemeye yardımcı olur.
Nereden alınır?
Bir inceleme 'CHANGES_REQUESTED' durumuyla gönderildiğinde GitHub Pull Request API veya webhook'lardan alınır.
Yakalayın
Pull request inceleme gönderim olaylarını 'CHANGES_REQUESTED' durumu için filtreleyin.
Olay türü
explicit
|
|||
|
Issue yeniden açıldı
|
Daha önce kapatılmış bir issue, genellikle düzeltmenin yetersiz kalması veya bir regresyon bulunması nedeniyle yeniden etkinleştirilir. Bu, geliştirme öğesinin yaşam döngüsünü yeniden başlatan açık bir olaydır. | ||
|
Neden önemli?
Bu, önemli bir yeniden çalışma döngüsünü gösterir ve olası bir üretim hatasının kaçtığına veya düzeltmenin tamamlanmadığına işaret eder. Sıklığını izlemek, genel yazılım kalitesinin önemli bir ölçümüdür.
Nereden alınır?
Bu, GitHub Issues API olay akışından alınan açık bir olaydır. Olay türü 'reopened' olur.
Yakalayın
Webhook'lar veya API yoklaması aracılığıyla bir issue üzerindeki 'reopened' olayını dinleyin.
Olay türü
explicit
|
|||
|
PR'ye kod gönderildi
|
İncelemeye gönderilen kodun, ilk PR'nin parçası olarak veya inceleme geri bildirimine yanıt olarak güncellendiğini gösterir. Bu olay, açık bir pull request ile ilişkilendirilmiş branch'e her yeni commit gönderildiğinde kaydedilir. | ||
|
Neden önemli?
Bu olayları izlemek, yeniden çalışma döngülerini belirlemek için önemlidir. İncelemeden sonra birden fazla gönderim yapılması, değişiklik gerektiğini gösterir ve toplam çevrim süresini etkiler.
Nereden alınır?
Bu, pull request zaman çizelgesinde açıkça yer alan bir olaydır ve çoğu zaman commit eklenmesi olarak etiketlenir. 'push' webhook'undan veya bir PR ile ilişkilendirilmiş commit'leri izleyerek alınabilir.
Yakalayın
Açık bir pull request ile ilişkilendirilmiş branch üzerindeki 'push' olaylarını izleyin.
Olay türü
explicit
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Verilerinizi hazırlamak ve yazılım geliştirme yaşam döngünüzü optimize etmeye başlamak için bu şablondan yararlanın. Verimsizlikleri keşfedin ve daha hızlı, daha akıcı sürümler yayınlayın.
SDLC'nizi iyileştirin: Verimsizlikleri anında belirleyin
Çevrim süresini %30 azaltın ve GitHub geliştirme sürecinizi daha akıcı hale getirin.
Kredi kartı gerekmez, dakikalar içinde kurulumu tamamlayın.