Templat data siklus pengembangan perangkat lunak Anda

GitLab
Templat data siklus pengembangan perangkat lunak Anda

Templat data siklus pengembangan perangkat lunak Anda

Templat ini memandu Anda menyiapkan data penting untuk menganalisis proses siklus pengembangan perangkat lunak. Templat ini menjelaskan atribut yang perlu dikumpulkan, aktivitas utama yang perlu dilacak, serta cara praktis mengambil data langsung dari GitLab. Gunakan panduan ini untuk menyiapkan data bagi analisis process mining.
  • Atribut yang disarankan untuk dikumpulkan
  • Aktivitas utama yang perlu dilacak
  • Panduan ekstraksi data
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut siklus pengembangan perangkat lunak

Berikut kolom data yang disarankan untuk disertakan dalam log peristiwa agar Anda dapat menganalisis dan mengoptimalkan siklus pengembangan perangkat lunak.
3 Wajib 5 Disarankan 12 Opsional
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 created_at pada issue, sedangkan StartTime untuk aktivitas 'Merge request digabungkan' adalah timestamp merged_at pada merge request.

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 assignee atau assignees di Issue atau Merge Request.

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 state dengan nilai 'opened' atau 'closed'. Status yang lebih terperinci biasanya dikelola menggunakan label dengan cakupan tertentu, misalnya 'Status::Triage', 'Status::In-Dev', atau 'Status::In-Review'.

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
Wajib Disarankan Opsional

Aktivitas siklus pengembangan perangkat lunak

Berikut langkah proses dan milestone utama yang perlu dicatat dalam log peristiwa agar proses dapat ditemukan secara akurat dan hambatan teridentifikasi.
4 Disarankan 8 Opsional
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
Disarankan Opsional

Panduan ekstraksi data

Cara mengambil data dari GitLab

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.

Mulai uji coba gratis

Tidak perlu kartu kredit. Mulai optimalkan proses sekarang.