Yazılım Geliştirme Yaşam Döngüsü Veri Template'iniz
Yazılım Geliştirme Yaşam Döngüsü Veri Template'iniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
Yazılım Geliştirme Yaşam Döngüsü Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
Activity
|
Meydana gelen belirli süreç adımının veya olayın adı, örneğin 'Sorun Oluşturuldu' veya 'Birleştirme İsteği Birleştirildi'. | ||
|
Açıklama
Aktivite özniteliği, bir Geliştirme Öğesinde meydana gelen belirgin olayları yakalar. Bunlar GitLab'de tek bir alan olarak saklanmaz, ancak Issues, Merge Requests ve CI/CD Pipeline'ları genelindeki çeşitli eylemlerden ve zaman damgası alanlarından türetilir. Örneğin, bir sorunun oluşturulması, bir commit'in gönderilmesi, bir pipeline'ın başarısız olması veya bir birleştirme isteğinin onaylanması hepsi farklı aktivitelerdir. Bu öznitelik, süreç haritası oluşturmak, iş akışını görselleştirmek ve olayların sırasını ve sıklığını analiz etmek için temeldir. Sapmaları, adımlar arasındaki darboğazları ve ortak süreç yollarını belirlemek için kullanılır.
Neden önemli
Süreç haritasındaki adımları tanımlar, uçtan uca geliştirme iş akışının görselleştirilmesine ve analiz edilmesine olanak tanır.
Nereden alınır
GitLab'in olay akışındaki
Örnekler
Sorun OluşturulduGeliştirme BaşladıBirleştirme İsteği BirleştirildiPipeline Başarısız OlduÜretime Dağıtıldı
|
|||
|
Başlangıç Zamanı
StartTime
|
Bir etkinlik veya olayın ne zaman başladığını gösteren `timestamp` (zaman damgası). | ||
|
Açıklama
StartTime, belirli bir aktivitenin meydana geldiği kesin tarihi ve saati işaretler. GitLab'deki olaylar için bu, çeşitli zaman damgası alanlarında yakalanır. Örneğin, 'Sorun Oluşturuldu' aktivitesinin StartTime'ı sorunun Bu zaman damgası, süreç madenciliğindeki temel zamansal öğedir. Olayları kronolojik olarak sıralamak, aktiviteler arasındaki süreleri hesaplamak, döngü sürelerini ölçmek ve zaman içindeki süreç performansını analiz etmek için kullanılır.
Neden önemli
Bu öznitelik, tüm zaman tabanlı metrikleri hesaplamak ve süreç akışını anlamak için temel olan kronolojik olay dizisini sağlar.
Nereden alınır
GitLab'deki çeşitli
Örnekler
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Geliştirme Öğesi
DevelopmentItem
|
Bir özellik, hata düzeltmesi veya görev gibi bir iş birimi için benzersiz tanımlayıcı, birincil vaka tanımlayıcısı olarak hizmet verir. | ||
|
Açıklama
Geliştirme Öğesi, yazılım geliştirme yaşam döngüsü boyunca akan tek, izlenebilir bir iş parçasını temsil eder. Oluşturulmasından nihai dağıtımına kadar tüm ilgili aktiviteleri tutarlı bir vakaya bağlar. GitLab'de bu, genellikle bir proje içinde benzersiz olan Issue'nun dahili Kimliği (IID) ile temsil edilir. Geliştirme Öğesine göre analiz, uçtan uca döngü süresi ölçümü, darboğaz tespiti ve süreç uygunluk kontrolü sağlar. İşin konseptten prodüksiyona ne kadar verimli bir şekilde teslim edildiğini anlamanın temelini oluşturur.
Neden önemli
Bu, tüm süreç olaylarını birbirine bağlayan temel vaka tanımlayıcısıdır ve herhangi bir iş öğesinin tam yaşam döngüsünü izlemeyi mümkün kılar.
Nereden alınır
Bu genellikle bir GitLab Issue'nun dahili ID'sidir (IID). Issues API yanıtında 'iid' alanı olarak bulunabilir.
Örnekler
1024512PRJ-2345
|
|||
|
Atanan Kişi
Assignee
|
Olay anında soruna veya birleştirme isteğine atanan kullanıcı. | ||
|
Açıklama
Atanan, sürecin belirli bir noktasında iş öğesinden sorumlu bireysel geliştirici veya kullanıcıdır. GitLab'de bu, bir Issue veya Merge Request'in Atanana göre analiz, 'Geliştirici İş Yükü ve Tahsisi' dashboard'u için kritiktir. Kaynak kullanımını anlamaya, aşırı yüklenmiş bireyleri veya ekipleri belirlemeye ve farklı kişiler arasındaki devirleri analiz etmeye yardımcı olur.
Neden önemli
İşi kimin yaptığını takip ederek iş yükü analizi, kaynak tahsis verimliliği ve el değiştirmelerden kaynaklanan gecikmelerin tespit edilmesini sağlar.
Nereden alınır
GitLab Issues ve Merge Requests API yanıtlarındaki 'assignee.username' veya 'assignees' alanlarından alınmıştır.
Örnekler
jdoeasmithr.williams
|
|||
|
Bitiş Saati
EndTime
|
Bir aktivitenin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
EndTime, bir aktivitenin bittiği tam tarih ve saati belirtir. GitLab'deki 'Issue Created' (Talep Oluşturuldu) gibi pek çok atomik olayda EndTime, StartTime ile aynıdır. 'Code Review' (Kod İncelemesi) gibi belirli bir süresi olan aktivitelerde ise tamamlanma zaman damgasını, örneğin son onayın verildiği anı temsil eder. Bu öznitelik, münferit aktivitelerin süresini (İşlem Süresi) doğru hesaplamak için kritiktir. Aktif çalışma süresi ile görevler arasındaki bekleme süresini birbirinden ayırarak detaylı darboğaz (bottleneck) analizine yardımcı olur.
Neden önemli
Süreçteki verimsiz adımları belirlemede anahtar olan kesin etkinlik sürelerinin (işleme süreleri) hesaplanmasını sağlar.
Nereden alınır
Atomik olaylar için bu, StartTime ile aynıdır. Süreli aktiviteler için, verilerdeki karşılık gelen bir tamamlanma olayını bularak türetilmelidir.
Örnekler
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Geliştirme Öğesi Türü
DevelopmentItemType
|
Geliştirme öğesinin 'Özellik', 'Hata', 'Görev' veya 'Bakım' gibi sınıflandırması. | ||
|
Açıklama
Bu öznitelik, gerçekleştirilen işin doğasını kategorize eder. GitLab'de bu, genellikle bir sorun üzerindeki etiketler kullanılarak uygulanır. Ekipler, yeni işlevsellik, hata çözümü, teknik borç ve diğer iş türleri arasında ayrım yapmak için etiketleri kullanır. Geliştirme Öğesi Türüne göre analiz, farklı iş türleri için süreç akışlarını ve döngü sürelerini karşılaştırmaya olanak tanır. Örneğin, hataların özelliklerden daha hızlı çözülüp çözülmediği veya teknik borç görevlerinin farklı bir inceleme sürecini takip edip etmediği analiz edilebilir.
Neden önemli
Süreci iş türüne göre segmentlere ayırmak, belirli iş türlerinin gecikmelere, tekrar işleme veya sapmalara daha yatkın olup olmadığını belirlemeye yardımcı olur.
Nereden alınır
Genellikle bir GitLab Issue'una uygulanan 'etiketlerden' türetilir. Belirli etiketleri standartlaştırılmış tiplere çevirmek için bir eşleme mantığına ihtiyaç vardır.
Örnekler
ÖzellikHataGörevTeknik Borç
|
|||
|
Proje Adı
ProjectName
|
Geliştirme öğesinin ait olduğu GitLab projesinin adı. | ||
|
Açıklama
Bu öznitelik, işin yapıldığı belirli kod deposunu veya projeyi tanımlar. GitLab'de her sorun ve birleştirme isteği bir projenin içindedir. Proje Adına göre analiz yapmak, farklı ürünler, bileşenler veya hizmetler arasında performans karşılaştırmalarına olanak tanır. Belirli projelerin diğerlerinden daha sağlıklı SDLC süreçlerine sahip olup olmadığını belirlemeye yardımcı olabilir ve dashboard'ları belirli bir ilgi alanına göre filtrelemek için kullanışlıdır.
Neden önemli
Süreç analizinin ürüne, uygulamaya veya bileşene göre segmentlere ayrılmasını sağlayarak, hedeflenmiş iyileştirme çabalarını kolaylaştırır.
Nereden alınır
Project API'deki 'name' veya 'path_with_namespace' alanlarından, Issues ve Merge Requests'deki 'project_id' aracılığıyla bağlantılı olarak alınmıştır.
Örnekler
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Şiddet
Severity
|
Geliştirme öğesinin önem derecesi, genellikle hatalar veya olaylar için. | ||
|
Açıklama
Önem derecesi, kritikden küçük olana kadar bir hata veya sorunun etkisini gösterir. GitLab'de yerleşik bir önem derecesi alanı bulunmadığından, bu neredeyse her zaman etiketler (örneğin, 'severity::1', 'severity::2') kullanılarak uygulanır. Bu öznitelik, 'Önem Derecesi Artış Trendleri' Dashboard'u ve ilişkili KPI için çok önemlidir. Yaşam döngüsü boyunca önem derecesindeki değişiklikleri analiz etmek, başlangıçta hafife alınan sorunları veya problemleri ağırlaştıran süreçleri vurgulayabilir.
Neden önemli
İşi önceliklendirmeye ve yüksek önem dereceli maddelerin daha hızlı ele alınıp alınmadığını analiz etmeye yardımcı olur. Değişiklikleri izlemek, 'Önem Derecesi Artış Sıklığı' KPI'ını destekler.
Nereden alınır
Bir GitLab Sorununa uygulanan 'etiketlerden' türetilmiştir. 'S1', 'S2' gibi etiketleri şiddet seviyeleri olarak yorumlamak için bir eşleme gereklidir.
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
Aktarım Bekleme Süresi
HandoffWaitTime
|
Farklı atanan kişiler tarafından gerçekleştirilen iki ardışık etkinlik arasındaki hesaplanan boşta kalma süresi. | ||
|
Açıklama
Bu metrik, bir aktivitenin tamamlanması ile bir sonrakinin başlaması arasındaki boşluğun süresini, özellikle atanan kişi değiştiğinde hesaplar. Örneğin, bir geliştiricinin işini bitirmesinden bir incelemecinin kod incelemesine başlamasına kadar geçen süreyi ölçer. Bu, 'Ortalama Devir Bekleme Süresi' KPI'sı için anahtar metrik olup kaynak tahsisindeki ve ekipler veya bireyler arasındaki iletişimdeki gizli verimsizlikleri ortaya çıkarmaya yardımcı olarak, aktif bir işin parçası olmayan gecikmeleri vurgular.
Neden önemli
Farklı kişiler veya ekipler arasındaki devirler sırasındaki boşta kalma süresini nicelendirir, gizli gecikmeleri ve iletişim darboğazlarını ortaya çıkarır.
Nereden alınır
Process mining aracı tarafından hesaplanır. Bir
Örnekler
1 gün 2 saat15 dakika8 saat
|
|||
|
Birleştirme İsteği Durumu
MergeRequestStatus
|
Olayla ilişkili birleştirme isteğinin durumu, örneğin 'Açıldı', 'Birleştirildi' veya 'Kapalı'. | ||
|
Açıklama
Bu öznitelik, bir olayın anındaki Birleştirme İsteği (MR) durumunu yakalar. GitLab MR'larının 'açık', 'kapalı', 'birleştirilmiş' veya 'kilitli' gibi farklı durumları vardır. Bu, genel Geliştirme Öğesi Durumundan ayrıdır. MR durumunu takip etmek, SDLC'nin kod entegrasyon aşamasını analiz etmek için kritik öneme sahiptir. 'Kod İnceleme Döngü Süresi ve Verimlilik' gibi dashboard'ları doğrudan destekler ve MR oluşturma, inceleme, onay ve birleştirme arasındaki gecikmeleri belirlemeye yardımcı olur.
Neden önemli
Kod inceleme ve birleştirme sürecine görünürlük sağlar, bu da SDLC'de genellikle kritik bir darboğazdır.
Nereden alınır
GitLab Merge Requests API yanıtındaki 'state' alanından alınmıştır.
Örnekler
openedmergedkapalılocked
|
|||
|
Döngü Süresi
CycleTime
|
Bir geliştirme öğesi için ilk aktiviteden son aktiviteye kadar geçen toplam süre. | ||
|
Açıklama
Döngü Süresi (Cycle Time), bir Bu, genel süreç verimliliğini ölçmek için birincil bir KPI'dır. 'SDLC Uçtan Uca Döngü Süresi' gibi
Neden önemli
Bu, geliştirme yaşam döngüsünün uçtan uca verimliliğini ölçen temel bir Process Mining KPI'ıdır.
Nereden alınır
Process mining aracı tarafından her benzersiz CaseId için maksimum
Örnekler
10 gün 4 saat23 saat 15 dakika35 gün
|
|||
|
Dönüm Noktası Başlığı
MilestoneTitle
|
Geliştirme öğesinin atandığı dönüm noktasının veya sprintin başlığı. | ||
|
Açıklama
GitLab'de bir Dönüm Noktası (Milestone), sprint veya sürüm gibi belirli bir hedefe veya zaman dilimine karşı işi izlemek için kullanılır. Bu Bu
Neden önemli
Geliştirme çalışmalarını sprintler veya sürümler gibi planlama döngülerine bağlar, planlanan zaman kutularına göre performans analizini mümkün kılar.
Nereden alınır
GitLab Issues veya Merge Requests API yanıtlarındaki 'milestone.title' alanından alınmıştır.
Örnekler
2023 4. Çeyrek SürümüSprint 23.11Aşama 1: MVP
|
|||
|
Ekip Adı
TeamName
|
Proje veya atanana bağlı geliştirme ekibi. | ||
|
Açıklama
Ekip Adı, geliştirme öğesinden sorumlu grubu veya takımı temsil eder. Bu bilgi genellikle GitLab'de standart bir alan değildir ve genellikle proje adlandırma kurallarından, grup yapılarından veya atananları harici bir referans tablosu kullanarak ilgili ekiplerine eşleştirerek türetilir. Bu öznitelik, süreç performansını ekip düzeyinde analiz etmek için kullanılır. Farklı ekipler arasındaki verimliliği, iş yükünü ve sürece bağlılığı karşılaştırmaya yardımcı olur, 'Aşamaya Özgü Darboğaz Analizi' gibi Dashboard'ları ekip tabanlı bir görünümden destekler.
Neden önemli
Farklı ekipler arasında performans analizi ve süreç karşılaştırması yapılmasına olanak tanır, ekip bazında
Nereden alınır
Genellikle Proje Adı veya Atananı GitLab dışında tanımlanmış bir ekip yapısına eşleyerek veya GitLab grup hiyerarşilerinden çıkarılarak elde edilir.
Örnekler
Frontend-AlphaBackend-HizmetleriPlatform-Infra
|
|||
|
Geliştirme Öğesi Durumu
DevelopmentItemStatus
|
Olay anındaki geliştirme öğesinin durumu, örneğin 'Açık', 'Devam Ediyor' veya 'Kapalı'. | ||
|
Açıklama
Bu öznitelik, birincil iş öğesinin durumunu yansıtır, genellikle GitLab'deki bir Issue'dur. GitLab Issue'larının 'açık' veya 'kapalı' olabilen bir Durum değişikliklerini izlemek, vaka yaşam döngüsünü anlamak için çok önemlidir. Öğelerin her durumda ne kadar zaman geçirdiğini belirlemeye yardımcı olur ve 'SDLC Uçtan Uca Döngü Süresi' gibi dashboard'larda aktif veya tamamlanmış işleri filtrelemek için kullanılabilir.
Neden önemli
Davanın durumunun bir anlık görüntüsünü sunarak, çeşitli aşamalarda harcanan sürenin analizini ve devam eden ile tamamlanmış işler arasında filtreleme yapılmasını sağlar.
Nereden alınır
Birincil durum, bir GitLab Issue'nun 'state' alanından ('opened', 'closed') gelir. Daha ayrıntılı durumlar genellikle etiketlerden türetilir.
Örnekler
openedkapalıDevam Ediyorİncelemede
|
|||
|
Hedef Dal
TargetBranch
|
Bir birleştirme isteği için hedef dalın adı. | ||
|
Açıklama
Hedef Dal, değişikliklerin birleştirilmesi amaçlanan daldır; örneğin 'main', 'develop' veya 'release/1.5' gibi bir sürüm dalı. Bu, herhangi bir Birleştirme İsteği için temel bir bilgi parçasıdır. Hedef Bala göre analiz yapmak, farklı hedeflere birleştirilen kodlar için farklı süreç davranışlarını ortaya çıkarabilir. Örneğin, 'main' dalına birleştirmeler, bir özellik dalına birleştirmelerden daha titiz bir onay sürecine ve daha uzun döngü sürelerine sahip olabilir. Ayrıca üretim dağıtımlarını diğer kod entegrasyonu türlerinden ayırmaya da yardımcı olabilir.
Neden önemli
Hedef dallara bağlı olarak süreçler önemli ölçüde değişebildiğinden, çeşitli geliştirme ve sürüm iş akışlarını ayırt etmeye yardımcı olur.
Nereden alınır
GitLab Merge Requests API yanıtındaki 'target_branch' alanından alınmıştır.
Örnekler
maingeliştirmerelease/v2.1.0hotfix/user-auth-bug
|
|||
|
İşlem Süresi
ProcessingTime
|
Tek bir aktivitenin süresi, bitiş ve başlangıç zamanı arasındaki fark olarak hesaplanır. | ||
|
Açıklama
İşlem süresi, belirli bir aktivite için aktif çalışma süresini ölçer ve aktiviteler arasındaki bekleme süresinden farklıdır. Tek bir olay kaydı için EndTime eksi StartTime olarak hesaplanır. Anlık olaylar için işlem süresi sıfırdır. Bu metrik, Aşamaya Özgü Darboğaz Analizi için kritik öneme sahiptir. Kod İncelemesi gibi bir aşamadaki aktivitelerin işlem sürelerini bir araya getirerek, analistler aktif olarak ne kadar süre harcandığını tam olarak belirleyebilir ve verimsiz süreç adımlarını tespit etmeye yardımcı olabilir.
Neden önemli
Bireysel aktivitelerin süresini ölçer, hassas darboğaz analizi için aktif çalışma süresini boşta bekleme süresinden ayırmaya yardımcı olur.
Nereden alınır
Process mining aracı tarafından bir etkinliğin
Örnekler
2 saat 30 dakika0 dakika3 gün 8 saat
|
|||
|
Kaynak Sistem
SourceSystem
|
Verilerin kaynaklandığı sistemi tanımlar. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu veri modeli için değer tutarlı olarak 'GitLab' olacaktır. Bu özniteliği dahil etmek, süreç verilerinin birden fazla sistemden (örneğin planlama için Jira ve yürütme için GitLab) birleştirilebileceği ortamlarda çok önemlidir. Filtreleme, segmentasyon sağlar ve veri kökenini korumaya yardımcı olur.
Neden önemli
Veri kaynağı konusunda netlik sağlayarak veri yönetişimi ve birden fazla kurumsal sistemden veri entegrasyonu için kritik bir avantaj sunar.
Nereden alınır
Bu, veri dönüştürme süreci sırasında eklenen statik bir değer olan 'GitLab'dir.
Örnekler
GitLab
|
|||
|
Pipeline Durumu
PipelineStatus
|
CI/CD pipeline çalıştırmasının durumu, örneğin 'Başarılı', 'Başarısız' veya 'Çalışıyor'. | ||
|
Açıklama
Bu öznitelik, bir commit veya birleştirme isteğiyle ilişkili bir CI/CD pipeline yürütmesinin sonucunu gösterir. GitLab'deki yaygın durumlar arasında 'running', 'pending', 'success', 'failed', 'canceled' ve 'skipped' bulunur. Bu veri, 'Tekrar İşleme ve Yeniden Çalıştırma Analizi' dashboard'u için temeldir. Sık pipeline hataları, önemli bir tekrar işleme ve gecikme kaynağı olabilir ve bunların sıklığını, konumunu ve etkisini analiz etmek, geliştirme verimliliğini ve kod kalitesini artırmak için anahtardır.
Neden önemli
Otomatik derlemelerin ve testlerin başarılarını/başarısızlıklarını izler; yeniden işleme döngülerini ve kod kalitesi veya test otomasyonuyla ilgili sorunları ortaya çıkarır.
Nereden alınır
GitLab CI/CD Pipelines API yanıtındaki 'status' alanından alınmıştır.
Örnekler
successbaşarısızrunningiptal edildi
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Bu olay için verilerin kaynak sistemden en son ne zaman güncellendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, olay verilerinin süreç madenciliği veri kümesinde en son ne zaman çıkarıldığını veya güncellendiğini kaydeder. Olayın ne zaman meydana geldiğini değil, olayın kaydının en son ne zaman senkronize edildiğini gösterir. Bu bilgi, veri güncelliğini anlamak ve süreç analizinin zamanlamasını doğrulamak için hayati öneme sahiptir. Kullanıcıların dashboard'ların ve KPI'ların güncel verilere dayandığına güvenmelerine yardımcı olur ve kaynak sistemi ile analiz arasındaki olası gecikme hakkında bilgi verir.
Neden önemli
Veri güncelliği konusunda şeffaflık sağlayarak, kullanıcıların süreç analizinin ne kadar güncel olduğundan haberdar olmalarını temin eder.
Nereden alınır
Bu zaman damgası, bir veri yenilemesi sırasında veri çıkarma aracı veya ETL süreci tarafından oluşturulur ve kaydedilir.
Örnekler
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Sürüm Versiyonu
ReleaseVersion
|
Dağıtımla ilişkili planlanan veya gerçek yazılım sürüm etiketi. | ||
|
Açıklama
Bu öznitelik, bir geliştirme öğesinin parçası olduğu belirli yazılım sürümünü tanımlar. GitLab'de bu, bir Dönüm Noktası, korumalı bir etiket veya Sürümler özelliğindeki bir giriş aracılığıyla ilişkilendirilebilir. Bu, 'Sürüm Takvimi Uyumluluk Takibi' dashboard'u için temeldir. Gerçek dağıtım tarihini sürüm versiyonuyla ilişkili planlanan bir tarihle karşılaştırarak, kuruluşlar takvimlere uyma yeteneklerini ölçebilir ve sürüm gecikmelerinin nedenlerini teşhis edebilir.
Neden önemli
Geliştirme öğelerini belirli bir yazılım sürümüne bağlar; bu, sürüm ilerlemesini ve zaman çizelgesine uyumu izlemek için çok önemlidir.
Nereden alınır
Bu, GitLab Sürümleri'nden, bir git etiketinin adından veya sürüm planlaması için kullanılan bir dönüm noktasının başlığından alınabilir.
Örnekler
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
Yeniden İşleme mi?
IsRework
|
Bir etkinliğin yeniden işleme döngüsünün bir parçası olup olmadığını gösteren bir boolean bayrağı. | ||
|
Açıklama
Bu hesaplanmış öznitelik, test başlamışken geliştirmeye geri dönme gibi süreçte geriye doğru bir adımı temsil eden aktiviteleri işaretler. Bu işaret için mantık genellikle belirli aktivite dizilerini tespit etmeyi içerir; örneğin, aynı durum için bir 'Pipeline Başarısız Oldu' veya 'KG Testi Başladı' olayından sonra bir 'Geliştirme Başladı' olayının meydana gelmesi. Bu öznitelik, 'Tekrar İşleme ve Yeniden Çalıştırma Analizi' dashboard'unu ve 'Test Sonrası Tekrar İşleme Oranı' KPI'ını doğrudan destekler. Tekrar işlemenin kolayca filtrelenmesini ve nicelleştirilmesini sağlayarak ekiplerin sıklığını, nedenlerini ve proje zaman çizelgeleri üzerindeki etkisini anlamalarına yardımcı olur.
Neden önemli
Yeniden işi doğrudan işaretler ve nicelleştirir, bu da süreç verimsizliklerinin ve kalite sorunlarının nedenlerini ve etkilerini analiz etmeyi kolaylaştırır.
Nereden alınır
Process mining aracı tarafından her
Örnekler
truefalse
|
|||
Yazılım Geliştirme Yaşam Döngüsü Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Birleştirme İsteği Birleştirildi
|
Bu aktivite, kod inceleme ve entegrasyon sürecinin başarılı bir şekilde tamamlandığını gösterir. Bir kullanıcının birleştirme isteğinin dalını hedef dala birleştirdiğinde meydana gelen açık bir olaydır. | ||
|
Neden önemli
Bu, geliştirme ve incelemenin tamamlandığını gösteren önemli bir dönüm noktasıdır. Geliştirme döngü süresini ölçmek için bitiş noktası ve dağıtım teslim süresini ölçmek için başlangıç noktası olarak hizmet eder.
Nereden alınır
Bu, 'merge_requests' tablosundaki 'merged_at' zaman damgasından yakalanan açık bir olaydır. Birleştirme sırasında bir sistem notu da oluşturulur.
Yakala
Merge request'in 'merged_at' zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Birleştirme İsteği Oluşturuldu
|
İlk geliştirme çalışmasının tamamlandığını ve kodun inceleme ve entegrasyon için hazır olduğunu gösterir. Bu, bir geliştiricinin yeni bir birleştirme isteği (MR) açtığında yakalanan, GitLab iş akışında açık ve temel bir olaydır. | ||
|
Neden önemli
Bu, geliştirmeden inceleme ve teste geçişi işaret eden kritik bir dönüm noktasıdır. Tüm kod inceleme ve CI/CD pipeline döngüsünü analiz etmek için giriş noktasıdır.
Nereden alınır
Bu, 'merge_requests' tablosundaki 'created_at' zaman damgasından veya Merge Requests API aracılığıyla yakalanan açık bir olaydır.
Yakala
Merge request'in 'created_at' zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Sorun Oluşturuldu
|
Bu aktivite, bir özellik, hata veya görev gibi yeni bir iş öğesinin oluşturulmasını temsil ederek geliştirme yaşam döngüsünün başlangıcını işaretler. Bir kullanıcı GitLab'de yeni bir sorun oluşturduğunda açıkça yakalanır ve bu da oluşturma zaman damgasını kaydeder. | ||
|
Neden önemli
Bu, uçtan uca süreç için birincil başlangıç olayıdır. Sorun oluşturmadan dağıtıma kadar geçen süreyi analiz etmek, SDLC döngü süresinin tam bir resmini sağlar.
Nereden alınır
Bu, 'issues' tablosundaki 'created_at' zaman damgasından veya Issues API aracılığıyla yakalanan açık bir olaydır. Sistem notları da oluşturma olayını kaydeder.
Yakala
Issue'nun 'created_at' zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Üretime Dağıtıldı
|
Bu aktivite, kodun canlı üretim ortamına başarılı bir şekilde dağıtıldığını işaret eder ve son kullanıcılara sunulmasını sağlar. Bu, bir GitLab CI/CD pipeline'ında belirli bir 'üretim ortamına dağıt' görevinin başarıyla tamamlanmasıyla yakalanır. | ||
|
Neden önemli
Bu, sürecin birincil bitiş olayıdır ve değerin teslim edildiğini gösterir. Toplam uçtan uca SDLC döngü süresini ve sürüm sıklığını ölçmek için temeldir.
Nereden alınır
Özellikle üretim dağıtımı için belirlenmiş başarılı bir CI/CD işinin 'finished_at'
Yakala
Başarılı bir üretim dağıtımı CI işindeki 'finished_at' zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Dağıtım Başladı
|
Kodu staging veya production gibi belirli bir ortama yayınlama sürecinin başlangıcını temsil eder. GitLab'de bu, bir CI/CD pipeline'ı içindeki bir 'deploy' görevinin başlangıcına karşılık gelir. | ||
|
Neden önemli
Dağıtım başlangıcını takip etmek, dağıtım aşamasının süresini izole etmeye yardımcı olur. Dağıtım teslim süresini ölçmek ve optimize etmek için çok önemlidir.
Nereden alınır
Dağıtım işi olarak yapılandırılmış bir CI/CD işinin 'started_at'
Yakala
Bir dağıtım görevi için CI iş günlüğündeki 'started_at' zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Geliştirme Başladı
|
Bu aktivite, sorun üzerinde aktif kodlama çalışmasının başlangıcını işaret eder. GitLab'de açık bir 'geliştirmeyi başlat' düğmesi bulunmadığından, bu genellikle soruna bağlı bir dala gönderilen ilk kod commit'inden çıkarılır. | ||
|
Neden önemli
Değer katan geliştirme çalışmasının kesin başlangıcını belirler, saf kodlama aşamasının doğru bir şekilde ölçülmesine ve planlama veya bekleme süresinden ayrılmasına olanak tanır.
Nereden alınır
Soruna bağlı bir özellik dalındaki ilk commit'in zaman damgasının bulunmasıyla çıkarılır. Bu, sorunları dallara bağlamayı gerektirir ve genellikle adlandırma kuralları veya meta veriler aracılığıyla yapılır.
Yakala
İlgili sorun kimliğine sahip bir daldaki ilk commit zaman damgasını bulun.
Event tipi
inferred
|
|||
|
Kod İncelemesi Başladı
|
Bir birleştirme isteği için akran inceleme sürecinin başlangıcını işaretler. Bu olay, yazar dışında birisi tarafından gönderilen ilk yorum veya konu gibi ilk inceleme ile ilgili eylemden çıkarılır. | ||
|
Neden önemli
MR oluşturma anından inceleme başlangıcına kadar geçen süreyi ölçmek, kuyruklanma gecikmelerini vurgular. Bu bekleme süresini azaltmak, genel kod inceleme döngüsünü kısaltmanın anahtarıdır.
Nereden alınır
Birleştirme isteğindeki, MR yazarından olmayan ilk yorum veya inceleme dizisinin zaman damgasından çıkarılır. Bu veriler sistem notları veya Notlar API'si aracılığıyla elde edilebilir.
Yakala
Bir MR'daki yazar olmayan ilk kullanıcı yorumunun zaman damgasını bulun.
Event tipi
inferred
|
|||
|
Onay Eklendi
|
Bir incelemeci tarafından birleştirme isteğindeki kod değişikliklerinin resmi onayını temsil eder. Bu, bir kullanıcının 'Onayla' düğmesine tıkladığında GitLab tarafından yakalanan açık bir olaydır. | ||
|
Neden önemli
Onaylar, temel kalite kapılarıdır. Onayları izlemek, gerekli imzaları almanın ne kadar sürdüğünü analiz etmeye yardımcı olur ve inceleme politikalarına
Nereden alınır
Birleştirme isteği onay olaylarından alınır. Bunlar Onaylar API'si aracılığıyla kullanılabilir veya MR'ın geçmişinde görülebilir.
Yakala
Merge request onay olay günlüğündeki zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Pipeline Başarısız Oldu
|
Bu aktivite, bir CI/CD pipeline yürütmesinin herhangi bir aşamada, örneğin bir build hatası veya başarısız bir test gibi, başarısız olması durumunda meydana gelir. GitLab, her pipeline'ın son durumunu açıkça kaydeder ve hataların kolayca belirlenmesini sağlar. | ||
|
Neden önemli
Pipeline hataları, tekrar işleme neden olan başlıca faktörlerden biridir. Sıklıklarını, sürelerini ve nedenlerini analiz etmek, kalite sorunlarını, kararsız testleri ve geliştiricilere geri bildirim döngüsündeki darboğazları belirlemeye yardımcı olur.
Nereden alınır
'ci_pipelines' tablosundaki bir pipeline kaydındaki 'failed' durumu ile tanımlanır. 'finished_at' zaman damgası, hatanın ne zaman meydana geldiğini gösterir.
Yakala
Hatalı' durumdaki pipeline kayıtlarını filtreleyin ve 'finished_at' zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Pipeline Başladı
|
Otomatik bir CI/CD pipeline'ının başlatılmasını temsil eder; bu genellikle build'ler, testler ve güvenlik taramaları çalıştırır. GitLab, bir pipeline bir commit veya MR oluşturma gibi bir olayla tetiklendiğinde açıkça bir başlangıç zaman damgasıyla bir pipeline kaydı oluşturur. | ||
|
Neden önemli
Pipeline yürütmelerini takip etmek, otomatik test ve entegrasyon süreçlerinin sağlığını ve verimliliğini izlemek için temeldir. Otomatik doğrulama işlemlerinde ne kadar zaman harcandığını belirlemeye yardımcı olur.
Nereden alınır
'ci_pipelines' tablosundaki bir
Yakala
MR'ın dalıyla ilişkili pipeline yürütme kaydındaki zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Sorun Atandı
|
Bir sorunun belirli bir geliştiriciye veya ekibe atanmasını temsil eder ve işin sahipliğinin belirlendiğini gösterir. Bu, bir sorunun assignee alanı her doldurulduğunda veya değiştirildiğinde GitLab tarafından kaydedilen açık bir olaydır. | ||
|
Neden önemli
Atamaları takip etmek, kaynak tahsisi, ekip iş yükü ve devir sürelerini analiz etmek için çok önemlidir. İşin oluşturulması ile alınması arasındaki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır
GitLab'in sorunla ilgili sistem notlarından alınır; bu notlar, bir 'atanan' kişi eklendiğinde veya değiştirildiğinde
Yakala
Sorunun sistem notlarından 'atanan değişti' olaylarını çıkarın.
Event tipi
explicit
|
|||
|
Sorun Kapatıldı
|
İş öğesinin, değişiklikleri dağıtıldıktan ve doğrulandıktan sonraki son idari kapanışını temsil eder. Bu, bir kullanıcının GitLab'de sorunu kapattığında yakalanan açık bir olaydır. | ||
|
Neden önemli
Bir sorunu kapatmak genellikle ilgili tüm işlerin sonunu işaret eder. Bunu dağıtım zamanıyla karşılaştırmak, dağıtım sonrası doğrulama veya idari süreçlerdeki gecikmeleri ortaya çıkarabilir.
Nereden alınır
Bu, 'issues' tablosundaki 'closed_at' zaman damgasından veya ilgili sistem notundan yakalanan açık bir olaydır.
Yakala
Issue'nun 'closed_at' zaman damgasını kullanın.
Event tipi
explicit
|
|||