Yazılım Geliştirme Yaşam Döngüsü Veri Template'inuz

GitLab
Yazılım Geliştirme Yaşam Döngüsü Veri Template'inuz

Yazılım Geliştirme Yaşam Döngüsü Veri Template'inuz

Bu detaylı şablon, Yazılım Geliştirme Yaşam Döngüsü sürecinizi analiz etmek için gereken temel veri noktalarında size rehberlik. eder. Toplanması gereken kritik nitelikleri, izlenecek temel aktiviteleri özetler ve bu bilgileri doğrudan GitLab'den çıkarmak için pratik rehberlik. sunar. Bu kaynakla, verilerinizi anlamlı süreç madenciliği için güvenle hazırlayabilirsiniz.
  • Önerilen Öznitelikler
  • İzlenecek Temel Etkinlikler
  • Veri Çekim Kılavuzu
Olay günlüklerine (Event Log) yeni mi başlıyorsunuz? Öğrenin Process Mining event log nasıl oluşturulur.

Yazılım Geliştirme Yaşam Döngüsü Öznitelikleri

Bunlar, detaylı yazılım geliştirme süreç döngüsü analizi ve optimizasyonu için event lognüze dahil etmeniz önerilen veri alanlarıdır.
3 Gerekli 5 Önerilen 12 Opsiyonel
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ı (zaman damgası) alanlarından türetilir. Örneğin, bir sorunun oluşturulması, bir commit'in gönderilmesi, bir veri hattı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 büyük önem taşır. Sapmaları, adımlar arasındaki darboğazları ve ortak süreç yollarını belirlemek için kullanılır.

Neden Önemli?dir?

Süreç haritasındaki adımları tanımlar, uçtan uca geliştirme iş akışının görselleştirilmesine ve analiz edilmesine sunar.

Nereden Alınır??

GitLab'in olay akışındaki event türlerinden ve durum değişikliklerinden veya Sorunlar (Issues) ve Birleştirme İstekleri (Merge Requests) üzerindeki 'created_at', 'merged_at' ve 'closed_at' gibi zaman damgası (zaman damgası) alanlarını yorumlayarak türetilmiştir.

Örnekler:::::::
Sorun OluşturulduGeliştirme BaşlatıldıBirleştirme İsteği BirleştirildiPipeline Başarısız OlduProd Ortamına Yayınlandı
Başlangıç Zamanı
StartTime
Bir etkinlik veya olayın ne zaman başladığını gösteren zaman damgası (zaman damgası) (zaman damgası (zaman damgası)).
Açıklama

StartTime, belirli bir faaliyetin meydana geldiği kesin tarihi ve saati işaretler. GitLab'deki olaylar için bu, çeşitli zaman damgası (zaman damgası) alanlarında yakalanır. Örneğin, 'Sorun Oluşturuldu' aktivitesinin StartTime'ı sorunun created_at zaman damgası (zaman damgası) olurken, 'Birleştirme İsteği Birleştirildi' aktivitesinin StartTime'ı birleştirme isteğinin merged_at zaman damgası (zaman damgası) olacaktır.

Bu zaman damgası (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?dir?

Bu öznitelik, tüm zaman tabanlı metrikleri hesaplamak ve süreç akışını anlamak için temel olan kronolojik olay dizisini sunar.

Nereden Alınır??

GitLab'deki çeşitli zaman damgası (zaman damgası) alanlarından, örneğin sorunlardaki 'created_at', 'updated_at', 'closed_at' ve birleştirme isteklerindeki 'merged_at' alanlarından çıkarılmıştır.

Ö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 (case) tanımlayıcısı olarak hizmet verir.
Açıklama

Geliştirme Öğesi, yazılım geliştirme süreç 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ü sunar. İşin konseptten prodüksiyona ne kadar verimli bir şekilde teslim edildiğini anlamanın temelini oluşturur.

Neden Önemli?dir?

Bu, tüm süreç olaylarını birbirine bağlayan temel vaka (case) tanımlayıcısıdır ve herhangi bir iş öğesinin tam süreç döngüsünü izlemeyi sunar.

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 assignee veya assignees alanında yakalanır.

Atanana göre analiz, 'Geliştirici İş Yükü ve Tahsisi' kontrol paneli'u için büyük önem taşır. 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?dir?

İşi kimin yaptığını takip ederek iş yükü analizi, kaynak tahsis verimliliği ve el değiştirmelerden kaynaklanan gecikmelerin tespit edilmesini sunar.

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ş Zamanı
EndTime
Bir aktivitenin veya olayın ne zaman tamamlandığını gösteren zaman damgası (zaman damgası)dır.
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ı (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 büyük önem taşır. 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?dir?

Süreçteki verimsiz adımları belirlemede anahtar olan kesin etkinlik sürelerinin (işleme süreleri) hesaplanmasını sunar.

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 sunar. Ö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?dir?

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şleştirme mantığına ihtiyaç vardır.

Örnekler:::::::
ÖzellikHataGörevTeknik Borç
Önem Derecesi
Severity
Geliştirme öğesinin önem derecesi, genellikle hatalar veya olaylar için.
Açıklama

Önem derecesi, kritikten düşü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 büyük önem taşır. 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?dir?

İş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
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 sunar. Belirli projelerin diğerlerinden daha sağlıklı SDLC süreçlerine sahip olup olmadığını belirlemeye yardımcı olabilir ve panelleri belirli bir ilgi alanına göre filtrelemek için kullanışlıdır.

Neden Önemli?dir?

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
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?dir?

Farklı kişiler veya ekipler arasındaki devirler sırasındaki boşta kalma süresini ölçülmesini sağlar, gizli gecikmeleri ve iletişim darboğazlarını ortaya çıkarır.

Nereden Alınır??

Process Mining aracı tarafından hesaplanır. Bir case içindeki ardışık olayları analiz etmeyi, 'Atanan' kişinin farklı olup olmadığını kontrol etmeyi ve ardından zaman farkını hesaplamayı gerektirir.

Ö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 büyük önem taşır. 'Kod İnceleme Döngü Süresi ve Verimlilik' gibi panelleri doğrudan destekler ve MR oluşturma, inceleme, onay ve birleştirme arasındaki gecikmeleri belirlemeye yardımcı olur.

Neden Önemli?dir?

Kod inceleme ve birleştirme sürecine görünürlük sunar, 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:::::::
openedbirleştirildikapalı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 case'in toplam süresini ölçen hesaplanmış bir metriktir. Genellikle tek bir Development Item için ilk olay ('Sorun Oluşturuldu' gibi) ile en son olay ('Üretime Dağıtıldı' gibi) arasındaki zaman farkı olarak hesaplanır.

Bu, genel süreç verimliliğini ölçmek için birincil bir KPI'dır. 'SDLC Uçtan Uca Döngü Süresi' gibi kontrol paneli'larda anahtar metriktir ve iyileştirmeleri izlemek ve sistemik sorunları gösterebilecek uzun süreli case'leri belirlemek için kullanılır.

Neden Önemli?dir?

Bu, geliştirme süreç 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 StartTime'dan minimum StartTime çıkarılarak hesaplanır.

Ö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 nitelik, o dönüm noktasının adını veya başlığını yakalar.

Bu nitelik, belirli sprint'ler veya planlama dönemleri bağlamında süreç performansının analiz edilmesini sunar. Döngü sürelerinin bir sprint'ten diğerine iyileşip iyileşmediğini görmek veya süreç görünümünü yalnızca yaklaşan bir sürümle ilgili işi gösterecek şekilde filtrelemek için kullanılabilir.

Neden Önemli?dir?

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 sunar.

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?dir?

Farklı ekipler arasında performans analizi ve süreç karşılaştırması yapılmasına sunar, ekip bazında darboğazları veya en iyi uygulamaları belirlemeye yardımcı olur.

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-Enerji ve AltyapıiPlatform-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 state'i vardır. Daha ayrıntılı durumlar genellikle detaylı etiketler (örneğin, 'Durum::Triage', 'Durum::Geliştirmede', 'Durum::İncelemede') kullanılarak yönetilir.

Durum değişikliklerini izlemek, vaka süreç döngüsünü anlamak için büyük önem taşır. Öğelerin her durumda ne kadar zaman geçirdiğini belirlemeye yardımcı olur ve 'SDLC Uçtan Uca Döngü Süresi' gibi kontrol paneli'larda aktif veya tamamlanmış işleri filtrelemek için kullanılabilir.

Neden Önemli?dir?

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ı sunar.

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?dir?

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
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 büyük önem taşır. Filtreleme, segmentasyon sunar ve veri kökenini korumaya yardımcı olur.

Neden Önemli?dir?

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ışanşı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ışanştırma Analizi' kontrol paneli'u için büyük önem taşır. 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 temel rol oynar.

Neden Önemli?dir?

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:::::::
başarılıbaş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ı (zaman damgası)dır.
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 büyük önem taşır. Kullanıcıların panellerin 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?dir?

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ı (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' kontrol paneli'u için büyük önem taşır. 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?dir?

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 büyük önem taşır.

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 değeri.
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ışanştırma Analizi' kontrol paneli'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?dir?

Yeniden işi doğrudan işaretler ve ölçülmesini sunar, 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 case için etkinlik dizisi analiz edilerek ve yeniden işi gösteren kalıplar belirlenerek hesaplanır.

Örnekler:::::::
truefalse
Gerekli Önerilen Opsiyonel

Yazılım Geliştirme Yaşam Döngüsü Faaliyetleri

Bunlar, doğru Process Discovery ve darboğaz tespiti için event lognuza dahil etmeniz gereken temel süreç adımları ve kilometre taşlarıdır.
4 Önerilen 8 Opsiyonel
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?dir?

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 olarak kullanılır.

Nereden Alınır??

Bu, 'merge_requests' tablosundaki 'merged_at' zaman damgası (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ı (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?dir?

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ı (zaman damgası)ndan veya Merge Requests API aracılığıyla yakalanan açık bir olaydır.

Yakala

Merge request'in 'created_at' zaman damgası (zaman damgası)nı kullanın.

Event tipi explicit
Prod Ortamına Yayınlandı
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ı sunar. Bu, bir GitLab CI/CD veri hattında belirli bir 'üretim ortamına dağıt' görevinin başarıyla tamamlanmasıyla yakalanır.
Neden Önemli?dir?

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 büyük önem taşır.

Nereden Alınır??

Özellikle üretim dağıtımı için belirlenmiş başarılı bir CI/CD işinin 'finished_at' zaman damgası (zaman damgası)'ından alınır. GitLab'in Ortamlar (Environments) özelliği bunu açıkça izler.

Yakala

Başarılı bir üretim dağıtımı CI işindeki 'finished_at' zaman damgası (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 süreç 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ı (zaman damgası)nı kaydeder.
Neden Önemli?dir?

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 sunar.

Nereden Alınır??

Bu, 'issues' tablosundaki 'created_at' zaman damgası (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ı (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 veri hattı içindeki bir 'deploy' görevinin başlangıcına karşılık gelir.
Neden Önemli?dir?

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 iyileştirmek için büyük önem taşır.

Nereden Alınır??

Dağıtım işi olarak yapılandırılmış bir CI/CD işinin 'started_at' zaman damgası (zaman damgası)'ından alınır. Bu, GitLab'in Ortamlar (Environments) ve Dağıtımlar (Deployments) özelliğinin bir parçasıdır.

Yakala

Bir dağıtım görevi için CI iş günlüğündeki 'started_at' zaman damgası (zaman damgası)nı kullanın.

Event tipi explicit
Geliştirme Başlatıldı
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?dir?

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 sunar.

Nereden Alınır??

Soruna bağlı bir özellik dalındaki ilk commit'in zaman damgası (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ı (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?dir?

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ı (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ı (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?dir?

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 uyumluluk sunar.

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 event logndeki zaman damgası (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 veri hattın son durumunu açıkça kaydeder ve hataların kolayca belirlenmesini sunar.
Neden Önemli?dir?

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ı (zaman damgası), hatanın ne zaman meydana geldiğini gösterir.

Yakala

Hatalı' durumdaki pipeline kayıtlarını filtreleyin ve 'finished_at' zaman damgası (zaman damgası)nı kullanın.

Event tipi explicit
Pipeline Başladı
Otomatik bir CI/CD veri hattı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ı (zaman damgası)yla bir pipeline kaydı oluşturur.
Neden Önemli?dir?

Pipeline yürütmelerini takip etmek, otomatik test ve entegrasyon süreçlerinin sağlığını ve verimliliğini izlemek için büyük önem taşır. Otomatik doğrulama işlemlerinde ne kadar zaman harcandığını belirlemeye yardımcı olur.

Nereden Alınır??

'ci_pipelines' tablosundaki bir pipeline kaydının 'created_at' veya 'started_at' zaman damgası (zaman damgası)'ından veya Pipelines API'si aracılığıyla alınır.

Yakala

MR'ın dalıyla ilişkili pipeline yürütme kaydındaki zaman damgası (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?dir?

Atamaları takip etmek, kaynak tahsisi, ekip iş yükü ve devir sürelerini analiz etmek için büyük önem taşır. İş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 log tutar. Olay zaman damgası (zaman damgası)'ı nota kaydedilir.

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?dir?

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ı (zaman damgası)ndan veya ilgili sistem notundan yakalanan açık bir olaydır.

Yakala

Issue'nun 'closed_at' zaman damgası (zaman damgası)nı kullanın.

Event tipi explicit
Önerilen Opsiyonel

Veri Çıkarma Kılavuzları

Verilerinizi GitLab'den Nasıl Alırsınız?