Templat data siklus pengembangan perangkat lunak Anda

GitHub
Templat data siklus pengembangan perangkat lunak Anda

Templat data siklus pengembangan perangkat lunak Anda

Templat ini memandu Anda mengumpulkan dan menyiapkan data siklus pengembangan perangkat lunak dari GitHub. Di dalamnya, Anda akan menemukan atribut yang disarankan, aktivitas penting untuk dilacak, dan panduan praktis untuk mengekstrak data. Gunakan templat ini untuk membuat log peristiwa yang akurat sebagai dasar analisis dan perbaikan proses.
  • 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 log peristiwa agar Anda dapat menganalisis dan menemukan proses dalam siklus pengembangan perangkat lunak.
3 Wajib 5 Disarankan 15 Opsional
Nama Deskripsi
Aktivitas
ActivityName
Nama peristiwa atau tugas tertentu yang terjadi dalam siklus pengembangan perangkat lunak.
Deskripsi

Nama Aktivitas menjelaskan satu langkah dalam proses pengembangan, seperti 'Issue dibuat', 'Kode dikirim ke PR', 'Pull request disetujui', atau 'Penerapan berhasil'. Peristiwa-peristiwa ini membentuk urutan langkah dalam keseluruhan proses untuk sebuah item pengembangan.

Atribut ini menjadi dasar process mining karena digunakan untuk menyusun peta proses. Dengan menganalisis urutan, frekuensi, dan durasi aktivitas, Anda dapat melihat alur proses yang sebenarnya, menemukan jalur yang umum, menyoroti penyimpangan, dan mengidentifikasi hambatan.

Mengapa ini penting

Atribut ini menjadi dasar peta proses dan membantu memvisualisasikan serta menganalisis urutan peristiwa dalam siklus pengembangan.

Sumber data

Diambil dari kolom 'action' dalam payload peristiwa webhook, misalnya 'opened' atau 'closed' untuk issue, atau dari jenis peristiwanya, misalnya 'PushEvent' atau 'PullRequestReviewEvent'.

Contoh
Issue dibuatPull request dibukaKode dikirim ke PRPeninjauan dimintaPull request digabungkan
Item pengembangan
DevelopmentItemId
Pengenal unik untuk satu unit pekerjaan pengembangan, seperti fitur, perbaikan bug, atau tugas. Pengenal ini berfungsi sebagai ID kasus utama.
Deskripsi

ID Item Pengembangan melacak item pekerjaan sejak dibuat hingga penerapan akhir. ID ini menghubungkan semua aktivitas terkait, seperti pembuatan branch, commit, pull request, peninjauan, dan penerapan, ke dalam satu rangkaian proses.

Dalam analisis, ID ini digunakan untuk menghitung waktu siklus tugas pengembangan dari awal hingga akhir. ID ini membantu merekonstruksi seluruh perjalanan fitur atau perbaikan bug, sehingga Anda dapat menganalisis hambatan, siklus pengerjaan ulang, dan variasi proses untuk setiap item pekerjaan.

Mengapa ini penting

ID ini menjadi kunci utama process mining karena menghubungkan semua peristiwa pengembangan terkait ke dalam satu kasus. Dengan begitu, siklus pengembangan perangkat lunak dari awal hingga akhir dapat divisualisasikan dan dianalisis secara akurat.

Sumber data

Biasanya berupa Nomor Issue atau Nomor Pull Request dari GitHub. Nilainya dapat diambil dari kolom 'number' dalam payload peristiwa webhook atau respons API yang terkait dengan issue atau pull request.

Contoh
101PR-2345TASK-812
Waktu mulai
EventTimestamp
Tanggal dan waktu persis saat aktivitas atau peristiwa pengembangan tertentu terjadi.
Deskripsi

Stempel waktu ini menandai awal suatu aktivitas. Data ini penting untuk mengurutkan peristiwa secara kronologis dan merekonstruksi alur proses setiap item pengembangan. Urutan dan selisih waktu antarstempel waktu digunakan untuk menganalisis kinerja proses.

Dalam analisis, atribut ini diperlukan untuk menghitung semua metrik berbasis waktu, termasuk waktu siklus, waktu pemrosesan, dan waktu tunggu. Atribut ini membantu menemukan keterlambatan antarlangkah dan menyediakan data untuk analisis hambatan serta pemantauan kinerja melalui dasbor.

Mengapa ini penting

Stempel waktu ini penting untuk mengurutkan peristiwa dengan benar dan menghitung semua metrik kinerja, seperti waktu siklus dan durasi hambatan.

Sumber data

Biasanya tersedia dalam kolom 'created_at' atau 'updated_at' pada payload JSON dari GitHub API dan webhook untuk berbagai objek, seperti issue, pull request, dan commit.

Contoh
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Jenis item pengembangan
DevelopmentItemType
Klasifikasi item pekerjaan pengembangan, seperti fitur, bug, tugas, atau epic.
Deskripsi

Atribut ini mengelompokkan jenis pekerjaan yang dilakukan. Informasi ini biasanya dikelola melalui label atau templat issue khusus di GitHub. Memahami jenis pekerjaan penting untuk menetapkan ekspektasi kinerja yang sesuai. Waktu siklus perbaikan bug, misalnya, mungkin jauh lebih singkat daripada pengembangan fitur baru.

Atribut ini memungkinkan perbandingan antarjenis pekerjaan. Anda dapat menganalisis apakah perbaikan bug diproses lebih cepat daripada fitur baru, atau memahami alokasi sumber daya untuk utang teknis dibandingkan pengembangan baru. Atribut ini menjadi dimensi penting dalam dasbor 'Throughput berdasarkan Proyek dan Jenis'.

Mengapa ini penting

Mengelompokkan item pekerjaan agar kinerja dapat dibandingkan dan alur berbagai jenis pekerjaan, seperti bug dan fitur, dapat dianalisis.

Sumber data

Biasanya ditentukan berdasarkan label GitHub pada issue atau pull request. Perlu ada konvensi pelabelan yang konsisten, misalnya 'type:bug' dan 'type:feature'.

Contoh
BugFiturTugasUtang teknis
Pengguna yang ditugaskan
Assignee
Pengguna atau developer yang ditugaskan untuk menangani item pengembangan atau tugas tertentu, seperti peninjauan pull request.
Deskripsi

Atribut ini menunjukkan siapa yang bertanggung jawab atas pekerjaan pada tahap tertentu. Orang tersebut dapat berupa penerima tugas issue, pembuat pull request, atau peninjau yang diminta untuk meninjau kode. Melacak penerima tugas penting untuk memahami alokasi sumber daya dan beban kerja.

Dalam analisis, atribut ini digunakan untuk memantau beban kerja developer, menemukan hambatan terkait sumber daya, dan menganalisis efisiensi serah terima antaranggota tim. Dasbor dapat difilter berdasarkan penerima tugas untuk menilai kinerja individu atau tim dan memastikan pembagian pekerjaan yang seimbang.

Mengapa ini penting

Penting untuk menganalisis beban kerja developer, kinerja tim, dan efisiensi serah terima antaranggota tim.

Sumber data

Tersedia dalam objek 'assignee' atau 'user' pada payload JSON untuk issue, pull request, dan peristiwa peninjauan dari GitHub API.

Contoh
john.doejane.smithdev-team-lead
Prioritas
Priority
Tingkat prioritas yang ditetapkan untuk item pengembangan, seperti 'Tinggi', 'Sedang', atau 'Rendah'.
Deskripsi

Prioritas menunjukkan tingkat urgensi atau kepentingan bisnis suatu item pekerjaan. Di GitHub, prioritas bukan kolom bawaan dan biasanya dikelola menggunakan label, misalnya 'P1-High' atau 'P2-Medium'. Agar informasi ini dapat diambil dengan andal, gunakan skema label yang konsisten.

Atribut ini penting untuk 'Analisis Alur Berdasarkan Prioritas'. Analis dapat memeriksa apakah item berprioritas tinggi benar-benar diproses lebih cepat daripada item berprioritas rendah, serta mengukur variasi waktu siklus menurut prioritas. Informasi ini juga membantu menilai efektivitas proses penentuan prioritas.

Mengapa ini penting

Membantu menganalisis apakah item berprioritas tinggi diproses lebih cepat daripada item berprioritas rendah, sekaligus menilai efektivitas strategi penentuan prioritas.

Sumber data

Diambil dari label GitHub pada issue atau pull request. Label prioritas harus mengikuti konvensi yang baku.

Contoh
TinggiSedangRendahKritis
Repositori
RepositoryName
Nama repositori kode tempat aktivitas pengembangan berlangsung.
Deskripsi

Repositori berfungsi sebagai pengenal proyek atau produk. Repositori memuat semua kode, issue, dan pull request untuk aplikasi atau komponen tertentu. Repositori juga membantu membagi dan membandingkan proses pengembangan di berbagai produk atau tim.

Dalam analisis, atribut ini memungkinkan Anda memfilter dan membandingkan kinerja proses di berbagai proyek. Atribut ini membantu menjawab pertanyaan seperti, 'Proyek mana yang memiliki waktu siklus terlama?' atau 'Bagaimana proses perbaikan bug di Proyek A dibandingkan dengan Proyek B?'. Atribut ini penting untuk dasbor 'Throughput berdasarkan Proyek dan Jenis'.

Mengapa ini penting

Memungkinkan proses pengembangan dibagi dan dibandingkan di berbagai proyek, produk, atau tim, sehingga analisis dapat lebih terarah.

Sumber data

Tersedia dalam objek 'repository' di hampir semua payload webhook dan API GitHub. Kolom yang digunakan biasanya 'repository.full_name' atau 'repository.name'.

Contoh
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Waktu selesai
EndTimestamp
Tanggal dan waktu persis saat aktivitas atau peristiwa pengembangan tertentu selesai.
Deskripsi

Stempel waktu akhir menandai selesainya suatu aktivitas. Banyak peristiwa di GitHub terjadi seketika, misalnya 'Issue dibuat', tetapi beberapa aktivitas memiliki durasi yang dapat diukur, seperti pemeriksaan CI yang sedang berjalan. Selisih antara Waktu selesai dan Waktu mulai menunjukkan waktu pemrosesan aktivitas.

Atribut ini digunakan untuk menghitung metrik 'ProcessingTime', yang penting untuk memahami waktu kerja aktif yang digunakan dalam tugas seperti peninjauan kode atau pemeriksaan otomatis. Analisis waktu pemrosesan membantu menemukan aktivitas yang tidak efisien dan memakan terlalu banyak waktu.

Mengapa ini penting

Memungkinkan penghitungan waktu pemrosesan aktivitas secara akurat, sehingga waktu kerja aktif dapat dibedakan dari waktu tunggu.

Sumber data

Dapat ditemukan sebagai 'completed_at' pada objek check run, atau diturunkan dari stempel waktu peristiwa berikutnya yang secara logis menandai penyelesaian.

Contoh
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Apakah pengerjaan ulang
IsRework
Penanda boolean yang bernilai true jika suatu aktivitas menunjukkan proses kembali ke tahap sebelumnya.
Deskripsi

Penanda ini bernilai true saat item pengembangan bergerak mundur dalam proses. Contohnya, pull request mendapat ulasan 'Perubahan diminta' atau issue dibuka kembali setelah ditutup. Nilainya ditentukan dengan menganalisis urutan aktivitas.

Atribut ini penting untuk mengukur pemborosan dan inefisiensi. Atribut ini mendukung dashboard 'Siklus Pengerjaan Ulang dan Regresi' serta KPI 'Tingkat Pengerjaan Ulang'. Dengan memfilter 'IsRework = true', analis dapat memisahkan dan menyelidiki penyebab pengerjaan ulang.

Mengapa ini penting

Menandai aktivitas yang termasuk pengerjaan ulang secara jelas, sehingga penyebab inefisiensi proses mudah diukur, divisualisasikan, dan dianalisis.

Sumber data

Atribut ini diturunkan dari data. Logikanya menetapkan alur proses standar, lalu menandai aktivitas yang menyimpang karena kembali ke tahap logis sebelumnya.

Contoh
truefalse
Hash commit
CommitHash
Pengenal unik (SHA) untuk commit kode tertentu.
Deskripsi

Hash commit adalah hash SHA-1 sepanjang 40 karakter yang menjadi pengenal unik untuk sebuah commit di Git. Hash ini berfungsi sebagai ID permanen untuk versi kode tertentu. Commit adalah unit perubahan terkecil dalam proses pengembangan.

Hash commit memberikan tingkat keterlacakan yang sangat terperinci. Analis dapat menghubungkan peristiwa proses langsung ke perubahan kode yang tepat. Ini sangat berguna untuk audit, kepatuhan, atau analisis akar masalah secara terperinci saat terjadi insiden di production.

Mengapa ini penting

Menghubungkan langkah proses dengan perubahan kode yang tepat secara terperinci, sehingga seluruh jejak perubahan dapat ditelusuri untuk keperluan audit dan debugging.

Sumber data

Tersedia dalam payload peristiwa push ('head_commit.id') atau melalui Commits API untuk pull request atau cabang.

Contoh
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Label
Labels
Daftar tag atau label yang diterapkan pada issue atau pull request untuk pengelompokan.
Deskripsi

Label di GitHub memberi cara fleksibel untuk menambahkan metadata ke issue dan pull request. Label dapat menunjukkan prioritas, jenis pekerjaan, komponen, tim, atau status. Daftar label mentah memberikan konteks yang kaya, tetapi tidak terstruktur.

Atribut seperti Prioritas dan Jenis diturunkan dari label, tetapi menyimpan seluruh daftar label tetap berguna untuk analisis sesuai kebutuhan dan menemukan pola proses lainnya. Anda dapat memfilter dan mengelompokkan kasus secara fleksibel berdasarkan kombinasi label apa pun.

Mengapa ini penting

Menyediakan sumber metadata yang kaya dan fleksibel untuk mengelompokkan item pekerjaan, sehingga analisis berdasarkan berbagai dimensi dapat dilakukan secara mendalam.

Sumber data

Tersedia sebagai array 'labels' dalam payload JSON untuk issue dan pull request dari GitHub API. Setiap item dalam array berupa objek dengan kolom 'name'.

Contoh
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Lingkungan penerapan
DeploymentEnvironment
Lingkungan tujuan penerapan, seperti 'Staging' atau 'Production'.
Deskripsi

Atribut ini menunjukkan tempat kode diterapkan. Melacak penerapan ke berbagai lingkungan penting untuk memahami seluruh siklus, dari pengembangan hingga rilis ke production.

Atribut ini membantu menganalisis subproses penerapan. Anda dapat mengukur waktu yang diperlukan untuk memindahkan kode dari staging ke production dan melacak tingkat keberhasilan penerapan di setiap lingkungan. Informasi ini penting untuk mengetahui kapan item pengembangan benar-benar selesai dan tersedia bagi pengguna.

Mengapa ini penting

Membedakan rilis praproduksi dan production. Ini penting untuk mengukur waktu hingga produk tersedia di pasar dan menganalisis pola penerapan.

Sumber data

Informasi ini diambil dari GitHub Deployments API, yang biasanya dipicu oleh pipeline CI/CD atau otomatisasi lainnya.

Contoh
developmentstagingproduction
Nama cabang
BranchName
Nama cabang Git tempat perubahan kode untuk item pengembangan dibuat.
Deskripsi

Cabang adalah jalur pengembangan terpisah yang dibuat untuk mengerjakan fitur baru atau memperbaiki bug tanpa memengaruhi basis kode utama. Nama cabang sering memuat informasi berguna, seperti nomor issue atau deskripsi singkat pekerjaan.

Analisis nama cabang membantu Anda memahami strategi percabangan dan kepatuhan terhadap konvensi pengembangan. Nama ini juga membantu menghubungkan commit kode tertentu dengan item pengembangan, sehingga aktivitas pengodean terlihat secara utuh.

Mengapa ini penting

Memberi konteks tentang jalur pengembangan tertentu serta membantu menerapkan dan menganalisis strategi percabangan dan konvensi penamaan.

Sumber data

Tersedia dalam kolom 'ref' untuk peristiwa push, atau dalam objek 'head' dan 'base' pada respons API pull request.

Contoh
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Nomor pull request
PullRequestNumber
Pengenal unik untuk pull request yang terkait dengan item pengembangan.
Deskripsi

Pull request (PR) adalah usulan untuk menggabungkan serangkaian perubahan kode ke cabang tertentu. Nomor pull request menghubungkan aktivitas pengembangan, seperti pengiriman kode dan peninjauan, dengan item pengembangan utama atau issue.

ID ini penting untuk melacak integrasi kode dan subproses peninjauan dalam siklus pengembangan yang lebih luas. Anda dapat menganalisis proses peninjauan kode secara terperinci, termasuk durasi peninjauan, siklus pengerjaan ulang yang ditemukan saat peninjauan, dan tingkat penggabungan. ID ini menghubungkan tahap perencanaan (issue) dengan tahap penerapan (PR).

Mengapa ini penting

Menghubungkan issue dengan perubahan kode dan proses peninjauan terkait. Dengan begitu, Anda dapat menganalisis siklus peninjauan kode secara terperinci dan melihat dampaknya terhadap waktu penyelesaian secara keseluruhan.

Sumber data

Tersedia sebagai kolom 'number' dalam objek 'pull_request' pada banyak respons GitHub API, atau sebagai pengenal utama dari Pull Requests API.

Contoh
12345678910
Pembaruan data terakhir
LastDataUpdate
Stempel waktu yang menunjukkan kapan data untuk catatan ini terakhir diperbarui dari sistem sumber.
Deskripsi

Atribut ini mencatat tanggal dan waktu ekstraksi atau pembaruan data terbaru. Atribut ini memberikan informasi tentang seberapa baru data yang dianalisis. Data ini berbeda dari stempel waktu peristiwa, yang mencatat kapan peristiwa bisnis terjadi.

Dalam analisis, kolom ini penting untuk mengetahui seberapa mutakhir tampilan proses. Kolom ini membantu pengguna mengetahui apakah data yang dilihat bersifat real-time atau merupakan rekaman dari waktu tertentu. Informasi ini penting untuk dasbor operasional dan pemantauan.

Mengapa ini penting

Menunjukkan seberapa baru data diperbarui. Informasi ini penting untuk memastikan analisis dan dasbor menggunakan data terkini.

Sumber data

Stempel waktu ini dibuat dan ditambahkan selama proses ekstraksi, transformasi, dan pemuatan data (ETL).

Contoh
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Pembuat
Author
Pengguna yang membuat issue, pull request, atau commit.
Deskripsi

Pembuat adalah orang yang memulai suatu artefak dalam proses pengembangan. Misalnya, pembuat issue adalah orang yang melaporkan bug atau meminta fitur. Pembuat pull request adalah developer yang menulis kodenya.

Dalam analisis, informasi pembuat dapat membantu Anda memahami sumber pekerjaan. Analisis pembuat laporan bug, misalnya, dapat menunjukkan pola yang terkait dengan tim atau fitur tertentu. Anda juga dapat menggabungkan informasi ini dengan penanggung jawab untuk menganalisis pola serah terima.

Mengapa ini penting

Menunjukkan siapa yang memulai suatu item pekerjaan atau perubahan kode. Informasi ini berguna untuk menganalisis sumber pengerjaan ulang, laporan bug, atau permintaan fitur.

Sumber data

Tersedia dalam objek 'user' di objek utama pada respons API untuk issue, pull request, dan commit. Nama kolomnya biasanya 'user.login'.

Contoh
sara.jonesmike.leeautomation-bot
Peninjau
Reviewer
Pengguna yang diminta untuk meninjau kode pada pull request.
Deskripsi

Peninjau adalah developer atau anggota tim yang ditugaskan untuk memeriksa kualitas, ketepatan, dan kesesuaian perubahan kode dengan standar dalam pull request. Satu pull request dapat memiliki beberapa peninjau.

Atribut ini penting untuk menganalisis proses peninjauan kode. Anda dapat mengidentifikasi hambatan yang terkait dengan peninjau tertentu, memahami pembagian beban peninjauan, dan mengukur waktu respons peninjau terhadap permintaan. Atribut ini juga menjadi komponen utama dalam menghitung KPI 'Rata-rata Waktu Siklus Peninjauan Kode'.

Mengapa ini penting

Menunjukkan orang-orang yang terlibat dalam proses penjaminan kualitas. Informasi ini membantu menganalisis beban peninjauan, keterlambatan, dan efisiensi peninjauan kode secara keseluruhan.

Sumber data

Tersedia dalam array 'requested_reviewers' atau objek 'user' pada peristiwa peninjauan pull request dari GitHub API.

Contoh
alex.chenmaria.garciasenior-dev-team
Sistem sumber
SourceSystem
Sistem tempat data proses pengembangan diambil.
Deskripsi

Atribut ini menunjukkan asal data peristiwa. Untuk proses ini, nilainya akan selalu 'GitHub'. Dalam lingkungan yang lebih kompleks, saat aktivitas pengembangan berlangsung di beberapa sistem, misalnya Jira untuk perencanaan, GitHub untuk kode, dan Jenkins untuk penerapan, kolom ini membedakan sumber setiap peristiwa.

Dalam analisis, atribut ini membantu menelusuri asal data untuk validasi dan pemecahan masalah. Atribut ini juga memungkinkan analisis proses yang melibatkan beberapa platform, dengan konteks yang jelas untuk setiap aktivitas.

Mengapa ini penting

Menunjukkan asal data. Informasi ini penting untuk validasi data dan analisis proses yang melibatkan beberapa sistem terintegrasi.

Sumber data

Biasanya, nilai statis ini ditambahkan saat proses ekstraksi, transformasi, dan pemuatan data (ETL) untuk menandai sumber catatan.

Contoh
GitHubGitHub Enterprise
Status item
State
Status terkini issue atau pull request, seperti 'open', 'closed', atau 'merged'.
Deskripsi

Atribut ini menunjukkan status umum item pengembangan. Status issue biasanya 'open' atau 'closed'. Status pull request mencakup 'open', 'closed', dan 'merged'. Informasi ini memberikan gambaran kemajuan item.

Dalam analisis, status digunakan untuk membedakan pekerjaan yang masih berlangsung dari pekerjaan yang sudah selesai. Status ini penting untuk dasbor seperti 'Kemajuan Pengembangan Aktif' yang memantau pekerjaan berjalan. Status juga digunakan untuk menentukan akhir proses. Misalnya, status 'merged' atau 'closed' dapat menandai selesainya suatu kasus.

Mengapa ini penting

Menunjukkan dengan jelas apakah item pekerjaan sedang berlangsung atau sudah selesai. Informasi ini menjadi dasar analisis siklus hidup dan pemantauan pekerjaan aktif.

Sumber data

Tersedia langsung dalam kolom 'state' pada payload JSON untuk issue dan pull request dari GitHub API.

Contoh
openclosedmerged
Status pemeriksaan CI
CiCheckStatus
Status pemeriksaan Continuous Integration (CI) otomatis, seperti 'berhasil' atau 'gagal'.
Deskripsi

Atribut ini menunjukkan hasil build, pengujian, dan pemindaian otomatis pada perubahan kode dalam pull request. Pemeriksaan CI menjadi gerbang kualitas penting dalam alur kerja pengembangan modern.

Analisis atribut ini membantu Anda memahami efektivitas pengujian otomatis. Tingkat kegagalan yang tinggi dapat menunjukkan masalah pada kestabilan kode, rangkaian pengujian, atau lingkungan pengembangan. Atribut ini mendukung aktivitas 'Pemeriksaan CI Berhasil' dan 'Pemeriksaan CI Gagal', serta membantu menganalisis keterlambatan akibat build yang gagal.

Mengapa ini penting

Menunjukkan keberhasilan atau kegagalan gerbang kualitas otomatis. Informasi ini memberi gambaran tentang kualitas kode dan efektivitas pipeline CI.

Sumber data

Diambil dari kolom 'state' atau 'conclusion' pada objek check run atau status melalui GitHub Checks API atau Statuses API.

Contoh
successfailurependingerror
Status peninjauan
ReviewState
Hasil peninjauan kode pada pull request, seperti 'Disetujui' atau 'Perubahan diminta'.
Deskripsi

Atribut ini mencatat keputusan peninjau. Status yang umum antara lain 'APPROVED', yang berarti kode siap digabungkan, dan 'CHANGES_REQUESTED', yang berarti kode perlu dikerjakan ulang. Status lainnya dapat berupa 'COMMENTED' atau 'PENDING'.

Atribut ini penting untuk menganalisis pengerjaan ulang dan kualitas. Jika 'CHANGES_REQUESTED' sering muncul, kualitas kode awal mungkin bermasalah atau persyaratannya kurang jelas. Atribut ini mendukung dashboard 'Siklus Pengerjaan Ulang dan Regresi' dengan menunjukkan kapan item pengembangan dikembalikan untuk diperbaiki.

Mengapa ini penting

Menunjukkan secara langsung siklus pengerjaan ulang dan gerbang kualitas dalam proses peninjauan kode. Informasi ini membantu menemukan sumber inefisiensi dan masalah kualitas.

Sumber data

Tersedia dalam kolom 'state' pada objek peninjauan pull request dari GitHub API, misalnya dalam payload 'PullRequestReviewEvent'.

Contoh
APPROVEDCHANGES_REQUESTEDCOMMENTED
Waktu siklus pengembangan
DevelopmentCycleTime
Total waktu sejak item pengembangan dibuat hingga akhirnya diterapkan atau ditutup.
Deskripsi

Metrik tingkat kasus ini dihitung dari selisih waktu antara peristiwa pertama, misalnya 'Issue Dibuat', dan peristiwa terakhir, misalnya 'Penerapan Berhasil' atau 'Issue Ditutup', untuk satu item pengembangan.

Metrik ini termasuk KPI terpenting untuk mengukur efisiensi proses pengembangan secara keseluruhan. Metrik ini mendukung dashboard 'Waktu Siklus Pengembangan Keseluruhan' dan KPI 'Rata-rata Waktu Siklus Pengembangan'. Mengurangi nilai metrik ini sering menjadi sasaran utama inisiatif perbaikan proses.

Mengapa ini penting

Menunjukkan waktu dari awal hingga produk tersedia di pasar untuk suatu item pengembangan. Karena itu, metrik ini menjadi KPI penting untuk mengukur kecepatan dan efisiensi proses secara keseluruhan.

Sumber data

Dihitung pada tingkat kasus dengan mengurangi stempel waktu aktivitas pertama dari stempel waktu aktivitas terakhir.

Contoh
P5DT6H30MP14DT12HP1DT2H
Waktu tunggu serah terima
HandoffWaitingTime
Waktu menganggur yang dihitung saat item pengembangan menunggu di antara aktivitas yang dilakukan oleh orang berbeda.
Deskripsi

Metrik ini mengukur waktu antara selesainya satu aktivitas dan dimulainya aktivitas berikutnya, tetapi hanya jika penanggung jawabnya berubah. Contohnya, waktu antara peristiwa 'Peninjauan Diminta' dan 'Perubahan Diminta dalam Peninjauan' oleh pengguna yang berbeda.

Metrik ini penting untuk menemukan kesenjangan komunikasi dan masalah koordinasi. Metrik ini mendukung dashboard 'Efisiensi Serah Terima Kritis' dan KPI 'Rata-rata Waktu Tunggu Serah Terima'. Waktu tunggu yang lama pada titik serah terima sering menunjukkan keterbatasan sumber daya atau proses notifikasi yang tidak efisien.

Mengapa ini penting

Menunjukkan keterlambatan akibat koordinasi yang buruk atau sumber daya yang tidak tersedia saat pekerjaan diserahterimakan antar tim atau peran. Hal ini sering menjadi sumber utama inefisiensi.

Sumber data

Dihitung dengan mencari aktivitas berurutan yang atribut 'Assignee' atau 'User'-nya berubah, lalu mengukur jeda waktu di antaranya.

Contoh
PT1H15MP2DT4HPT25M
Wajib Disarankan Opsional

Aktivitas siklus pengembangan perangkat lunak

Berikut tahapan dan pencapaian proses utama yang perlu dicatat dalam log peristiwa untuk menemukan proses secara akurat dan mengidentifikasi hambatan.
6 Disarankan 7 Opsional
Aktivitas Deskripsi
Issue dibuat
Menandai awal siklus hidup item pengembangan, yaitu saat tugas, bug, atau permintaan fitur dibuat secara resmi. Peristiwa ini tercatat saat pengguna membuat issue baru di repositori GitHub.
Mengapa ini penting

Ini adalah aktivitas awal utama dalam proses. Aktivitas ini penting untuk mengukur total waktu siklus pengembangan dan memahami sumber awal pekerjaan.

Sumber data

Peristiwa ini tercatat secara langsung dalam aliran peristiwa GitHub Issues API. Jenis peristiwanya biasanya 'opened' untuk nomor issue tertentu.

Pengumpulan data

Pantau peristiwa 'opened' pada issue melalui webhook atau polling API.

Jenis peristiwa explicit
Issue ditutup
Item pengembangan dianggap selesai dan issue terkait resmi ditutup. Penutupan dapat terjadi otomatis saat pull request yang terhubung digabungkan, atau dilakukan secara manual oleh anggota tim.
Mengapa ini penting

Aktivitas ini menandai akhir proses untuk sebuah item pengembangan. Tahap ini penting untuk menghitung waktu siklus dari awal hingga akhir.

Sumber data

Peristiwa ini tercatat secara langsung dalam aliran peristiwa GitHub Issues API. Jenis peristiwanya adalah 'closed'.

Pengumpulan data

Pantau peristiwa 'closed' pada issue melalui webhook atau polling API.

Jenis peristiwa explicit
Pemeriksaan CI berhasil
Menandai keberhasilan pemeriksaan otomatis, seperti build, pengujian unit, atau analisis statis, pada kode dalam pull request. Peristiwa ini disimpulkan dari status pemeriksaan yang dilaporkan oleh sistem seperti GitHub Actions.
Mengapa ini penting

Pemeriksaan kualitas otomatis ini penting untuk menjaga kestabilan kode. Kegagalan atau waktu proses yang lama dapat menjadi hambatan besar dalam alur rilis.

Sumber data

Disimpulkan dari GitHub Checks API atau Statuses API. Check run atau pembaruan status melaporkan 'success', atau 'completed' dengan hasil 'success'.

Pengumpulan data

Pantau Checks API untuk mengetahui hasil 'success' pada rangkaian pemeriksaan terkait.

Jenis peristiwa inferred
Pull request dibuka
Menandakan bahwa bagian awal kode siap ditinjau dan digabungkan. Developer membuat pull request (PR) untuk mengusulkan perubahan dari feature branch ke branch utama. Peristiwa ini tercatat secara langsung di GitHub.
Mengapa ini penting

Ini adalah tonggak penting yang menandai berakhirnya tahap awal pengembangan dan dimulainya proses peninjauan serta integrasi. Tahap ini membantu menganalisis waktu siklus pengembangan dan peninjauan secara terpisah.

Sumber data

Data diperoleh dari aliran peristiwa GitHub Pull Request API atau webhook. Tindakan peristiwanya adalah 'opened'.

Pengumpulan data

Pantau tindakan 'opened' pada pull request melalui webhook atau polling API.

Jenis peristiwa explicit
Pull request digabungkan
Perubahan kode yang telah disetujui dalam pull request resmi digabungkan ke branch tujuan, seperti main atau develop. Ini adalah tindakan akhir pada pull request yang memasukkan kode baru.
Mengapa ini penting

Ini adalah tonggak penting yang menandai selesainya pengembangan dan peninjauan. Bagi banyak tim, tahap ini menjadi langkah terakhir sebelum penerapan otomatis.

Sumber data

Data diperoleh dari aliran peristiwa GitHub Pull Request API atau webhook. Tindakan peristiwanya adalah 'closed', dan atribut 'merged' dalam payload pull request bernilai true.

Pengumpulan data

Pantau tindakan 'closed' pada pull request, lalu periksa apakah penanda 'merged' bernilai true.

Jenis peristiwa explicit
Pull request disetujui
Peninjau secara resmi menyetujui perubahan dalam pull request. Artinya, perubahan tersebut memenuhi standar kualitas dan fungsi. Peristiwa ini tercatat saat peninjau mengirimkan hasil peninjauan dengan status 'approve'.
Mengapa ini penting

Ini adalah pemeriksaan kualitas penting dan tonggak utama sebelum penggabungan. Waktu dari pembuatan PR hingga tahap ini merupakan KPI penting untuk mengukur efisiensi proses peninjauan.

Sumber data

Data diperoleh dari GitHub Pull Request API atau webhook saat hasil peninjauan dikirim dengan status 'APPROVED'.

Pengumpulan data

Filter peristiwa pengiriman hasil peninjauan pull request berdasarkan status 'APPROVED'.

Jenis peristiwa explicit
Branch dibuat
Menandai dimulainya pekerjaan pengembangan aktif untuk sebuah issue, saat developer membuat branch baru dari basis kode utama. Peristiwa ini tercatat saat branch baru dikirim ke repositori. Nama branch sering kali mencantumkan nomor issue.
Mengapa ini penting

Menandai peralihan dari perencanaan ke penulisan kode. Dengan mengukur waktu antara pembuatan issue dan peristiwa ini, Anda dapat menganalisis waktu yang dibutuhkan developer untuk mulai menangani pekerjaan serta keterlambatan awal dalam antrean pekerjaan.

Sumber data

Data diperoleh melalui GitHub Git API atau webhook yang memantau peristiwa 'create' bertipe 'branch'. Biasanya, nama branch perlu dikaitkan dengan issue melalui konvensi penamaan, seperti 'feature/issue-123'.

Pengumpulan data

Uraikan peristiwa webhook 'create' untuk branch baru, lalu kaitkan branch tersebut dengan issue.

Jenis peristiwa explicit
Issue dibuka kembali
Issue yang sebelumnya ditutup diaktifkan kembali, biasanya karena perbaikannya belum memadai atau ditemukan regresi. Peristiwa ini tercatat secara langsung dan memulai kembali siklus hidup item pengembangan.
Mengapa ini penting

Peristiwa ini menandai siklus pengerjaan ulang yang signifikan, yang dapat menunjukkan adanya 'cacat produksi yang lolos' atau perbaikan yang belum tuntas. Frekuensinya menjadi salah satu ukuran penting kualitas perangkat lunak secara keseluruhan.

Sumber data

Peristiwa ini tercatat secara langsung dalam aliran peristiwa GitHub Issues API. Jenis peristiwanya adalah 'reopened'.

Pengumpulan data

Pantau peristiwa 'reopened' pada issue melalui webhook atau polling API.

Jenis peristiwa explicit
Kode dikirim ke PR
Menandai pembaruan kode yang diajukan untuk ditinjau, baik sebagai bagian dari PR awal maupun sebagai tanggapan atas masukan peninjau. Peristiwa ini tercatat setiap kali commit baru dikirim ke branch yang terkait dengan pull request terbuka.
Mengapa ini penting

Melacak peristiwa ini penting untuk menemukan siklus pengerjaan ulang. Beberapa kali pengiriman kode setelah peninjauan menunjukkan bahwa perubahan diperlukan dan dapat memperpanjang waktu siklus secara keseluruhan.

Sumber data

Peristiwa ini tercatat secara langsung di linimasa pull request, biasanya dengan keterangan bahwa commit telah ditambahkan. Data dapat diperoleh dari webhook 'push' atau dengan memantau commit yang terkait dengan PR.

Pengumpulan data

Lacak peristiwa 'push' pada branch yang terkait dengan pull request terbuka.

Jenis peristiwa explicit
Pemeriksaan CI gagal
Menandai kegagalan pemeriksaan otomatis, seperti kesalahan build atau pengujian unit yang gagal, pada kode dalam pull request. Peristiwa ini disimpulkan dari status kegagalan yang dilaporkan oleh sistem seperti GitHub Actions.
Mengapa ini penting

Aktivitas ini menyoroti masalah kualitas teknis yang perlu ditangani developer dan memicu siklus pengerjaan ulang. Analisis frekuensi kegagalan dapat membantu tim meningkatkan pengujian lokal atau kualitas kode.

Sumber data

Disimpulkan dari GitHub Checks API atau Statuses API. Check run atau pembaruan status melaporkan 'failure', atau 'completed' dengan hasil 'failure'.

Pengumpulan data

Pantau Checks API untuk mengetahui hasil 'failure' pada rangkaian pemeriksaan terkait.

Jenis peristiwa inferred
Penerapan berhasil
Perubahan kode berhasil diterapkan ke lingkungan tertentu, seperti staging atau produksi. Peristiwa ini biasanya tercatat melalui GitHub Deployments API, sering kali setelah GitHub Action dijalankan usai penggabungan.
Mengapa ini penting

Menandai perpindahan kode dari repositori ke lingkungan aktif. Melacak tahap ini penting untuk mengukur keseluruhan waktu dari ide hingga produksi.

Sumber data

Data diperoleh melalui Deployments API. Layanan eksternal atau GitHub Action membuat penerapan, lalu memperbarui statusnya menjadi 'success'.

Pengumpulan data

Pantau peristiwa status penerapan melalui webhook untuk mengetahui status 'success'.

Jenis peristiwa inferred
Peninjauan diminta
Pembuat pull request secara resmi meminta anggota atau tim tertentu untuk meninjau kode. Tindakan ini dilakukan melalui antarmuka atau API GitHub dan mengirimkan notifikasi kepada peninjau yang diminta.
Mengapa ini penting

Aktivitas ini menandai dimulainya proses serah terima untuk peninjauan kode. Waktu antara permintaan ini dan pengiriman hasil peninjauan membantu mengukur kecepatan tanggapan peninjau serta menemukan potensi hambatan.

Sumber data

Data diperoleh dari aliran peristiwa GitHub Pull Request API atau webhook. Tindakan peristiwanya adalah 'review_requested'.

Pengumpulan data

Pantau tindakan 'review_requested' pada pull request.

Jenis peristiwa explicit
Perubahan diminta dalam peninjauan
Peninjau telah menyelesaikan peninjauan kode dan memutuskan bahwa perubahan perlu dilakukan sebelum pull request dapat disetujui. Peninjau mengirimkan hasil peninjauan secara resmi dengan status 'request_changes'.
Mengapa ini penting

Peristiwa ini secara langsung menandai siklus pengerjaan ulang. Dengan menganalisis frekuensinya, tim dapat menemukan masalah kualitas, persyaratan yang kurang jelas, atau kebutuhan pelatihan developer.

Sumber data

Data diperoleh dari GitHub Pull Request API atau webhook saat hasil peninjauan dikirim dengan status 'CHANGES_REQUESTED'.

Pengumpulan data

Filter peristiwa pengiriman hasil peninjauan pull request berdasarkan status 'CHANGES_REQUESTED'.

Jenis peristiwa explicit
Disarankan Opsional

Panduan ekstraksi

Cara mengambil data dari GitHub

Siap memulai?

Gunakan templat ini untuk menyiapkan data dan mulai mengoptimalkan siklus pengembangan perangkat lunak Anda. Temukan inefisiensi dan wujudkan rilis yang lebih cepat dan lancar.

Tingkatkan SDLC: temukan inefisiensi dengan cepat

Kurangi waktu siklus hingga 30% dan sederhanakan proses pengembangan GitHub Anda.

Mulai uji coba gratis

Tidak perlu kartu kredit. Siapkan dalam hitungan menit.