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 dari ServiceNow DevOps
Atribut siklus pengembangan perangkat lunak
| Nama | Deskripsi | ||
|---|---|---|---|
| Item pengembangan DevelopmentItem | ID unik untuk satu unit pekerjaan, seperti fitur, bug, atau tugas, yang bergerak melalui siklus pengembangan. | ||
| Deskripsi Item Pengembangan berfungsi sebagai ID kasus utama yang mewakili satu unit pekerjaan yang dilacak. Item ini menghubungkan semua aktivitas, mulai dari perumusan dan perencanaan awal hingga pengembangan, pengujian, dan penerapan. Dalam analisis process mining, atribut ini menjadi dasar untuk merekonstruksi perjalanan setiap item pekerjaan dari awal hingga akhir. Atribut ini memungkinkan visualisasi alur proses, penghitungan total waktu siklus, dan identifikasi variasi proses untuk setiap fitur atau perbaikan bug. Setiap peristiwa dalam log harus dikaitkan dengan Item Pengembangan agar peta proses dapat disusun secara utuh. Mengapa ini penting ID utama ini menghubungkan semua aktivitas pengembangan terkait ke dalam satu instans proses. Dengan begitu, seluruh siklus setiap item pekerjaan dapat dianalisis. Sumber data ID ini biasanya berupa kunci utama dari tabel yang mengelola story, bug, atau tugas, seperti tabel 'rm_story', 'rm_bug', atau 'task' di ServiceNow. Contoh STRY0010015BUG0034092TASK0050118 | |||
| Nama aktivitas ActivityName | Nama peristiwa tertentu dalam siklus pengembangan yang terjadi, seperti 'Pengembangan dimulai' atau 'Tinjauan kode dilakukan'. | ||
| Deskripsi Atribut ini mencatat nama setiap tonggak atau tugas yang diselesaikan dalam siklus pengembangan perangkat lunak. Aktivitas ini membentuk urutan langkah proses, dari pembuatan hingga penerapan. Menganalisis urutan dan frekuensi aktivitas merupakan fungsi utama process mining. Analisis ini membantu menyusun peta proses, menemukan hambatan di antara langkah-langkah, serta menyoroti variasi proses yang tidak patuh atau tidak efisien. Daftar aktivitas yang ditetapkan mencakup tahap penting seperti desain, pengembangan, pengujian, dan penerapan. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam peta proses. Anda dapat menganalisis alur proses, menemukan hambatan, dan mengidentifikasi penyimpangan dari SDLC standar. Sumber data Biasanya, atribut ini diperoleh dengan memetakan perubahan status, rekaman peristiwa, atau entri jejak audit ke daftar nama aktivitas standar. Contohnya, perubahan kolom 'state' menjadi 'In Progress' dapat dipetakan ke 'Pengembangan dimulai'. Contoh Pengembangan dimulaiKode di-commitPengujian QA selesaiDiterapkan ke produksi | |||
| Waktu mulai EventTime | Stempel waktu tepat yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu setiap aktivitas dalam siklus pengembangan. Data ini diperlukan untuk mengurutkan peristiwa secara kronologis dan melakukan semua analisis berbasis waktu. Dalam process mining, waktu mulai digunakan untuk menghitung durasi antaraktivitas, menemukan waktu tunggu, dan mengukur total waktu siklus proses. Data ini penting untuk dashboard yang menganalisis kinerja, seperti Analisis Waktu Siklus SDLC dari Awal hingga Akhir, serta untuk menghitung indikator kinerja utama seperti Waktu Penyelesaian Tinjauan Kode. Mengapa ini penting Stempel waktu ini diperlukan untuk mengurutkan peristiwa dengan benar dan menghitung semua metrik kinerja, termasuk waktu siklus, durasi, dan waktu tunggu. Sumber data Biasanya ditemukan di kolom stempel waktu yang dibuat sistem, seperti 'sys_updated_on' atau 'sys_created_on', pada tabel jejak audit atau tugas. Contoh 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z | |||
| Pembaruan data terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk log peristiwa ini terakhir kali diperbarui dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat kapan dataset terakhir diekstrak atau diperbarui dari ServiceNow DevOps. Atribut ini berlaku untuk seluruh dataset, bukan untuk setiap peristiwa. Stempel waktu ini penting untuk mengetahui seberapa baru data yang dianalisis. Informasi ini menunjukkan seberapa mutakhir wawasan proses bagi pengguna dan membantu menjadwalkan pembaruan data. Dengan menampilkan informasi ini di dashboard, setiap metrik dan visualisasi memiliki konteks yang jelas sehingga keputusan didasarkan pada data terbaru. Mengapa ini penting Memberikan konteks penting tentang kebaruan data, sehingga pengguna mengetahui seberapa mutakhir analisis proses. Sumber data Stempel waktu ini dibuat dan ditambahkan selama proses ekstraksi data untuk mencatat waktu pelaksanaan ekstraksi. Contoh 2023-11-15T08:00:00Z | |||
| Sistem sumber SourceSystem | Menunjukkan sistem asal data yang diekstrak, dalam hal ini ServiceNow DevOps. | ||
| Deskripsi Atribut ini menunjukkan sistem asal data peristiwa. Untuk proses ini, nilainya akan selalu 'ServiceNow DevOps'. Meski tampak tetap, pencantuman sistem sumber secara eksplisit penting untuk tata kelola data dan lingkungan yang menggabungkan data dari beberapa sistem, seperti Jira atau Azure DevOps. Informasi ini memperjelas asal data dan membantu mendiagnosis masalah kualitas atau ekstraksi data. Mengapa ini penting Memastikan data dapat ditelusuri dan menjaga integritasnya, terutama saat menggabungkan data dari beberapa alat pengembangan. Sumber data Nilai tetap ini perlu ditambahkan selama proses ekstraksi dan transformasi data. Contoh ServiceNow DevOps | |||
| Apakah pengerjaan ulang IsRework | Penanda boolean bernilai benar jika aktivitas termasuk dalam siklus pengerjaan ulang, misalnya kembali ke tahap pengembangan setelah pengujian. | ||
| Deskripsi Atribut turunan ini menandai aktivitas yang terjadi setelah proses kembali ke tahap sebelumnya. Misalnya, jika aktivitas 'Pengembangan dimulai' terjadi setelah 'Pengujian QA selesai' untuk item yang sama, aktivitas tersebut ditandai sebagai pengerjaan ulang. Penanda ini penting untuk mengukur dan memvisualisasikan pengerjaan ulang. Penanda ini mendukung dasbor 'Analisis alur pengerjaan ulang dan penolakan' dan digunakan untuk menghitung KPI 'Tingkat pengerjaan ulang setelah pengujian'. Dengan penanda ini, analis dapat memfilter dan menganalisis frekuensi, penyebab, serta dampak pengerjaan ulang terhadap waktu siklus secara keseluruhan. Mengapa ini penting Penanda ini memudahkan pengukuran dan analisis pengerjaan ulang, membantu menilai kualitas proses dan menemukan penyebab pekerjaan berulang. Sumber data Atribut ini dihitung di alat process mining dengan menganalisis urutan aktivitas setiap kasus untuk mendeteksi langkah mundur dalam alur proses. Contoh truefalse | |||
| Developer yang ditugaskan AssignedDeveloper | Nama atau ID developer maupun pengguna yang ditugaskan ke item pengembangan saat aktivitas berlangsung. | ||
| Deskripsi Atribut ini menunjukkan orang yang bertanggung jawab menjalankan tugas atau aktivitas tertentu. Nilainya dapat berubah saat item pengembangan berpindah tahap atau tim. Atribut ini penting untuk menganalisis alokasi sumber daya, beban kerja, dan serah terima. Atribut ini mendukung dashboard 'Beban Kerja dan Serah Terima Developer' serta KPI 'Volume Aktivitas per Developer'. Dengan melacak perubahan nilainya, Anda dapat mengukur waktu serah terima dan menemukan hambatan kolaborasi antar-developer atau antara tim pengembangan dan QA. Mengapa ini penting Atribut ini diperlukan untuk analisis berbasis sumber daya, termasuk distribusi beban kerja, efisiensi serah terima, dan pola kinerja khusus tim. Sumber data Informasi ini biasanya tersimpan di kolom 'assigned_to' pada tabel terkait tugas di ServiceNow. Contoh David MillerAnna WilliamsJames Brown | |||
| Grup penugasan AssignmentGroup | Tim atau grup yang bertanggung jawab atas item pengembangan saat aktivitas berlangsung. | ||
| Deskripsi Atribut ini menunjukkan tim yang menangani item kerja, misalnya 'Pengembang frontend', 'Layanan backend', atau 'Tim QA'. Saat item kerja berjalan, penanganannya sering berpindah dari satu grup penugasan ke grup lain. Melacak grup penugasan penting untuk memahami kolaborasi lintas fungsi dan perpindahan pekerjaan. Informasi ini membantu menemukan keterlambatan sistemis saat pekerjaan berpindah antartim. Atribut ini juga mendukung analisis kinerja dan beban kerja tiap tim, serta membantu mengetahui tim mana yang menjadi hambatan dalam alur kerja secara keseluruhan. Mengapa ini penting Melacak tim yang bertanggung jawab atas pekerjaan, sehingga kinerja dan beban kerja tim serta kelancaran perpindahan pekerjaan antartim dapat dianalisis. Sumber data Informasi ini tersimpan di kolom 'assignment_group', kolom standar pada tabel terkait tugas di ServiceNow. Contoh Rekayasa platformTim aplikasi selulerJaminan kualitasDevOps | |||
| Jenis item pengembangan DevelopmentItemType | Klasifikasi item kerja, misalnya 'Fitur', 'Bug', 'Utang teknis', atau 'Tugas'. | ||
| Deskripsi Atribut ini membedakan jenis pekerjaan yang berjalan dalam proses SDLC. Misalnya, proses untuk memperbaiki bug kritis mungkin berbeda dan lebih cepat daripada proses untuk mengembangkan fitur baru. Analisis berdasarkan jenis item kerja memberi gambaran kinerja yang lebih terperinci. Anda dapat menjawab pertanyaan seperti: 'Apakah bug lebih sering dikerjakan ulang daripada fitur baru?' atau 'Apakah waktu siklus pengurangan utang teknis sudah sesuai?'. Pengelompokan ini memberi wawasan lebih mendalam daripada melihat semua pekerjaan sebagai satu proses yang sama. Mengapa ini penting Membedakan jenis pekerjaan, seperti fitur dan bug, yang mungkin memiliki jalur proses, prioritas, dan durasi yang berbeda. Sumber data Jenis ini dapat diketahui dari tabel sumber rekaman, misalnya 'rm_story' atau 'rm_bug', atau dari kolom 'type' pada tabel tugas umum. Contoh FiturBugTugasSpike | |||
| Modul/komponen yang terdampak ModuleComponentAffected | Modul perangkat lunak, aplikasi, atau komponen tertentu yang terkait dengan item pengembangan. | ||
| Deskripsi Atribut ini mengelompokkan pekerjaan pengembangan berdasarkan bagian sistem yang terdampak. Bagian tersebut dapat berupa microservice tertentu, komponen UI, atau aplikasi backend. Mengelompokkan proses berdasarkan modul atau komponen penting untuk menemukan hambatan di bagian tertentu. Dasbor 'Wawasan hambatan khusus komponen' dan KPI 'Rata-rata durasi tahap per komponen' menggunakan atribut ini untuk mengetahui apakah bagian tertentu dari basis kode secara konsisten berkaitan dengan siklus pengembangan yang lebih lama, pengerjaan ulang yang lebih sering, atau kegagalan penerapan yang lebih banyak. Dengan begitu, upaya perbaikan dapat difokuskan pada bagian yang paling membutuhkan. Mengapa ini penting Memungkinkan analisis dikelompokkan berdasarkan aplikasi atau komponen, sehingga hambatan atau masalah kualitas di bagian sistem tertentu dapat diketahui. Sumber data Biasanya berupa kolom khusus atau referensi ke Configuration Management Database (CMDB) yang menghubungkan item kerja dengan rekaman 'cmdb_ci'. Lihat dokumentasi ServiceNow DevOps. Contoh Layanan penagihanUI autentikasi penggunaBasis data pelaporanAPI Gateway | |||
| Prioritas DevelopmentItemPriority | Tingkat prioritas item pengembangan, seperti 'High', 'Medium', atau 'Low'. | ||
| Deskripsi Atribut ini mengelompokkan item pengembangan berdasarkan tingkat urgensi bisnisnya. Tingkat prioritas membantu tim berfokus pada tugas paling penting dan sering digunakan untuk mengelola SLA serta ekspektasi pemangku kepentingan. Dalam process mining, prioritas menjadi dimensi penting untuk analisis perbandingan. Anda dapat memfilter peta proses untuk melihat apakah item berprioritas tinggi mengikuti jalur yang lebih cepat atau berbeda. Atribut ini penting untuk dashboard dan KPI 'Waktu Pengiriman Fitur Berprioritas Tinggi', yang membantu memastikan item penting benar-benar diproses lebih cepat. Mengapa ini penting Memungkinkan Anda memfilter dan membandingkan proses berdasarkan tingkat prioritas, serta memeriksa apakah item berprioritas tinggi diproses lebih cepat dan efisien. Sumber data Ini adalah kolom standar, biasanya bernama 'priority', pada tabel terkait tugas di ServiceNow. Contoh 1 - Kritis2 - Tinggi3 - Sedang4 - Rendah | |||
| Status item pengembangan DevelopmentItemState | Status item pengembangan saat suatu peristiwa terjadi, misalnya 'Terbuka', 'Sedang dikerjakan', atau 'Ditutup'. | ||
| Deskripsi Atribut ini menunjukkan status resmi item pengembangan di ServiceNow. Aktivitas menggambarkan langkah-langkah proses, sedangkan status menunjukkan tahap formal dalam alur kerja sistem. Status sering menjadi sumber untuk menentukan aktivitas. Status juga dapat digunakan untuk memvalidasi data dan membuat tampilan proses tingkat tinggi yang lebih sederhana. Misalnya, analisis waktu yang dihabiskan di setiap status dapat menunjukkan hambatan dengan cara berbeda dibandingkan analisis waktu antaraktivitas. Status juga berguna untuk menemukan item yang tertahan atau sudah diselesaikan. Mengapa ini penting Menunjukkan status resmi item kerja di sistem. Status ini sering menjadi sumber untuk menentukan aktivitas dan dapat digunakan untuk validasi serta analisis status tingkat tinggi. Sumber data Biasanya, tabel terkait tugas di ServiceNow memiliki kolom standar bernama 'state' atau 'stage'. Contoh MenungguSedang dikerjakanSiap diujiDitutup, selesai | |||
| Waktu siklus item pengembangan DevelopmentItemCycleTime | Total waktu sejak item pengembangan dibuat hingga ditutup atau diterapkan. | ||
| Deskripsi Atribut ini adalah metrik hasil perhitungan yang menunjukkan durasi menyeluruh untuk satu item pengembangan. Nilainya dihitung dari selisih waktu aktivitas pertama dan terakhir untuk setiap kasus. Metrik ini menjadi indikator kinerja utama bagi seluruh proses SDLC dan mendukung KPI 'Rata-rata waktu siklus SDLC'. Metrik ini mengukur kecepatan dan efisiensi proses secara keseluruhan. Dengan menganalisisnya dari waktu ke waktu dan berdasarkan dimensi seperti prioritas atau tim, Anda dapat memantau dampak inisiatif perbaikan proses. Mengapa ini penting Menunjukkan total durasi menyeluruh suatu item kerja. Metrik ini penting untuk mengukur efisiensi dan kecepatan proses secara keseluruhan. Sumber data Kolom ini tidak tersedia di sistem sumber. Nilainya dihitung di alat process mining dengan mengurangi StartTime minimum dari StartTime maksimum untuk setiap CaseId. Contoh 15 hari 4 jam3 hari 12 jam32 hari 8 jam | |||
| Alasan pengerjaan ulang ReworkReason | Klasifikasi atau keterangan tentang alasan item pengembangan perlu dikerjakan ulang setelah pengujian. | ||
| Deskripsi Saat item gagal dalam QA atau UAT, atribut ini mencatat penyebabnya. Penyebabnya dapat berupa kategori bug tertentu, persyaratan yang disalahpahami, atau masalah lingkungan. Informasi ini memberi konteks penting untuk dasbor 'Analisis alur pengerjaan ulang dan penolakan'. Analis tidak hanya mengetahui bahwa pengerjaan ulang terjadi, tetapi juga alasannya. Dengan begitu, perbaikan dapat diarahkan secara tepat, misalnya dengan memperjelas persyaratan, meningkatkan pengujian unit, atau menstabilkan lingkungan pengujian untuk mengurangi pengerjaan ulang secara keseluruhan. Mengapa ini penting Menjelaskan alasan pengerjaan ulang, sehingga perbaikan proses dapat diarahkan untuk meningkatkan kualitas dan mengurangi siklus pengerjaan ulang. Sumber data Informasi ini dapat dicatat di kolom 'close_notes' saat pengujian gagal, atau di kolom khusus 'rework_reason'. Lihat dokumentasi ServiceNow DevOps. Contoh Persyaratan disalahartikanBug regresiGagal dalam uji kinerjaMasalah UI/UX | |||
| ID commit CommitId | Pengenal unik commit kode sumber yang terkait dengan pekerjaan pengembangan. | ||
| Deskripsi Atribut ini menghubungkan item pengembangan langsung ke perubahan kode tertentu di repositori kode sumber, seperti Git. Informasi ini dicatat saat aktivitas 'Kode di-commit' terjadi. Dalam process mining, ID commit memperkaya analisis dengan menghubungkan data proses dan data rekayasa perangkat lunak. Analis dapat menelusuri penerapan yang bermasalah hingga ke perubahan kode tertentu, atau mengaitkan metrik kompleksitas kode dengan waktu siklus pengembangan. Ini memberi lapisan analisis akar masalah yang lebih mendalam dan teknis. Mengapa ini penting Menghubungkan peristiwa proses dengan perubahan kode tertentu, sehingga analisis akar masalah dapat dilakukan lebih mendalam dengan mengaitkan metrik proses dan detail kode. Sumber data Informasi ini dicatat melalui integrasi ServiceNow DevOps dengan sistem manajemen kode sumber seperti Git atau SVN. Data tersimpan di tabel terkait yang terhubung dengan item pengembangan. Contoh a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f | |||
| Status penerapan DeploymentStatus | Menunjukkan hasil aktivitas penerapan, biasanya 'Berhasil' atau 'Gagal'. | ||
| Deskripsi Atribut ini mencatat hasil penerapan ke lingkungan tertentu. Informasi ini penting untuk memahami keandalan dan kestabilan proses rilis. Atribut ini diperlukan untuk dasbor 'Tren keberhasilan dan kegagalan penerapan' serta KPI 'Tingkat kegagalan penerapan'. Dengan menganalisis frekuensi dan tren kegagalan penerapan, organisasi dapat menemukan masalah mendasar pada pengujian, infrastruktur, atau koordinasi rilis. Hasilnya membantu memusatkan upaya pada peningkatan kualitas dan keandalan pengiriman perangkat lunak. Mengapa ini penting Mengukur langsung keberhasilan aktivitas penerapan. Informasi ini penting untuk menghitung tingkat kegagalan penerapan dan menganalisis kestabilan rilis. Sumber data Status ini biasanya dicatat dalam tugas pelacakan penerapan atau rekaman eksekusi pipeline CI/CD yang terintegrasi dengan ServiceNow DevOps. Contoh BerhasilGagalSelesai dengan peringatan | |||
| Versi rilis yang direncanakan PlannedReleaseVersion | Rilis atau versi perangkat lunak yang ditargetkan untuk menyertakan item pengembangan. | ||
| Deskripsi Atribut ini menghubungkan item pengembangan dengan rilis tertentu yang direncanakan, misalnya 'Versi 2.3' atau 'Rilis Q4 2023'. Atribut ini penting untuk manajemen proyek dan perencanaan rilis. Dalam process mining, atribut ini penting bagi dasbor 'Pemantauan kesesuaian rencana rilis'. Dengan membandingkan tanggal penyelesaian aktual dengan tanggal rilis yang direncanakan, tim dapat mengukur kesesuaian jadwal, menemukan item yang berisiko tidak masuk ke rilis, dan menganalisis penyebab keterlambatan rilis. Atribut ini menghubungkan proses pengembangan tingkat detail dengan sasaran bisnis tingkat tinggi. Mengapa ini penting Menghubungkan pekerjaan pengembangan dengan rilis tertentu, sehingga kesesuaian jadwal dan dampak keterlambatan proses terhadap jadwal rilis dapat dianalisis. Sumber data Informasi ini biasanya tersimpan di kolom 'release' atau 'planned_release', yang sering merujuk ke tabel manajemen rilis di ServiceNow. Lihat dokumentasi ServiceNow DevOps. Contoh v3.4.1Rilis Q1 2024Peluncuran Project Phoenix | |||
| Waktu selesai EventEndTime | Stempel waktu tepat yang menunjukkan kapan suatu aktivitas selesai. Untuk peristiwa yang terjadi seketika, nilainya sama dengan Waktu mulai. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu selesainya setiap aktivitas dalam siklus pengembangan. Atribut ini sangat berguna untuk aktivitas yang durasinya dapat diukur, seperti 'Tinjauan kode dilakukan' atau 'Pengujian QA'. Dalam process mining, data waktu mulai dan waktu selesai memungkinkan penghitungan durasi pengerjaan aktivitas secara akurat, terpisah dari waktu tunggu antaraktivitas. Dengan begitu, Anda dapat mengetahui apakah keterlambatan disebabkan oleh tugas yang lama atau waktu tunggu sumber daya. Untuk peristiwa yang terjadi seketika, seperti 'Build dimulai', Waktu selesai dapat sama dengan Waktu mulai. Mengapa ini penting Memungkinkan penghitungan durasi pengerjaan aktivitas secara akurat, sehingga waktu kerja dapat dibedakan dari waktu tunggu. Sumber data Nilai ini mungkin perlu diturunkan dari data lain. Sumbernya dapat berupa stempel waktu mulai aktivitas berikutnya atau kolom 'end date' terpisah, jika tersedia di sistem sumber. Contoh 2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z | |||
Aktivitas siklus pengembangan perangkat lunak
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Diterapkan ke produksi | Peristiwa ini menandai keberhasilan penerapan ke lingkungan produksi. ServiceNow DevOps mencatatnya secara langsung saat alat CI/CD melaporkan pipeline berhasil diselesaikan. | ||
| Mengapa ini penting Ini adalah titik akhir keberhasilan utama dalam proses SDLC. Peristiwa ini menuntaskan alur nilai dan diperlukan untuk menghitung total waktu siklus. Sumber data Diambil dari nilai 'completion_status' pada rekaman Pipeline Execution [sn_devops_pipeline_execution] atau Stage Execution Run terkait. Status 'Success' pada waktu selesai menandai peristiwa ini. Pengumpulan data Dicatat saat pipeline penerapan produksi berhasil diselesaikan. Jenis peristiwa explicit | |||
| Item pengembangan dibuat | Aktivitas ini menandai pembuatan item pengembangan baru, seperti story, bug, atau epic, di ServiceNow. Peristiwa ini biasanya tercatat secara langsung saat rekaman baru dimasukkan ke tabel terkait, seperti tabel Story [rm_story]. | ||
| Mengapa ini penting Ini adalah peristiwa awal utama dalam proses SDLC. Peristiwa ini memungkinkan pengukuran total waktu siklus dari awal hingga akhir serta pelacakan permintaan yang masuk. Sumber data Peristiwa ini tercatat di tabel sys_audit atau sys_history_line saat rekaman dibuat di tabel terkait pengembangan, seperti Story [rm_story], Epic [rm_epic], atau Defect [rm_defect]. Stempel waktu pembuatan biasanya tersimpan pada rekaman itu sendiri. Pengumpulan data Diambil dari stempel waktu pembuatan rekaman item pengembangan. Jenis peristiwa explicit | |||
| Penerapan gagal | Menandakan upaya menerapkan item pengembangan ke produksi tidak berhasil. ServiceNow DevOps mencatatnya secara langsung saat pipeline CI/CD melaporkan kegagalan. | ||
| Mengapa ini penting Ini adalah titik akhir kegagalan yang penting. Analisis frekuensi dan penyebabnya membantu meningkatkan stabilitas rilis dan mengurangi tingkat kegagalan penerapan. Sumber data Diambil dari nilai 'completion_status' pada rekaman Pipeline Execution [sn_devops_pipeline_execution]. Status 'Failed' pada waktu selesai menandai peristiwa ini. Pengumpulan data Dicatat saat pipeline penerapan produksi melaporkan status gagal. Jenis peristiwa explicit | |||
| Pengembangan dimulai | Aktivitas ini menandai saat developer mulai menulis kode atau menerapkan item pengembangan. Biasanya, aktivitas ini disimpulkan dari perubahan status item menjadi 'In Progress', 'Development', atau 'Coding'. | ||
| Mengapa ini penting Tonggak penting ini menandai dimulainya tahap pengerjaan yang menghasilkan nilai. Data ini penting untuk mengukur waktu pengerjaan developer dan siklus tinjauan kode. Sumber data Disimpulkan dari stempel waktu saat kolom 'State' pada rekaman item pengembangan, misalnya Story [rm_story], diperbarui menjadi 'In Progress' atau status yang setara. Pengumpulan data Berdasarkan stempel waktu perubahan state menjadi 'In Progress' atau nilai serupa. Jenis peristiwa inferred | |||
| Pengujian QA selesai | Menandakan tim Quality Assurance telah menyelesaikan pengujian item pengembangan. Peristiwa ini biasanya disimpulkan saat state item keluar dari tahap pengujian dan berubah menjadi status seperti 'Ready for UAT' atau 'Done'. | ||
| Mengapa ini penting Tonggak ini menandai selesainya salah satu titik pemeriksaan kualitas utama. Tahap ini harus selesai sebelum proses berlanjut ke User Acceptance Testing atau persiapan rilis. Sumber data Disimpulkan dari stempel waktu perubahan state dari status pengujian, misalnya 'In QA', ke status setelah pengujian, misalnya 'Ready for UAT' atau 'Resolved'. Pengumpulan data Berdasarkan stempel waktu perubahan state dari 'Testing' ke state berikutnya. Jenis peristiwa inferred | |||
| Tinjauan kode dilakukan | Aktivitas ini menandai selesainya tinjauan kode oleh rekan kerja, biasanya terkait dengan pull request atau merge request. Peristiwa ini dapat dicatat langsung melalui integrasi DevOps atau disimpulkan dari perubahan status pada rekaman terkait. | ||
| Mengapa ini penting Ini adalah titik pemeriksaan kualitas yang penting. Analisis durasinya membantu menemukan hambatan dalam proses tinjauan, yang sering menjadi sumber keterlambatan SDLC. Sumber data Peristiwa ini dapat diambil dari peristiwa 'Merged' atau 'Completed' pada rekaman Pull Request di integrasi Git ServiceNow, atau disimpulkan dari perubahan status item pengembangan menjadi 'Code Review Complete'. Pengumpulan data Dicatat saat Pull Request yang terkait dengan item pekerjaan digabungkan. Jenis peristiwa explicit | |||
| UAT disetujui | Menandakan pemangku kepentingan bisnis telah menyetujui item pengembangan secara resmi setelah User Acceptance Testing. Tonggak penting ini disimpulkan dari perubahan status, misalnya dari 'In UAT' menjadi 'Ready for Release' atau 'Approved'. | ||
| Mengapa ini penting Ini adalah persetujuan bisnis terakhir sebelum item dinyatakan siap diterapkan ke lingkungan produksi. Tahap ini menjadi titik pemeriksaan penting untuk kualitas dan tata kelola. Sumber data Disimpulkan dari perubahan state pada rekaman item pengembangan yang menandakan UAT berhasil diselesaikan. Perubahan ini tercatat dalam riwayat aktivitas item. Pengumpulan data Disimpulkan dari perubahan state dari 'UAT' ke status disetujui atau siap dirilis. Jenis peristiwa inferred | |||
| Build dimulai | Peristiwa ini menandai dimulainya build pipeline CI/CD, yang sering kali dipicu oleh commit kode. ServiceNow DevOps mencatatnya sebagai eksekusi pipeline dan mengaitkannya dengan item pengembangan asal. | ||
| Mengapa ini penting Aktivitas ini menghubungkan pengembangan dengan pengujian atau penerapan otomatis. Analisis waktu antara commit dan dimulainya build dapat mengungkap keterlambatan dalam proses CI/CD. Sumber data Dicatat secara langsung di tabel Pipeline Execution [sn_devops_pipeline_execution] saat build dimulai di alat CI/CD terintegrasi, seperti Jenkins atau Azure DevOps. Pengumpulan data Diambil dari waktu mulai rekaman di tabel Pipeline Execution. Jenis peristiwa explicit | |||
| Desain dimulai | Menandai tahap pembuatan desain teknis atau arsitektur solusi untuk item pengembangan. Tahap ini biasanya disimpulkan dari perubahan nilai pada kolom status atau state item, misalnya menjadi 'Design' atau 'Solutioning'. | ||
| Mengapa ini penting Analisis durasi tahap desain membantu menemukan hambatan dalam menerjemahkan persyaratan dan merencanakan solusi sebelum pekerjaan pengembangan dimulai. Sumber data Disimpulkan dari perubahan state pada rekaman item pengembangan, misalnya Story [rm_story]. Periksa perubahan pada kolom 'State' atau kolom 'Stage' khusus ke nilai yang terkait dengan desain. Pengumpulan data Disimpulkan dari perubahan status menjadi 'Design' atau state serupa. Jenis peristiwa inferred | |||
| Disiapkan untuk rilis | Aktivitas ini menandakan item pengembangan telah melewati semua titik pemeriksaan kualitas dan dimasukkan ke dalam rilis tertentu. Peristiwa ini dapat disimpulkan saat item dikaitkan dengan rekaman Release atau statusnya berubah menjadi 'Ready for Deployment'. | ||
| Mengapa ini penting Tahap ini menandakan item telah selesai secara teknis dan fungsional. Waktu yang dihabiskan dalam state ini dapat menunjukkan waktu antre sebelum jadwal penerapan. Sumber data Disimpulkan dari perubahan kolom 'State' menjadi 'Ready for Release', atau dengan melacak kapan kolom 'Release' pada rekaman item pengembangan diisi atau diperbarui. Pengumpulan data Disimpulkan dari perubahan status atau keterkaitan dengan rekaman Release. Jenis peristiwa inferred | |||
| Item pengembangan dibatalkan | Menandai penghentian item pengembangan sebelum selesai. Ini adalah status akhir alternatif yang biasanya disimpulkan saat state item diatur menjadi 'Cancelled' atau 'Closed Incomplete'. | ||
| Mengapa ini penting Pelacakan pembatalan membantu menemukan upaya yang terbuang dan memahami alasan perubahan cakupan atau prioritas. Data ini memberikan gambaran lebih lengkap tentang semua kemungkinan hasil proses. Sumber data Disimpulkan dari stempel waktu saat kolom 'State' pada rekaman item pengembangan diperbarui ke status akhir yang belum selesai, seperti 'Cancelled'. Pengumpulan data Disimpulkan dari perubahan state menjadi 'Cancelled' atau status akhir yang setara. Jenis peristiwa inferred | |||
| Kode di-commit | Menandai saat developer melakukan commit kode ke repositori sistem kontrol versi yang terhubung dengan item pengembangan. ServiceNow DevOps mencatat peristiwa ini secara langsung dari alat SCM terintegrasi seperti Git atau GitHub. | ||
| Mengapa ini penting Pelacakan commit memberikan gambaran terperinci tentang kemajuan pengembangan dan frekuensi aktivitas. Data ini membantu mengaitkan perubahan kode tertentu dengan item pengembangan induknya. Sumber data Dicatat sebagai peristiwa langsung di tabel Commits [sn_devops_commit] ServiceNow DevOps. Tabel ini diisi melalui webhook dari sistem manajemen kode sumber yang terintegrasi. Pengumpulan data Dicatat saat webhook commit diterima dari alat SCM. Jenis peristiwa explicit | |||
| Penerapan ke produksi dimulai | Aktivitas ini menandai dimulainya pipeline penerapan ke lingkungan produksi. ServiceNow DevOps mencatatnya sebagai peristiwa langsung saat tahap produksi dalam pipeline CI/CD mulai dijalankan. | ||
| Mengapa ini penting Ini menandai dimulainya tahap akhir siklus, yang sering kali paling penting. Pelacakan tahap ini membantu menganalisis durasi penerapan dan menemukan peluang otomatisasi. Sumber data Dicatat secara langsung di tabel Stage Execution Run [sn_devops_stage_execution], dengan filter untuk tahap yang terkait dengan lingkungan produksi. Pengumpulan data Diambil dari waktu mulai tahap penerapan produksi dalam Pipeline Execution. Jenis peristiwa explicit | |||
| Pengerjaan ulang teridentifikasi | Menandakan adanya masalah yang ditemukan saat pengujian sehingga item harus dikembalikan ke tahap pengembangan. Peristiwa ini disimpulkan dari pergerakan mundur dalam alur proses, misalnya perubahan status dari 'In QA' kembali ke 'In Progress'. | ||
| Mengapa ini penting Pelacakan pengerjaan ulang penting untuk memahami masalah kualitas dan inefisiensi proses. Jika aktivitas ini sering terjadi, mungkin ada masalah dalam pengembangan atau kejelasan persyaratan. Sumber data Disimpulkan dengan menganalisis riwayat kolom 'State' di tabel sys_audit atau sys_history_line. Perubahan dari status tahap lanjut, misalnya 'Testing', ke status tahap sebelumnya, misalnya 'In Progress', menandakan pengerjaan ulang. Pengumpulan data Disimpulkan dari perubahan status ke tahap sebelumnya, misalnya 'Testing' -> 'In Progress'. Jenis peristiwa inferred | |||
| Pengujian QA dimulai | Menandai dimulainya tahap pengujian Quality Assurance secara resmi. Peristiwa ini hampir selalu disimpulkan dari perubahan state item pengembangan menjadi nilai seperti 'In QA', 'Testing', atau 'Ready for Test'. | ||
| Mengapa ini penting Aktivitas ini menandai serah terima dari tim pengembangan ke tim QA. Data ini membantu mengukur durasi pengujian dan menemukan hambatan akibat kapasitas pengujian. Sumber data Disimpulkan dari stempel waktu saat kolom 'State' pada rekaman item pengembangan, misalnya Story atau Defect, diperbarui ke status khusus QA. Pengumpulan data Berdasarkan stempel waktu perubahan state menjadi 'Testing' atau status yang setara. Jenis peristiwa inferred | |||
| UAT dimulai | Menandai dimulainya User Acceptance Testing, saat pemangku kepentingan bisnis memvalidasi fungsi yang dikembangkan. Peristiwa ini disimpulkan dari perubahan status menjadi 'UAT', 'In UAT', atau 'User Acceptance Testing'. | ||
| Mengapa ini penting Tahap ini penting untuk memastikan fitur yang dikembangkan memenuhi persyaratan bisnis. Analisis durasinya dapat mengungkap masalah keterlibatan pengguna atau ketidaksesuaian persyaratan. Sumber data Disimpulkan dari perubahan state pada rekaman item pengembangan. Cara ini bergantung pada model state pelanggan yang memiliki status khusus untuk UAT. Pengumpulan data Disimpulkan dari perubahan state menjadi status 'UAT'. Jenis peristiwa inferred | |||
Panduan ekstraksi data
Langkah
- Pahami model status Anda: Sebelum membuat laporan, dokumentasikan nilai tertentu di kolom status item pengembangan Anda, misalnya pada tabel Story
[rm_story]atau Defect[rm_defect], yang sesuai dengan aktivitas yang diwajibkan. Contohnya, nilai status 'Sedang Dikerjakan' dapat dipetakan ke aktivitas 'Development Started'. - Buka pembuatan laporan: Masuk ke instans ServiceNow Anda. Di Filter navigator, buka
Reports > View / Run, lalu klik tombolCreate a report. - Buat laporan untuk perubahan status: Buat laporan pertama untuk merekam aktivitas yang dipicu oleh perubahan status. Konfigurasikan sebagai berikut:
- Nama laporan:
ProcessMind - State Change Events - Jenis sumber:
Table - Tabel:
Audit [sys_audit] - Jenis:
List - Konfigurasikan kolom: Tambahkan
Document key,Created on,Table name,Field name,Old value, danNew value. - Filter: Atur
Table nameke salah satu tabel item pengembangan Anda, misalnyaStory, danField nameke kolom status, misalnyaState. Tambahkan filter tanggal pada kolomCreated onuntuk periode yang diinginkan.
- Nama laporan:
- Buat laporan untuk pembuatan item: Buat laporan baru untuk peristiwa pembuatan awal.
- Nama laporan:
ProcessMind - Item Creation Events - Jenis sumber:
Table - Tabel:
Story [rm_story](atau tabel item pengembangan utama Anda) - Jenis:
List - Konfigurasikan kolom: Tambahkan kolom untuk atribut yang diwajibkan, seperti
Number,Created on,Assigned to,Priority,State, dan sebagainya. - Filter: Terapkan filter tanggal pada kolom
Created on.
- Nama laporan:
- Buat laporan untuk commit kode: Buat laporan untuk peristiwa DevOps eksplisit yang terkait dengan commit.
- Nama laporan:
ProcessMind - Commit Events - Jenis sumber:
Table - Tabel:
Commit [sn_devops_commit] - Jenis:
List - Konfigurasikan kolom: Tambahkan kolom seperti
Work item,Commit time,Author, dan sebagainya. - Filter: Terapkan filter tanggal pada kolom
Commit time.
- Nama laporan:
- Buat laporan untuk build dan penerapan: Ulangi langkah sebelumnya untuk tabel
Build [sn_devops_build]danDeployment [sn_devops_deployment]. Tabel ini berisi catatan aktivitasBuild Triggered,Deployment to Production Started,Deployed to Production, danDeployment Failed. - Ekspor semua laporan: Jalankan setiap laporan yang dibuat satu per satu. Untuk setiap laporan, klik ikon menu konteks (tiga titik atau panah bawah), lalu pilih
Export > CSVatauExport > Excel. Simpan semua file. - Gabungkan dan transformasikan data: Buka file yang diekspor di aplikasi spreadsheet atau gunakan alat persiapan data. Gabungkan data dari semua file secara manual ke dalam satu lembar. Buat kolom log peristiwa yang diwajibkan (
DevelopmentItem,ActivityName,EventTime, dan sebagainya), lalu petakan data dari kolom sumber. Misalnya, petakanDocument keydari laporan audit danNumberdari laporan Story ke kolomDevelopmentItem. - Petakan nama aktivitas: Buat kolom
ActivityNamedengan menerjemahkan data sumber. Untuk laporan perubahan status, gunakan model status yang sudah didokumentasikan untuk memetakan entriNew valueke nama aktivitas, misalnya petakan status 'Testing' ke 'QA Testing Started'. Untuk laporan lainnya, tetapkan nama aktivitas yang sama pada setiap baris, misalnya semua baris dari ekspor commit menjadi 'Code Committed'. - Selesaikan dan simpan: Tambahkan kolom
SourceSystemdanLastDataUpdatedengan nilai tetap untuk semua baris. Pastikan semua stempel waktu menggunakan format yang konsisten. Simpan file gabungan final sebagai satu file CSV. File ini siap diunggah ke ProcessMind.
Konfigurasi
- Tabel yang diperlukan: Tabel utama untuk ekstraksi ini adalah
Audit [sys_audit]untuk peristiwa hasil inferensi, tabel item pengembangan yang sesuai, misalnyaStory [rm_story]danDefect [rm_defect], serta tabel inti ServiceNow DevOps:Commit [sn_devops_commit],Build [sn_devops_build], danDeployment [sn_devops_deployment]. - Filter utama: Filter terpenting adalah rentang tanggal. Terapkan secara konsisten pada semua laporan menggunakan kolom stempel waktu seperti
Created on,Commit time, atauWaktu mulai. Untuk laporansys_audit, filterTable name(misalnyarm_story) danField name(misalnyastate) agar data hanya mencakup perubahan status yang relevan. - Saran rentang tanggal: Sebaiknya ekstrak data untuk periode 3 hingga 6 bulan agar kumpulan data cukup mewakili proses tanpa menimbulkan masalah kinerja. Untuk sistem yang lebih besar, pertimbangkan mengekstrak data per bulan.
- Definisi model status: Anda perlu memahami model status work item organisasi dengan jelas. Informasi ini diperlukan untuk memetakan nilai status dalam tabel
sys_auditdengan benar ke aktivitas bisnis terkait, seperti 'Pengujian QA Dimulai' atau 'UAT Disetujui'. - Prasyarat: Pengguna yang melakukan ekstraksi memerlukan peran
report_useratau izin setara untuk membuat dan menjalankan laporan. Mereka juga memerlukan akses baca ke tabel DevOps dan pengembangan aplikasi yang disebutkan di atas. Plugin ServiceNow DevOps harus terpasang dan terintegrasi secara aktif dengan alat SCM dan CI/CD Anda.
Contoh kueri sql
/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/
---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
- Number (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- 'Development Item Created' (create a formula or static column for ActivityName)
- Assigned to (maps to AssignedDeveloper)
- Priority (maps to DevelopmentItemPriority)
- State (maps to DevelopmentItemState)
- cmdb_ci (maps to ModuleComponentAffected)
- Type (maps to DevelopmentItemType)
- Assignment group (maps to AssignmentGroup)
Filters:
- sys_created_on ON Last 6 months
---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
- documentkey (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- newvalue (maps to ActivityName, requires translation)
- user (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
- WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
- WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
- WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
- WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
- WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
- WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
- WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
- tablename = 'rm_story'
- fieldname = 'state'
- sys_created_on ON Last 6 months
---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- commit_time (maps to EventTime)
- 'Code Committed' (create a formula or static column for ActivityName)
- author.name (maps to AssignedDeveloper)
Filters:
- commit_time ON Last 6 months
---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime)
- 'Build Triggered' (create a formula or static column for ActivityName)
Filters:
- start_time ON Last 6 months
---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime for 'Started' activities)
- end_time (maps to EventTime for 'Completed' or 'Failed' activities)
- state (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
- WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
- WHEN state IS 'successful' THEN 'Deployed to Production'
- WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
- start_time ON Last 6 months
- [Filter for production deployments based on your environment configuration]
---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
--- Langkah
- Prasyarat: Pastikan Anda memiliki akses jaringan ke instans ServiceNow dan akun layanan khusus dengan izin baca (peran
itildansn_devops.viewerdapat menjadi titik awal yang baik). Akun ini memerlukan akses ke tabel sepertirm_story,sys_audit, dan skemasn_devops_*. - Pasang driver ODBC ServiceNow: Unduh driver ODBC ServiceNow yang sesuai dengan sistem operasi Anda dari portal dukungan ServiceNow. Ikuti petunjuk pemasangan yang tersedia.
- Atur DSN: Buat System DSN (Data Source Name) baru di komputer yang akan menjalankan kueri. Di ODBC Data Source Administrator, tambahkan driver ServiceNow dan atur URL instans (misalnya,
yourinstance.service-now.com), nama pengguna, dan kata sandi. - Hubungkan dengan klien SQL: Gunakan alat klien SQL seperti DBeaver, Microsoft SQL Server Management Studio (dengan linked server), atau bahasa skrip seperti Python dengan pustaka ODBC untuk terhubung ke ServiceNow menggunakan DSN yang sudah diatur.
- Identifikasi model status: Sebelum menjalankan kueri, identifikasi nilai persis yang digunakan organisasi Anda pada kolom
statedi tabel item pengembangan (misalnya,rm_story,rm_defect). Kueri yang disediakan menggunakan contoh umum seperti 'In Progress' atau 'In QA'. Ganti nilai tersebut dengan nilai yang digunakan di instans Anda. - Sesuaikan kueri SQL: Salin kueri SQL yang disediakan ke klien Anda. Ubah placeholder di bagian atas kueri, termasuk tanggal mulai ekstraksi dan nilai status spesifik yang sesuai dengan aktivitas siklus pengembangan Anda.
- Jalankan kueri: Jalankan seluruh kueri SQL pada database ServiceNow melalui koneksi ODBC. Proses ini mungkin memerlukan waktu cukup lama, bergantung pada rentang tanggal dan volume data.
- Tinjau data: Setelah kueri selesai, tinjau sekilas data yang dihasilkan. Periksa variasi aktivitas dan pastikan kolom penting seperti
DevelopmentItem,ActivityName, danEventTimeterisi sesuai harapan. - Ekspor ke CSV: Ekspor seluruh hasil kueri ke file CSV. Pastikan file menggunakan encoding UTF-8 dan judul kolom sesuai dengan nama atribut yang diperlukan ProcessMind, misalnya
DevelopmentItem,ActivityName,EventTime. - Siapkan untuk diunggah: Pastikan tidak ada baris kosong di akhir file CSV. Pastikan format tanggal untuk
EventTimedanLastDataUpdatekonsisten dan didukung ProcessMind (misalnya,YYYY-MM-DD HH:MM:SS).
Konfigurasi
- Prasyarat: Akses ke instans ServiceNow dengan modul DevOps aktif. Anda memerlukan akun pengguna khusus dengan izin baca untuk tabel yang diperlukan. Driver ODBC ServiceNow harus terpasang dan dikonfigurasi di komputer klien.
- Konfigurasi driver ODBC: Untuk terhubung, Anda memerlukan URL instans, nama pengguna, serta kata sandi atau token OAuth. Uji koneksi DSN sebelum menjalankan kueri yang rumit.
- Filter rentang tanggal: Kueri yang disediakan memuat placeholder
s.sys_created_on >= '2023-01-01'untuk membatasi jumlah data yang diekstrak. Sebaiknya ekstrak data untuk periode tertentu, misalnya 6 hingga 12 bulan terakhir, agar waktu eksekusi kueri tetap terkendali. - Penyesuaian model status: Ketepatan kueri dalam menyimpulkan peristiwa sepenuhnya bergantung pada model status. Ganti nilai status placeholder (misalnya,
[Your 'In Progress' State Value],[Your 'In QA' State Value]) dengan nilai persis yang digunakan dalam konfigurasi ServiceNow Anda. Nilai ini peka huruf besar-kecil. - Tabel item kerja: Kueri ini dibuat untuk tabel Story (
rm_story). Jika organisasi Anda juga menggunakan Defect (rm_defect), Enhancement (rm_enhancement), atau jenis tugas lainnya, tambahkan tabel tersebut ke Common Table Expression (CTE) awalDevItemsmenggunakanUNION ALL. - Kinerja: Kueri langsung pada instans ServiceNow produksi dapat memengaruhi kinerja. Sebaiknya jalankan ekstraksi besar di luar jam sibuk. Untuk kumpulan data yang sangat besar, pertimbangkan strategi ekstraksi bertahap berdasarkan kolom
sys_updated_on.
Contoh kueri sql
WITH DevItems AS (
-- This CTE selects the base set of development items to analyze.
-- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
SELECT
s.sys_id,
s.number,
s.sys_created_on,
s.sys_updated_on,
s.assigned_to,
s.priority,
s.state,
s.cmdb_ci, -- Module/Component Affected
s.sys_class_name, -- Development Item Type
s.assignment_group,
DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
FROM rm_story s
WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
-- This CTE unnests the audit trail for state changes, which are used for inferred activities.
SELECT
a.documentkey AS item_sys_id,
a.sys_created_on AS change_time,
a.oldvalue,
a.newvalue,
-- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
CASE a.oldvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS old_state_order,
CASE a.newvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS new_state_order
FROM sys_audit a
WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
i.number AS DevelopmentItem,
'Development Item Created' AS ActivityName,
i.sys_created_on AS EventTime,
'ServiceNow DevOps' AS SourceSystem,
GETDATE() AS LastDataUpdate,
us.name AS AssignedDeveloper,
i.priority AS DevelopmentItemPriority,
i.state AS DevelopmentItemState,
ci.name AS ModuleComponentAffected,
i.sys_class_name AS DevelopmentItemType,
grp.name AS AssignmentGroup,
i.cycle_time_seconds AS DevelopmentItemCycleTime,
CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***
UNION ALL
-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process
UNION ALL
-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state
UNION ALL
-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***
UNION ALL
-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value *** Siap memulai?
Mulai tingkatkan siklus pengembangan perangkat lunak Anda hari ini. Gunakan templat data ini untuk menemukan inefisiensi tersembunyi dan mendorong perbaikan berkelanjutan.
Jangan tunda, optimalkan siklus pengembangan perangkat lunak hari ini
Temukan inefisiensi untuk memangkas waktu siklus SDLC hingga 30% atau lebih.
Tidak perlu kartu kredit. Mulai optimalkan proses hari ini.