Templat data siklus pengembangan perangkat lunak Anda
Templat data siklus pengembangan perangkat lunak Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data
Atribut siklus pengembangan perangkat lunak
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
Activity
|
Nama langkah proses atau peristiwa tertentu yang terjadi, seperti 'Issue dibuat' atau 'Merge request digabungkan'. | ||
|
Deskripsi
Atribut Aktivitas mencatat peristiwa berbeda yang terjadi pada item pengembangan. Peristiwa ini tidak tersimpan dalam satu kolom di GitLab, tetapi diturunkan dari berbagai tindakan dan kolom timestamp pada Issues, Merge Requests, dan CI/CD Pipelines. Contohnya, pembuatan issue, pengiriman commit, kegagalan pipeline, atau persetujuan merge request merupakan aktivitas yang berbeda. Atribut ini menjadi dasar untuk menyusun peta proses, memvisualisasikan alur kerja, serta menganalisis urutan dan frekuensi peristiwa. Atribut ini digunakan untuk menemukan penyimpangan, hambatan antar langkah, dan jalur proses yang umum.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam peta proses, sehingga alur kerja pengembangan dari awal hingga akhir dapat divisualisasikan dan dianalisis.
Sumber data
Data diturunkan dari jenis peristiwa dan perubahan status dalam aliran peristiwa GitLab, atau dengan menafsirkan kolom timestamp seperti 'created_at', 'merged_at', dan 'closed_at' pada Issues dan Merge Requests.
Contoh
Issue dibuatPengembangan dimulaiMerge request digabungkanPipeline gagalDiterapkan ke produksi
|
|||
|
Item pengembangan
DevelopmentItem
|
Pengenal unik untuk satu unit pekerjaan, seperti fitur, perbaikan bug, atau tugas. Pengenal ini berfungsi sebagai ID kasus utama. | ||
|
Deskripsi
Item pengembangan mewakili satu pekerjaan yang dapat dilacak sepanjang siklus pengembangan perangkat lunak. Item ini menghubungkan semua aktivitas terkait, dari pembuatan hingga penerapan akhir, dalam satu kasus yang utuh. Di GitLab, item ini biasanya diwakili oleh ID internal Issue (IID), yang unik dalam satu proyek. Analisis berdasarkan item pengembangan memungkinkan pengukuran waktu siklus dari awal hingga akhir, identifikasi hambatan, dan pemeriksaan kesesuaian proses. Ini menjadi dasar untuk memahami seberapa efisien pekerjaan diselesaikan, dari konsep hingga produksi.
Mengapa ini penting
Ini adalah pengenal kasus utama yang menghubungkan semua peristiwa proses, sehingga seluruh siklus hidup item kerja dapat ditelusuri.
Sumber data
Biasanya, ini adalah ID internal (IID) GitLab Issue. Nilainya tersedia pada kolom 'iid' dalam respons Issues API.
Contoh
1024512PRJ-2345
|
|||
|
Waktu mulai
StartTime
|
Timestamp yang menunjukkan kapan suatu aktivitas atau peristiwa dimulai. | ||
|
Deskripsi
StartTime menunjukkan tanggal dan waktu tepat terjadinya aktivitas tertentu. Untuk peristiwa di GitLab, waktunya tercatat dalam berbagai kolom timestamp. Contohnya, StartTime untuk aktivitas 'Issue dibuat' adalah timestamp Timestamp ini menjadi unsur waktu utama dalam process mining. Data ini digunakan untuk mengurutkan peristiwa secara kronologis, menghitung durasi antaraktivitas, mengukur waktu siklus, dan menganalisis kinerja proses dari waktu ke waktu.
Mengapa ini penting
Atribut ini menunjukkan urutan kronologis peristiwa, yang penting untuk menghitung semua metrik berbasis waktu dan memahami alur proses.
Sumber data
Data diambil dari berbagai kolom timestamp di GitLab, seperti 'created_at', 'updated_at', dan 'closed_at' pada issue, serta 'merged_at' pada merge request.
Contoh
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Jenis item pengembangan
DevelopmentItemType
|
Klasifikasi item pengembangan, seperti 'Fitur', 'Bug', 'Tugas', atau 'Pemeliharaan'. | ||
|
Deskripsi
Atribut ini mengelompokkan jenis pekerjaan yang dilakukan. Di GitLab, pengelompokan ini biasanya diterapkan menggunakan label pada issue. Tim menggunakan label untuk membedakan fungsi baru, perbaikan cacat, utang teknis, dan jenis pekerjaan lainnya. Analisis berdasarkan jenis item pengembangan memungkinkan perbandingan alur proses dan waktu siklus untuk berbagai jenis pekerjaan. Misalnya, Anda dapat menganalisis apakah bug diperbaiki lebih cepat daripada pengembangan fitur, atau apakah tugas utang teknis mengikuti proses peninjauan yang berbeda.
Mengapa ini penting
Pengelompokan proses berdasarkan jenis pekerjaan membantu menemukan jenis pekerjaan yang lebih rentan mengalami keterlambatan, pekerjaan ulang, atau penyimpangan.
Sumber data
Biasanya, atribut ini diturunkan dari 'labels' yang diterapkan pada GitLab Issue. Logika pemetaan diperlukan untuk mengubah label tertentu menjadi jenis standar.
Contoh
FiturBugTugasUtang teknis
|
|||
|
Nama proyek
ProjectName
|
Nama proyek GitLab tempat item pengembangan berada. | ||
|
Deskripsi
Atribut ini menunjukkan repositori kode atau proyek tertentu tempat pekerjaan dilakukan. Di GitLab, setiap issue dan merge request berada dalam sebuah proyek. Analisis berdasarkan nama proyek memungkinkan perbandingan kinerja berbagai produk, komponen, atau layanan. Analisis ini dapat menunjukkan apakah proses SDLC di proyek tertentu berjalan lebih baik daripada proyek lain. Atribut ini juga berguna untuk memfilter dashboard agar hanya menampilkan area yang diinginkan.
Mengapa ini penting
Atribut ini memungkinkan analisis proses dikelompokkan berdasarkan produk, aplikasi, atau komponen, sehingga upaya perbaikan dapat diarahkan ke area tertentu.
Sumber data
Data diambil dari kolom 'name' atau 'path_with_namespace' pada Project API, yang dihubungkan melalui 'project_id' pada Issues dan Merge Requests.
Contoh
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Penerima tugas
Assignee
|
Pengguna yang ditugaskan pada issue atau merge request saat peristiwa terjadi. | ||
|
Deskripsi
Penerima tugas adalah developer atau pengguna yang bertanggung jawab atas item kerja pada tahap tertentu dalam proses. Di GitLab, informasi ini tercatat pada kolom Analisis berdasarkan penerima tugas penting untuk dashboard 'Beban kerja dan alokasi developer'. Analisis ini membantu memahami pemanfaatan sumber daya, menemukan individu atau tim yang kelebihan beban, dan menganalisis serah terima antarorang.
Mengapa ini penting
Atribut ini mencatat siapa yang mengerjakan tugas, sehingga beban kerja dan efisiensi alokasi sumber daya dapat dianalisis, serta keterlambatan akibat serah terima dapat ditemukan.
Sumber data
Data diambil dari kolom 'assignee.username' atau 'assignees' dalam respons GitLab Issues API dan Merge Requests API.
Contoh
jdoeasmithr.williams
|
|||
|
Tingkat keparahan
Severity
|
Tingkat keparahan item pengembangan, biasanya untuk bug atau insiden. | ||
|
Deskripsi
Tingkat keparahan menunjukkan dampak bug atau masalah, dari kritis hingga ringan. GitLab tidak menyediakan kolom tingkat keparahan bawaan, sehingga informasi ini hampir selalu diterapkan menggunakan label, misalnya 'severity::1' atau 'severity::2'. Atribut ini penting untuk dashboard 'Tren eskalasi tingkat keparahan' dan KPI terkait. Analisis perubahan tingkat keparahan sepanjang siklus hidup dapat menunjukkan masalah yang awalnya dianggap kurang serius atau proses yang memperburuk masalah.
Mengapa ini penting
Atribut ini membantu menentukan prioritas pekerjaan dan menganalisis apakah item dengan tingkat keparahan tinggi ditangani lebih cepat. Pelacakan perubahan mendukung KPI 'Frekuensi eskalasi tingkat keparahan'.
Sumber data
Atribut ini diturunkan dari 'labels' yang diterapkan pada GitLab Issue. Pemetaan diperlukan untuk menafsirkan label seperti 'S1' dan 'S2' sebagai tingkat keparahan.
Contoh
1 - Kritis2 - Tinggi3 - Sedang4 - Rendah
|
|||
|
Waktu selesai
EndTime
|
Timestamp yang menunjukkan kapan suatu aktivitas atau peristiwa selesai. | ||
|
Deskripsi
EndTime menunjukkan tanggal dan waktu tepat saat suatu aktivitas selesai. Untuk banyak peristiwa atomik di GitLab, seperti 'Issue dibuat', EndTime sama dengan StartTime. Untuk aktivitas yang memiliki durasi, seperti 'Peninjauan kode', EndTime menunjukkan waktu penyelesaian, misalnya saat persetujuan terakhir diberikan. Atribut ini penting untuk menghitung durasi setiap aktivitas secara akurat (waktu pemrosesan). Atribut ini juga membantu analisis hambatan secara terperinci dengan membedakan waktu kerja aktif dari waktu tunggu antar tugas.
Mengapa ini penting
Atribut ini memungkinkan penghitungan durasi aktivitas secara akurat (waktu pemrosesan), yang penting untuk menemukan langkah proses yang tidak efisien.
Sumber data
Untuk peristiwa atomik, nilainya sama dengan StartTime. Untuk aktivitas berdurasi, nilainya perlu diturunkan dengan mencari peristiwa penyelesaian yang sesuai dalam data.
Contoh
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Apakah Pengerjaan Ulang
IsRework
|
Penanda boolean yang menunjukkan apakah suatu aktivitas merupakan bagian dari siklus pengerjaan ulang. | ||
|
Deskripsi
Atribut hasil perhitungan ini menandai aktivitas yang menunjukkan langkah mundur dalam proses, misalnya kembali ke tahap pengembangan setelah pengujian dimulai. Logika penanda ini biasanya mendeteksi urutan aktivitas tertentu, seperti peristiwa 'Pengembangan Dimulai' yang terjadi setelah peristiwa 'Pipeline Gagal' atau 'Pengujian QA Dimulai' untuk kasus yang sama. Atribut ini menjadi dasar bagi dasbor 'Analisis Pengerjaan Ulang dan Eksekusi Ulang' serta KPI 'Tingkat Pengerjaan Ulang Setelah Pengujian'. Anda dapat memfilter dan menghitung pengerjaan ulang dengan mudah untuk memahami frekuensi, penyebab, dan dampaknya terhadap jadwal proyek.
Mengapa ini penting
Menandai dan menghitung pengerjaan ulang secara langsung, sehingga penyebab dan dampak inefisiensi proses serta masalah kualitas lebih mudah dianalisis.
Sumber data
Dihitung oleh alat process mining dengan menganalisis urutan aktivitas setiap kasus dan menemukan pola yang menunjukkan pengerjaan ulang.
Contoh
truefalse
|
|||
|
Branch Tujuan
TargetBranch
|
Nama branch tujuan untuk merge request. | ||
|
Deskripsi
Branch Tujuan adalah branch tempat perubahan akan digabungkan, misalnya 'main', 'develop', atau branch rilis seperti 'release/1.5'. Informasi ini merupakan bagian penting dari setiap Merge Request. Analisis berdasarkan Branch Tujuan dapat menunjukkan perbedaan proses penggabungan kode ke berbagai tujuan. Misalnya, penggabungan ke 'main' mungkin memerlukan proses persetujuan yang lebih ketat dan waktu siklus yang lebih lama dibandingkan penggabungan ke branch fitur. Data ini juga membantu membedakan penerapan ke produksi dari jenis integrasi kode lainnya.
Mengapa ini penting
Membantu membedakan alur kerja pengembangan dan rilis, karena proses dapat sangat berbeda bergantung pada branch tujuan.
Sumber data
Diambil dari kolom 'target_branch' pada respons GitLab Merge Requests API.
Contoh
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
Judul Milestone
MilestoneTitle
|
Judul milestone atau sprint yang menjadi tempat item pengembangan ditugaskan. | ||
|
Deskripsi
Di GitLab, Milestone digunakan untuk melacak pekerjaan berdasarkan sasaran atau batas waktu tertentu, seperti sprint atau versi rilis. Atribut ini mencatat nama atau judul milestone tersebut. Atribut ini memungkinkan Anda menganalisis kinerja proses dalam konteks sprint atau periode perencanaan tertentu. Anda dapat melihat apakah waktu siklus membaik dari satu sprint ke sprint berikutnya, atau memfilter tampilan proses agar hanya menampilkan pekerjaan untuk rilis mendatang.
Mengapa ini penting
Menghubungkan pekerjaan pengembangan dengan siklus perencanaan seperti sprint atau rilis, sehingga kinerja dapat dianalisis berdasarkan batas waktu yang direncanakan.
Sumber data
Diambil dari kolom 'milestone.title' pada respons GitLab Issues API atau Merge Requests API.
Contoh
Rilis Q4-2023Sprint 23.11Fase 1: MVP
|
|||
|
Nama tim
TeamName
|
Tim pengembangan yang terkait dengan proyek atau penerima tugas. | ||
|
Deskripsi
Nama tim menunjukkan grup atau skuad yang bertanggung jawab atas item pengembangan. Informasi ini biasanya bukan kolom standar di GitLab. Nama tim sering diturunkan dari konvensi penamaan proyek, struktur grup, atau pemetaan penerima tugas ke tim masing-masing menggunakan tabel referensi eksternal. Atribut ini digunakan untuk menganalisis kinerja proses di tingkat tim. Atribut ini membantu membandingkan efisiensi, beban kerja, dan kepatuhan terhadap proses antar tim, serta mendukung dashboard seperti 'Analisis hambatan per tahap' berdasarkan tim.
Mengapa ini penting
Atribut ini memungkinkan analisis kinerja dan perbandingan proses antar tim, sehingga hambatan khusus tim dan praktik terbaik dapat ditemukan.
Sumber data
Biasanya, atribut ini diturunkan dengan memetakan Nama Proyek atau Penerima Tugas ke struktur tim yang ditetapkan di luar GitLab, atau diperkirakan dari hierarki grup GitLab.
Contoh
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Timestamp yang menunjukkan kapan data untuk peristiwa ini terakhir diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu terakhir kali data peristiwa diekstrak atau diperbarui dalam dataset process mining. Waktu ini bukan waktu terjadinya peristiwa, melainkan waktu terakhir catatan peristiwa disinkronkan. Informasi ini penting untuk mengetahui kebaruan data dan memastikan analisis proses menggunakan data yang tepat waktu. Informasi ini membantu pengguna memastikan dashboard dan KPI menggunakan data terbaru, sekaligus menunjukkan kemungkinan jeda antara sistem sumber dan analisis.
Mengapa ini penting
Atribut ini menjelaskan kebaruan data agar pengguna mengetahui seberapa mutakhir analisis proses.
Sumber data
Timestamp ini dibuat dan dicatat oleh alat ekstraksi data atau proses ETL saat data diperbarui.
Contoh
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Menunjukkan sistem asal data. | ||
|
Deskripsi
Atribut ini menunjukkan asal data proses. Untuk model data ini, nilainya selalu 'GitLab'. Atribut ini penting di lingkungan yang menggabungkan data proses dari beberapa sistem, misalnya Jira untuk perencanaan dan GitLab untuk pelaksanaan. Atribut ini memungkinkan pemfilteran dan segmentasi, serta membantu menjaga jejak asal data.
Mengapa ini penting
Atribut ini memperjelas asal data, yang penting untuk tata kelola data dan integrasi data dari berbagai sistem perusahaan.
Sumber data
Nilai statis 'GitLab' ini ditambahkan selama proses transformasi data.
Contoh
GitLab
|
|||
|
Status item pengembangan
DevelopmentItemStatus
|
Status item pengembangan saat peristiwa terjadi, seperti 'Terbuka', 'Sedang dikerjakan', atau 'Ditutup'. | ||
|
Deskripsi
Atribut ini menunjukkan status item kerja utama, yang biasanya berupa Issue di GitLab. GitLab Issue memiliki Pelacakan perubahan status penting untuk memahami siklus hidup kasus. Ini membantu mengetahui berapa lama item berada dalam setiap status dan dapat digunakan untuk memfilter pekerjaan yang masih berlangsung atau sudah selesai pada dashboard seperti 'Waktu siklus SDLC dari awal hingga akhir'.
Mengapa ini penting
Atribut ini menunjukkan status kasus, sehingga waktu yang dihabiskan di berbagai tahap dapat dianalisis dan pekerjaan yang masih berlangsung dapat dibedakan dari yang sudah selesai.
Sumber data
Status utama diambil dari kolom 'state' pada GitLab Issue ('opened', 'closed'). Status yang lebih terperinci biasanya diturunkan dari label.
Contoh
terbukaditutupSedang dikerjakanSedang ditinjau
|
|||
|
Status Merge Request
MergeRequestStatus
|
Status Merge Request yang terkait dengan peristiwa, seperti 'Dibuka', 'Digabung', atau 'Ditutup'. | ||
|
Deskripsi
Atribut ini mencatat status Merge Request (MR) saat suatu peristiwa terjadi. MR di GitLab memiliki beberapa status: 'opened', 'closed', 'merged', atau 'locked'. Status ini berbeda dari Status Item Pengembangan secara keseluruhan. Melacak status MR penting untuk menganalisis tahap integrasi kode dalam SDLC. Data ini mendukung dasbor seperti 'Waktu Siklus dan Throughput Tinjauan Kode' serta membantu menemukan jeda antara pembuatan MR, peninjauan, persetujuan, dan penggabungan.
Mengapa ini penting
Memberi gambaran tentang proses peninjauan dan penggabungan kode, yang sering menjadi hambatan penting dalam SDLC.
Sumber data
Diambil dari kolom 'state' pada respons GitLab Merge Requests API.
Contoh
terbukamergedditutuplocked
|
|||
|
Status Pipeline
PipelineStatus
|
Status eksekusi pipeline CI/CD, seperti 'Berhasil', 'Gagal', atau 'Berjalan'. | ||
|
Deskripsi
Atribut ini menunjukkan hasil eksekusi pipeline CI/CD yang terkait dengan commit atau merge request. Status umum di GitLab mencakup 'running', 'pending', 'success', 'failed', 'canceled', dan 'skipped'. Data ini penting untuk dasbor 'Analisis Pengerjaan Ulang dan Eksekusi Ulang'. Kegagalan pipeline yang sering terjadi dapat menyebabkan banyak pengerjaan ulang dan keterlambatan. Menganalisis frekuensi, lokasi, dan dampaknya membantu meningkatkan efisiensi pengembangan dan kualitas kode.
Mengapa ini penting
Melacak keberhasilan dan kegagalan build serta pengujian otomatis, sekaligus menyoroti siklus pengerjaan ulang dan masalah kualitas kode atau otomatisasi pengujian.
Sumber data
Diambil dari kolom 'status' pada respons GitLab CI/CD Pipelines API.
Contoh
successfailedrunningcanceled
|
|||
|
Versi Rilis
ReleaseVersion
|
Tag versi perangkat lunak yang direncanakan atau digunakan untuk penerapan. | ||
|
Deskripsi
Atribut ini menunjukkan rilis perangkat lunak tertentu yang mencakup suatu item pengembangan. Di GitLab, rilis dapat dikaitkan melalui Milestone, tag terlindungi, atau entri di fitur Releases. Atribut ini penting untuk dasbor 'Pelacakan Kepatuhan Jadwal Rilis'. Dengan membandingkan tanggal penerapan aktual dengan tanggal rencana untuk versi rilis, organisasi dapat mengukur ketepatan jadwal dan mencari penyebab keterlambatan rilis.
Mengapa ini penting
Menghubungkan item pengembangan dengan rilis perangkat lunak tertentu. Informasi ini penting untuk melacak progres rilis dan kepatuhan terhadap jadwal.
Sumber data
Sumbernya dapat berupa GitLab Releases, nama tag git, atau judul milestone yang digunakan untuk merencanakan rilis.
Contoh
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
Waktu Siklus
CycleTime
|
Total waktu dari aktivitas pertama hingga aktivitas terakhir untuk suatu item pengembangan. | ||
|
Deskripsi
Waktu Siklus adalah metrik hasil perhitungan yang mengukur total durasi sebuah kasus. Biasanya, metrik ini dihitung dari selisih waktu antara peristiwa pertama, misalnya 'Issue Dibuat', dan peristiwa terakhir, misalnya 'Diterapkan ke Produksi', untuk satu Item Pengembangan. Metrik ini menjadi KPI utama untuk mengukur efisiensi proses secara keseluruhan. Dasbor seperti 'Waktu Siklus SDLC dari Awal hingga Akhir' menggunakannya untuk melacak perbaikan dan menemukan kasus yang berlangsung lama, yang mungkin menandakan masalah sistemik.
Mengapa ini penting
KPI utama process mining ini mengukur efisiensi siklus pengembangan dari awal hingga akhir.
Sumber data
Dihitung oleh alat process mining dengan mengurangi StartTime minimum dari StartTime maksimum untuk setiap CaseId yang unik.
Contoh
10 hari 4 jam23 jam 15 menit35 hari
|
|||
|
Waktu Tunggu Serah Terima
HandoffWaitTime
|
Waktu menganggur yang dihitung di antara dua aktivitas berurutan yang dilakukan oleh penanggung jawab berbeda. | ||
|
Deskripsi
Metrik ini menghitung jeda antara selesainya satu aktivitas dan dimulainya aktivitas berikutnya, khususnya saat penanggung jawabnya berganti. Contohnya, metrik ini mengukur waktu sejak pengembang menyelesaikan pekerjaan hingga peninjau mulai meninjau kode. Metrik ini menjadi ukuran utama untuk KPI 'Rata-rata Waktu Tunggu Serah Terima'. Metrik ini membantu menemukan inefisiensi tersembunyi dalam alokasi sumber daya dan komunikasi antarindividu atau tim, serta menyoroti keterlambatan saat tidak ada pekerjaan aktif.
Mengapa ini penting
Mengukur waktu menganggur saat pekerjaan diserahkan antarorang atau tim, sehingga keterlambatan tersembunyi dan hambatan komunikasi dapat terlihat.
Sumber data
Dihitung oleh alat process mining. Perhitungannya menganalisis peristiwa berurutan dalam satu kasus, memeriksa apakah 'Assignee' berbeda, lalu menghitung selisih waktunya.
Contoh
1 hari 2 jam15 menit8 jam
|
|||
Aktivitas siklus pengembangan perangkat lunak
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Diterapkan ke produksi
|
Aktivitas ini menandai keberhasilan penerapan kode ke lingkungan produksi aktif sehingga tersedia bagi pengguna akhir. Peristiwa ini tercatat saat job khusus 'deploy to production' dalam pipeline CI/CD GitLab berhasil diselesaikan. | ||
|
Mengapa ini penting
Ini adalah peristiwa akhir utama dalam proses, yang menandakan bahwa hasil kerja telah tersedia. Peristiwa ini penting untuk mengukur total waktu siklus SDLC dari awal hingga akhir dan frekuensi rilis.
Sumber data
Data diambil dari timestamp 'finished_at' pada job CI/CD yang berhasil dan khusus ditetapkan untuk penerapan ke produksi. Fitur Environments di GitLab mencatatnya secara eksplisit.
Pengumpulan data
Gunakan timestamp 'finished_at' dari job CI penerapan produksi yang berhasil.
Jenis peristiwa
explicit
|
|||
|
Issue dibuat
|
Aktivitas ini menandai awal siklus pengembangan, yaitu saat item kerja baru seperti fitur, bug, atau tugas dibuat. GitLab mencatatnya secara eksplisit ketika pengguna membuat issue baru, beserta waktu pembuatannya. | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama dalam proses dari awal hingga akhir. Analisis waktu dari pembuatan issue hingga penerapan memberikan gambaran lengkap tentang waktu siklus SDLC.
Sumber data
Peristiwa ini tercatat secara eksplisit melalui timestamp 'created_at' pada tabel 'issues' atau melalui Issues API. Catatan sistem juga mencatat pembuatan issue.
Pengumpulan data
Gunakan timestamp 'created_at' pada issue.
Jenis peristiwa
explicit
|
|||
|
Merge request dibuat
|
Aktivitas ini menunjukkan bahwa pekerjaan pengembangan awal telah selesai dan kode siap ditinjau serta diintegrasikan. Ini adalah peristiwa utama yang tercatat secara eksplisit dalam workflow GitLab, yaitu saat developer membuka merge request (MR) baru. | ||
|
Mengapa ini penting
Ini adalah tonggak penting yang menandai peralihan dari pengembangan ke peninjauan dan pengujian. Peristiwa ini menjadi titik awal untuk menganalisis seluruh siklus peninjauan kode dan pipeline CI/CD.
Sumber data
Peristiwa ini tercatat secara eksplisit melalui timestamp 'created_at' pada tabel 'merge_requests' atau melalui Merge Requests API.
Pengumpulan data
Gunakan timestamp 'created_at' pada merge request.
Jenis peristiwa
explicit
|
|||
|
Merge request digabungkan
|
Aktivitas ini menandai selesainya proses peninjauan dan integrasi kode. Peristiwa ini tercatat secara eksplisit saat pengguna menggabungkan branch merge request ke branch target. | ||
|
Mengapa ini penting
Ini adalah tonggak penting yang menunjukkan bahwa pengembangan dan peninjauan telah selesai. Peristiwa ini menjadi titik akhir pengukuran waktu siklus pengembangan sekaligus titik awal pengukuran waktu hingga penerapan.
Sumber data
Peristiwa ini tercatat secara eksplisit melalui timestamp 'merged_at' pada tabel 'merge_requests'. Catatan sistem juga dibuat saat penggabungan.
Pengumpulan data
Gunakan timestamp 'merged_at' pada merge request.
Jenis peristiwa
explicit
|
|||
|
Issue ditugaskan
|
Aktivitas ini menunjukkan bahwa issue ditugaskan kepada developer atau tim tertentu, sehingga penanggung jawab pekerjaan telah ditetapkan. GitLab mencatat peristiwa ini setiap kali kolom assignee pada issue diisi atau diubah. | ||
|
Mengapa ini penting
Pelacakan penugasan penting untuk menganalisis alokasi sumber daya, beban kerja tim, dan waktu serah terima. Ini membantu menemukan jeda antara saat pekerjaan dibuat dan saat mulai ditangani.
Sumber data
Data diambil dari catatan sistem GitLab untuk issue, yang mencatat kapan 'assignee' ditambahkan atau diubah. Timestamp peristiwa tercatat di dalam catatan tersebut.
Pengumpulan data
Ambil peristiwa 'assignee changed' dari catatan sistem issue.
Jenis peristiwa
explicit
|
|||
|
Issue ditutup
|
Aktivitas ini menunjukkan penutupan administratif akhir item kerja, biasanya setelah perubahannya diterapkan dan diverifikasi. GitLab mencatatnya secara eksplisit saat pengguna menutup issue. | ||
|
Mengapa ini penting
Penutupan issue sering menandai berakhirnya seluruh pekerjaan terkait. Membandingkan waktu penutupan dengan waktu penerapan dapat menunjukkan keterlambatan dalam validasi setelah penerapan atau proses administratif.
Sumber data
Peristiwa ini tercatat secara eksplisit melalui timestamp 'closed_at' pada tabel 'issues' atau melalui catatan sistem terkait.
Pengumpulan data
Gunakan timestamp 'closed_at' pada issue.
Jenis peristiwa
explicit
|
|||
|
Penerapan dimulai
|
Aktivitas ini menandai dimulainya proses untuk merilis kode ke lingkungan tertentu, seperti staging atau produksi. Di GitLab, ini sesuai dengan dimulainya job 'deploy' dalam pipeline CI/CD. | ||
|
Mengapa ini penting
Pelacakan waktu mulai penerapan membantu memisahkan durasi tahap penerapan. Data ini penting untuk mengukur dan mengoptimalkan waktu hingga penerapan.
Sumber data
Data diambil dari timestamp 'started_at' pada job CI/CD yang dikonfigurasi sebagai job penerapan. Fitur Environments and Deployments di GitLab mencatat informasi ini.
Pengumpulan data
Gunakan timestamp 'started_at' dari log job CI untuk tugas penerapan.
Jenis peristiwa
explicit
|
|||
|
Pengembangan dimulai
|
Aktivitas ini menandai dimulainya pekerjaan coding aktif pada issue. Biasanya, waktu ini diperkirakan dari commit kode pertama yang dikirim ke branch terkait issue, karena GitLab tidak menyediakan tombol khusus untuk memulai pengembangan. | ||
|
Mengapa ini penting
Aktivitas ini menunjukkan waktu tepat dimulainya pekerjaan pengembangan yang menghasilkan nilai. Dengan begitu, durasi coding dapat diukur secara akurat dan dipisahkan dari waktu perencanaan atau antrean.
Sumber data
Waktu ini diperkirakan dari timestamp commit pertama pada feature branch yang terhubung dengan issue. Untuk itu, issue perlu dihubungkan ke branch, biasanya melalui konvensi penamaan atau metadata.
Pengumpulan data
Cari timestamp commit pertama pada branch yang terkait dengan ID issue.
Jenis peristiwa
inferred
|
|||
|
Peninjauan kode dimulai
|
Aktivitas ini menandai dimulainya peninjauan oleh rekan sejawat untuk sebuah merge request. Waktunya diperkirakan dari tindakan peninjauan pertama, seperti komentar atau thread pertama yang dibuat oleh orang selain pembuat MR. | ||
|
Mengapa ini penting
Pengukuran waktu dari pembuatan MR hingga peninjauan dimulai menunjukkan jeda antrean. Mengurangi waktu tunggu ini penting untuk mempersingkat keseluruhan siklus peninjauan kode.
Sumber data
Waktunya diperkirakan dari timestamp komentar atau thread peninjauan pertama pada merge request yang dibuat oleh orang selain pembuat MR. Data ini tersedia melalui catatan sistem atau Notes API.
Pengumpulan data
Cari timestamp komentar pertama pada MR dari pengguna selain pembuatnya.
Jenis peristiwa
inferred
|
|||
|
Persetujuan diberikan
|
Aktivitas ini menunjukkan persetujuan resmi dari peninjau atas perubahan kode dalam merge request. GitLab mencatatnya secara eksplisit saat pengguna mengeklik tombol 'Approve'. | ||
|
Mengapa ini penting
Persetujuan menjadi gerbang penting untuk menjaga kualitas. Pelacakannya membantu menganalisis waktu yang diperlukan untuk memperoleh persetujuan wajib dan memastikan kepatuhan terhadap kebijakan peninjauan.
Sumber data
Data diambil dari peristiwa persetujuan merge request. Peristiwa ini tersedia melalui Approvals API atau dapat dilihat dalam riwayat MR.
Pengumpulan data
Gunakan timestamp dari log peristiwa persetujuan merge request.
Jenis peristiwa
explicit
|
|||
|
Pipeline dimulai
|
Aktivitas ini menandai dimulainya pipeline CI/CD otomatis, yang biasanya menjalankan build, pengujian, dan pemindaian keamanan. GitLab membuat catatan pipeline dengan timestamp mulai setiap kali pipeline dipicu, misalnya oleh commit atau pembuatan MR. | ||
|
Mengapa ini penting
Pelacakan eksekusi pipeline penting untuk memantau kesehatan dan efisiensi proses pengujian serta integrasi otomatis. Ini membantu mengetahui waktu yang digunakan untuk validasi otomatis.
Sumber data
Data diambil dari timestamp 'created_at' atau 'started_at' pada catatan pipeline di tabel 'ci_pipelines' atau melalui Pipelines API.
Pengumpulan data
Gunakan timestamp dari catatan eksekusi pipeline yang terkait dengan branch MR.
Jenis peristiwa
explicit
|
|||
|
Pipeline gagal
|
Aktivitas ini terjadi ketika eksekusi pipeline CI/CD gagal pada tahap mana pun, misalnya karena kesalahan build atau pengujian yang gagal. GitLab mencatat status akhir setiap pipeline secara eksplisit, sehingga kegagalan mudah ditemukan. | ||
|
Mengapa ini penting
Kegagalan pipeline sering menyebabkan pekerjaan ulang. Analisis frekuensi, durasi, dan penyebabnya membantu menemukan masalah kualitas, pengujian yang tidak konsisten, serta hambatan dalam siklus umpan balik kepada developer.
Sumber data
Kegagalan dikenali dari status 'failed' pada catatan pipeline di tabel 'ci_pipelines'. Timestamp 'finished_at' menunjukkan waktu terjadinya kegagalan.
Pengumpulan data
Filter catatan pipeline dengan status 'failed', lalu gunakan timestamp 'finished_at'.
Jenis peristiwa
explicit
|
|||
Panduan ekstraksi data
Siap memulai?
Gunakan templat ini untuk menyiapkan data dan mulai mengoptimalkan siklus pengembangan perangkat lunak. Mulai perbaikan proses Anda hari ini.
Tingkatkan siklus pengembangan perangkat lunak Anda: mulai optimalkan sekarang
Atasi hambatan SDLC, kurangi waktu siklus hingga 30%, dan tingkatkan kualitas.
Tidak perlu kartu kredit. Mulai optimalkan proses sekarang.