Cara Menerapkan SonarQube di Tim Development Tanpa Bikin Tim Frustrasi

Banyak tim memulai SonarQube dengan cara yang sama: scanner dipasang di pipeline CI/CD, lalu analisis pertama dijalankan. Hasilnya sering bikin kaget, misalnya 3.800 issue dan coverage 11% di aplikasi yang sudah bertahun-tahun jalan di production. Kalau semua temuan itu langsung dianggap pekerjaan yang harus dibereskan, tim cepat kewalahan, dan beberapa bulan kemudian SonarQube cuma jadi dashboard yang tidak dibuka lagi.

Jangan Jadikan Jumlah Issue Awal sebagai Target

3.800 issue itu adalah tumpukan keputusan teknis selama bertahun-tahun, termasuk keputusan yang diambil karena deadline dan kebutuhan bisnis waktu itu. Membereskan semuanya dalam waktu singkat tidak realistis. Menulis ulang kode production yang sudah stabil tanpa test yang memadai juga berisiko memunculkan bug baru. Jadi sejak awal, pisahkan technical debt lama dari masalah yang muncul di kode baru.

Target yang tidak masuk akal juga membuat tim berhenti percaya pada quality gate. Kalau status merah sudah jadi hal biasa yang selalu diabaikan, peringatan dari SonarQube ikut diabaikan, termasuk saat ada bug atau celah keamanan yang memang harus segera ditangani.

Fokuskan Quality Gate ke Kode Baru

SonarQube menyebut pendekatan ini Clean as You Code. Quality gate hanya menilai kode yang baru ditambahkan atau diubah. Batas "kode baru" bisa diatur sejak versi rilis sebelumnya, dalam jangka waktu tertentu seperti 30 hari, atau sejak analisis tertentu. Issue di kode lama tetap terlihat sebagai bahan perencanaan technical debt, tapi tidak menghalangi pekerjaan development yang sedang berjalan.

Contohnya, file berumur empat tahun dengan 40 issue tidak otomatis masuk ke sprint. Yang dinilai hanya 60 baris yang baru ditulis atau diubah. Technical debt dikurangi sedikit demi sedikit di bagian yang memang sedang dikerjakan, saat developer sedang paham konteksnya dan bisa sekalian menambah test.

Tips: tampilkan metrik kode baru di dashboard tim, dan sembunyikan dulu angka total issue selama bulan pertama. Diskusi tim jadi fokus ke kode yang sedang ditulis.

Cara Mengatur Quality Gate SonarQube

Quality gate bawaan Sonar way bisa jadi titik awal, tapi setiap kondisinya perlu disesuaikan dengan kondisi tim. Target coverage 80% untuk kode baru mungkin cocok untuk tim yang sudah terbiasa menulis test. Di codebase dengan coverage 11%, target setinggi itu akan membuat hampir semua pull request gagal, dan tim akhirnya mencari cara untuk melewatinya. Quality gate hanya berguna kalau tim memang menjalankannya.

Cara SonarQube Membaca Test Coverage

Bagian ini paling sering disalahpahami. SonarQube tidak menjalankan test dan tidak menghitung coverage sendiri. SonarQube hanya membaca laporan coverage yang dihasilkan oleh proses build dan test. Kalau path laporannya belum diatur dengan benar, dashboard akan menunjukkan coverage 0,0% padahal test-nya ada dan berjalan.

• Java dan Kotlin memakai laporan XML JaCoCo, lewat sonar.coverage.jacoco.xmlReportPaths.
• JavaScript dan TypeScript memakai lcov.info, lewat sonar.javascript.lcov.reportPaths.
• Go memakai hasil go test -coverprofile, lewat sonar.go.coverage.reportPaths.
• PHP memakai laporan Clover XML, lewat sonar.php.coverage.reportPaths.
• Python memakai coverage.xml, lewat sonar.python.coverage.reportPaths.
• Untuk .NET, jalankan scanner MSBuild dalam tahap begin dan end, lalu berikan hasil OpenCover atau dotnet-coverage.

Laporan coverage harus ada di tempat scanner berjalan. Bisa dihasilkan di job yang sama, atau disalin dulu sebelum analisis dimulai. Kalau laporannya ada di runner lain atau path-nya salah, SonarQube tidak bisa membacanya, dan hasilnya kembali 0,0%.

Yang Bisa dan Tidak Bisa Ditemukan SonarQube

SonarQube sangat membantu untuk menemukan pola masalah yang sulit dicek konsisten lewat code review manual. Contohnya resource yang tidak ditutup, exception yang ditangkap lalu diabaikan, implementasi equals dan hashCode yang salah, regular expression yang berpotensi lambat, password yang tersimpan di file konfigurasi, dan query SQL yang dirakit dengan menggabungkan string.

Tapi static analysis ada batasnya. SonarQube mengenali pola di kode, tapi tidak memahami aturan bisnis atau kondisi saat aplikasi berjalan. Beberapa jenis bug tetap butuh orang yang paham bisnisnya, integration test, dan pengujian langsung.

• Aturan diskon yang memakai persentase yang salah. Kodenya bersih, hasilnya tetap salah.
• Endpoint yang lupa mengecek otorisasi, padahal kode di sekitarnya terlihat normal.
• Race condition yang baru muncul saat banyak request datang bersamaan.
• Migrasi dengan SQL yang benar, tapi mengunci tabel besar di jam paling ramai.

Cek juga edisi SonarQube yang dipakai. Fitur seperti taint analysis lintas file, analisis branch, dan komentar otomatis di pull request ada di edisi berbayar. Kalau rencananya memblokir pull request sebelum merge, pastikan dulu edisi yang dipakai mendukungnya.

Langkah Penerapan SonarQube

1. 1Jalankan analisis pertama di branch utama sebagai baseline. Hasilnya dipakai untuk melihat kondisi awal, tidak untuk dijadikan target perbaikan. Atur periode kode baru ke versi rilis sebelumnya, atau 30 hari kalau tim rilis terus-menerus.
2. 2Arahkan kondisi quality gate ke kode baru atau kode yang berubah. Metrik keseluruhan tetap ditampilkan untuk memantau technical debt, tapi tidak dijadikan blocker.
3. 3Tentukan kebutuhan edisi dari awal. Kalau alur kerja tim butuh analisis pull request dan blokir sebelum merge, pastikan edisinya mendukung. Kalau analisis baru jalan setelah merge ke branch utama, sepakati siapa yang memperbaiki dan seberapa cepat kalau quality gate gagal.
4. 4Pakai beberapa minggu pertama untuk merapikan quality profile. Untuk rule yang terus diperdebatkan, ambil keputusan yang jelas: dipertahankan dengan panduan penerapannya, atau dimatikan kalau memang tidak relevan. Cara ini lebih baik daripada menaburkan komentar NOSONAR di mana-mana tanpa alasan yang tercatat.
5. 5Kecualikan file yang tidak perlu dianalisis, seperti client hasil generate, migrasi database kalau memang sesuai, kode vendor, dan hasil build. Simpan pengaturannya di sonar-project.properties atau file konfigurasi lain di repository, supaya setiap perubahan ikut di-review.
6. 6Pasang SonarQube for IDE (dulu bernama SonarLint) dan hubungkan ke SonarQube Server, supaya developer memakai quality profile yang sama sejak menulis kode. Masalah yang ketahuan di editor jauh lebih cepat diperbaiki daripada yang baru ketahuan saat code review atau di CI.

Tanda Penerapannya Berjalan

Penerapan yang berhasil tidak selalu terlihat dari jumlah total issue yang turun cepat. Tandanya lebih terlihat di cara kerja tim. Quality gate gagal karena alasan yang jelas dan bisa langsung diperbaiki. Developer dapat feedback otomatis untuk masalah umum, sehingga code review bisa fokus ke desain dan logika bisnis. Setiap security hotspot punya keputusan, dan file lama tidak bertambah issue-nya setiap kali disentuh.

Codebase-nya memang tidak langsung bersih dalam semalam. Yang didapat adalah proses yang mencegah technical debt baru terus bertambah, ditambah jalur yang jelas untuk membereskan kode lama sedikit demi sedikit.