Yazılım Geliştirme Yaşam Döngüsü Veri Template'inuz
Yazılım Geliştirme Yaşam Döngüsü Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Veri Çekim Kılavuzu
Yazılım Geliştirme Yaşam Döngüsü Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
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
Ö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 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 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
Ö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 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?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
Ö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?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 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
Örnekler:::::::
truefalse
|
|||
Yazılım Geliştirme Yaşam Döngüsü Faaliyetleri
| 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
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
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
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
|
|||