Banyak tim memulai implementasi SonarQube dengan menghubungkan scanner ke pipeline CI/CD lalu menjalankan analisis pertama. Hasilnya bisa cukup mengejutkan, yaitu ribuan issue dan coverage yang rendah pada aplikasi yang sudah bertahun-tahun berjalan di production. Jika seluruh temuan tersebut langsung dianggap sebagai pekerjaan remediasi besar, tim dapat kehilangan fokus dan akhirnya berhenti menggunakan SonarQube secara konsisten.
Mengapa Jumlah Issue Awal SonarQube Bukan Target Utama
3.800 issue tersebut merupakan akumulasi keputusan teknis selama bertahun-tahun, termasuk keputusan yang dibuat dengan mempertimbangkan deadline dan kebutuhan bisnis. Menjadikan seluruh backlog sebagai target remediasi dalam waktu singkat bukan pendekatan yang realistis. Menulis ulang kode production yang stabil tanpa test coverage yang memadai juga dapat meningkatkan risiko regresi. Karena itu, implementasi SonarQube sebaiknya membedakan technical debt lama dengan masalah yang muncul dari kode baru.
Target yang tidak realistis juga dapat menurunkan kepercayaan tim terhadap quality gate. Ketika status merah menjadi sesuatu yang selalu diabaikan, sinyal dari SonarQube kehilangan nilai—termasuk ketika menemukan bug atau masalah keamanan yang benar-benar perlu ditindaklanjuti.
Terapkan Quality Gate pada Kode Baru, Bukan Legacy Code
SonarQube menyebut pendekatan ini Clean as You Code. Alih-alih memperbaiki seluruh legacy codebase sekaligus, quality gate berfokus pada kode yang baru ditambahkan atau diubah. Periode kode baru dapat ditentukan berdasarkan versi rilis sebelumnya, periode tertentu seperti 30 hari, atau sejak analisis tertentu. Issue pada legacy code tetap dapat ditampilkan sebagai informasi dan bahan perencanaan technical debt, tetapi tidak harus menjadi penghambat development saat ini.
Dalam praktiknya, file berusia empat tahun dengan 40 issue tidak otomatis menjadi target sprint. Fokusnya adalah 60 baris kode baru atau yang diubah. Technical debt dapat dikurangi secara bertahap pada area yang sedang dikerjakan tim, sehingga developer memiliki konteks yang cukup dan dapat memperbaiki test coverage bersamaan dengan perubahan kode.
Legacy codebase tidak menjadi lebih baik hanya karena dashboard dipantau. Standar kualitas yang paling realistis untuk ditegakkan adalah pada kode baru yang sedang dikembangkan.
Cara Mengatur Quality Gate SonarQube
Sonar way quality gate dapat menjadi titik awal yang baik, tetapi setiap kondisinya perlu disesuaikan dengan praktik engineering tim. Target coverage 80% pada kode baru mungkin sesuai untuk tim yang sudah memiliki budaya testing yang matang. Namun, pada codebase dengan overall coverage 11%, target yang terlalu agresif sejak awal dapat membuat hampir semua pull request gagal dan mendorong tim untuk melakukan bypass. Quality gate hanya efektif jika diperlakukan sebagai standar engineering yang benar-benar dijalankan.
| Kondisi | Kami mulai dari | Alasan |
|---|---|---|
| Bug dan vulnerability baru | 0 | Satu-satunya kondisi yang layak dipasang ketat. Kode baru tidak seharusnya rilis membawa cacat yang sudah diketahui. |
| Security hotspot ditinjau | 100% | Hotspot meminta keputusan, belum tentu perbaikan. Menandainya aman disertai satu kalimat konteks sudah dihitung lolos. |
| Coverage kode baru | 50-60%, dinaikkan tiap kuartal | Angka yang bisa dicapai dan dipertahankan lebih berguna daripada angka ideal yang akhirnya dilangkahi. |
| Duplikasi pada kode baru | 3% | Menangkap kebiasaan salin-tempel-lalu-ubah yang mengubah satu bug menjadi empat. |
| Rating kode keseluruhan | Laporan saja | Memblokir di sini hanya menghukum siapa pun yang kebetulan menyentuh file paling tua berikutnya. |
Bagaimana SonarQube Membaca Test Coverage
Bagian ini sering menimbulkan kesalahpahaman. SonarQube tidak menjalankan test dan tidak menghitung test coverage secara langsung. SonarQube membaca laporan coverage yang sudah dihasilkan oleh proses build dan testing. Jika path laporan belum dikonfigurasi dengan benar, dashboard dapat menampilkan coverage 0,0% meskipun automated test sebenarnya sudah tersedia.
- Java dan Kotlin menggunakan laporan XML JaCoCo, lewat sonar.coverage.jacoco.xmlReportPaths.
- JavaScript dan TypeScript menggunakan lcov.info, lewat sonar.javascript.lcov.reportPaths.
- Go menggunakan hasil go test -coverprofile, lewat sonar.go.coverage.reportPaths.
- PHP menggunakan laporan Clover XML, lewat sonar.php.coverage.reportPaths.
- Python menggunakan coverage.xml, lewat sonar.python.coverage.reportPaths.
- Untuk .NET, jalankan scanner MSBuild dalam bentuk begin dan end, lalu berikan hasil OpenCover atau dotnet-coverage.
Laporan coverage harus tersedia pada environment yang digunakan SonarQube Scanner, baik dihasilkan pada job yang sama maupun disalin sebelum proses analisis berjalan. Jika laporan berada di runner lain atau path-nya tidak dapat diakses, SonarQube tidak dapat mengimpornya. Akibatnya, dashboard dapat menunjukkan 0,0% meskipun test sebenarnya sudah dijalankan.
Apa yang Bisa dan Tidak Bisa Dideteksi SonarQube
SonarQube sangat berguna untuk menemukan pola masalah pada kualitas, reliability, maintainability, dan keamanan kode yang sulit diperiksa secara konsisten melalui code review manual. Contohnya adalah resource yang tidak ditutup, exception yang ditangkap tetapi diabaikan, implementasi equals/hashCode yang tidak tepat, regular expression yang berpotensi bermasalah, credential yang tersimpan di file konfigurasi, serta query SQL yang dirakit melalui penggabungan string yang tidak aman.
Static analysis juga memiliki keterbatasan. SonarQube dapat mengenali pola pada kode, tetapi tidak memahami seluruh aturan bisnis atau kondisi runtime aplikasi. Karena itu, beberapa jenis defect tetap membutuhkan business knowledge, integration testing, dan validasi pada runtime.
- Aturan diskon yang memakai persentase yang salah. Semua barisnya bersih, hasilnya tetap keliru.
- Endpoint yang lupa pengecekan otorisasi, sementara kode di sekitarnya terlihat biasa saja.
- Race condition yang baru muncul pada konkurensi sesungguhnya.
- Migrasi dengan SQL yang benar tetapi mengunci tabel besar di jam paling ramai.
Tim juga perlu memastikan edisi SonarQube yang digunakan sudah sesuai dengan kebutuhan. Fitur seperti cross-file taint analysis, branch analysis, dan pull request decoration berkaitan dengan kemampuan yang tersedia pada edisi berbayar. Jika tujuan implementasi adalah memblokir pull request sebelum merge, pastikan terlebih dahulu edisi dan fitur yang dibutuhkan tersedia pada konfigurasi yang dipilih.
Strategi Implementasi SonarQube yang Berkelanjutan
- 1Jalankan analisis SonarQube pertama pada branch utama sebagai baseline, bukan sebagai target remediasi berdasarkan jumlah issue. Atur periode kode baru ke versi rilis sebelumnya, atau gunakan periode seperti 30 hari jika proses release berjalan secara kontinu.
- 2Fokuskan kondisi quality gate pada kode baru atau kode yang berubah. Metrik keseluruhan tetap dapat ditampilkan untuk memantau technical debt, tetapi tidak perlu langsung dijadikan blocker.
- 3Pastikan kebutuhan edisi dan fitur ditentukan sejak awal. Jika workflow membutuhkan analisis pull request dan mekanisme blocking sebelum merge, verifikasi edisi SonarQube yang mendukung kebutuhan tersebut. Jika analisis dilakukan setelah merge pada branch utama, tetapkan proses tindak lanjut yang jelas agar quality-gate failure segera diperbaiki.
- 4Gunakan beberapa minggu pertama untuk meninjau dan menyempurnakan quality profile. Untuk rule yang berulang kali menimbulkan perdebatan, buat keputusan yang eksplisit, yaitu mempertahankannya dengan panduan penerapan yang jelas atau menonaktifkannya jika memang tidak relevan. Konfigurasi yang jelas lebih baik daripada penggunaan komentar NOSONAR secara berlebihan yang dapat menyembunyikan alasan sebuah temuan diabaikan.
- 5Kecualikan artefak yang memang tidak relevan untuk dianalisis sebagai application source code, seperti generated client, database migration jika sesuai dengan kebutuhan proyek, vendor code, dan build output. Simpan konfigurasi tersebut di sonar-project.properties atau konfigurasi proyek yang version-controlled agar setiap perubahan tetap terlihat dalam proses code review.
- 6Gunakan SonarQube for IDE, yang sebelumnya dikenal sebagai SonarLint, dan hubungkan dengan SonarQube Server agar developer dapat menggunakan quality profile yang konsisten. Menemukan issue saat development biasanya lebih cepat dan lebih murah dibandingkan menemukannya ketika code review atau CI sudah berjalan.
Seperti Apa Implementasi SonarQube yang Berhasil
Implementasi yang berhasil tidak selalu ditandai dengan turunnya jumlah total issue secara cepat. Indikator yang lebih relevan adalah proses yang menjadi lebih konsisten, yaitu quality gate gagal karena alasan yang jelas dan dapat ditindaklanjuti, developer menerima feedback otomatis untuk masalah umum, code review dapat lebih fokus pada desain dan business logic, security hotspot mendapatkan keputusan yang jelas, dan file legacy tidak terus menambah issue ketika dimodifikasi.
Hasil akhirnya bukan codebase yang langsung bersih dalam semalam. Nilai utamanya adalah proses development yang mampu mencegah technical debt baru bertambah dengan cepat sekaligus menyediakan jalur yang terstruktur untuk memperbaiki legacy code secara bertahap.
Poin penting
- Fokuskan quality gate SonarQube pada kode baru. Issue legacy menjadi konteks untuk perencanaan technical debt, bukan target rilis langsung.
- Tetapkan target code coverage yang realistis, ukur secara konsisten, lalu tingkatkan seiring kematangan proses testing tim.
- SonarQube mengimpor laporan test coverage, bukan menghitung coverage secara langsung. Hasil 0,0% sering kali menunjukkan masalah pada path laporan atau konfigurasi scanner.
- Pastikan kebutuhan edisi SonarQube untuk pull-request analysis, fitur keamanan, dan workflow quality gate sebelum menerapkan blocking gate pada CI/CD.
