Kami ingin membagikan pengalaman kami dalam menerapkan platform untuk analisis berkelanjutan dan pengukuran kualitas kode SonarQube ke dalam proses yang ada untuk mengembangkan sistem DPO (tambahan sistem akuntansi penyimpanan dan kliring Alameda) dari National Settlement Depository.
National Settlement Depository (Moscow Exchange Group of Companies) adalah salah satu perusahaan infrastruktur keuangan utama yang menyimpan dan mencatat sekuritas penerbit Rusia dan asing senilai lebih dari 50 triliun rubel. Pertumbuhan volume operasi yang dilakukan oleh sistem, serta peningkatan fungsionalitas yang berkelanjutan, membutuhkan pemeliharaan kualitas tinggi dari kode sumber sistem. Salah satu alat untuk mencapai tujuan ini adalah penganalisa statis SonarQube. Dalam artikel ini, kami menjelaskan pengalaman sukses menerapkan penganalisis statis SonarQube dengan mulus ke dalam proses pengembangan yang ada di departemen kami.
Secara singkat tentang departemen
Kompetensi kami mencakup modul-modul berikut: pembayaran ke klien NSD, manajemen dokumen elektronik (EDF), pemrosesan pesan repositori perdagangan (pendaftaran transaksi off-exchange), saluran interaksi elektronik antara klien dan NSD, dan banyak lagi. Secara umum, lapisan besar pekerjaan di sisi teknis operasi. Kami bekerja berdasarkan aplikasi. Aplikasi teller diproses oleh analis: mereka mengumpulkan persyaratan pelanggan dan menyampaikan kepada kami visi mereka tentang bagaimana hal itu harus sesuai dengan program. Selanjutnya, skema standar: pengembangan kode - pengujian - operasi percobaan - pengiriman kode ke sirkuit produktif ke pelanggan langsung.
Mengapa SonarQube?
Ini adalah pengalaman pertama departemen kami dalam mengimplementasikan platform untuk kontrol kualitas kode - sebelumnya kami melakukannya secara manual, hanya meninjau kode. Tetapi volume pekerjaan yang terus meningkat membutuhkan otomatisasi proses ini. Selain itu, ada juga karyawan yang tidak berpengalaman dalam tim yang tidak sepenuhnya memahami peraturan pengembangan internal dan cenderung melakukan lebih banyak kesalahan. Untuk mengontrol kualitas kode, diputuskan untuk mengimplementasikan penganalisa statis. Karena SonarQube telah digunakan di beberapa sistem NSD, tidak butuh waktu lama untuk memilih. Sebelumnya, kolega dari divisi lain menggunakannya untuk menganalisis kode layanan mikro di sistem Alameda (sistem akuntansi penyimpanan dan kliring NSD sendiri), di CFT (sistem informasi untuk akuntansi, saldo, penyusunan pelaporan wajib dan internal), di beberapa lainnya sistem . Untuk eksperimen, kami memutuskan untuk memulai dengan SonarQube versi gratis. Jadi mari kita beralih ke kasus kita.
Proses implementasi
Kita punya:
- perakitan otomatis sistem di TeamCity;
- mengatur proses pengunggahan kode melalui MergeRequest dari cabang fitur ke cabang master di GitLab (proses pengembangan menurut Aliran GitHub);
- SonarQube dikonfigurasi untuk menganalisis kode untuk sistem DPO sesuai jadwal.
Tujuan kita: menerapkan analisis kode otomatis dalam proses CI/CD AVE.
Perlu menyesuaikan: proses pengecekan kode secara otomatis oleh penganalisa statis dengan setiap MergeRequest ke cabang utama.
Itu. gambar targetnya adalah sebagai berikut: segera setelah pengembang mengunggah perubahan ke cabang fitur, pemeriksaan otomatis untuk kesalahan baru dalam kode dimulai. Jika tidak ada kesalahan, maka perubahan diperbolehkan untuk diterima, jika tidak, kesalahan harus diperbaiki. Sudah pada tahap awal, kami dapat mengidentifikasi sejumlah kesalahan dalam kode. Sistem ini memiliki pengaturan yang sangat fleksibel: dapat dikonfigurasi sedemikian rupa sehingga berfungsi untuk tugas pengembang tertentu, untuk setiap sistem dan gaya pemrograman.
Mengonfigurasi QualityGate di SonarQube
Analisis QualityGate adalah hal yang kita baca di perut Internet. Awalnya, kami menggunakan pendekatan yang berbeda, lebih kompleks dan, dalam beberapa hal, tidak sepenuhnya benar. Pertama, kami menjalankan pemindaian melalui SonarQube dua kali: kami memindai cabang fitur dan cabang tempat kami akan menggabungkan cabang fitur, lalu kami membandingkan jumlah kesalahan. Metode ini tidak stabil dan tidak selalu memberikan hasil yang benar. Dan kemudian kami mengetahui bahwa alih-alih menjalankan SonarQube dua kali, Anda dapat menetapkan batas jumlah kesalahan yang dibuat (QualityGate) dan hanya menganalisis cabang yang Anda unggah dan bandingkan.
Untuk saat ini, kami masih menggunakan pemeriksaan kode yang agak primitif. Perlu dicatat bahwa SonarQube tidak kompatibel dengan beberapa bahasa pemrograman, termasuk Delphi. Saat ini, untuk sistem kami, kami hanya menganalisis kode PLSql.
Ini bekerja seperti ini:
- Kami hanya menganalisis kode PL/SQL untuk proyek kami.
- QualityGate dikonfigurasi di SonarQube sehingga jumlah kesalahan tidak bertambah dengan komit.
- Jumlah kesalahan saat dijalankan pertama adalah 229. Jika ada lebih banyak kesalahan selama komit, maka penggabungan tidak diperbolehkan.
- Selanjutnya, tunduk pada koreksi kesalahan, dimungkinkan untuk mengkonfigurasi ulang QualityGate.
- Anda juga dapat menambahkan item baru untuk analisis, misalnya cakupan kode dengan pengujian, dll.
Skema kerja:
Di komentar skrip, Anda dapat melihat bahwa jumlah kesalahan di cabang fitur tidak bertambah. Jadi semuanya baik-baik saja.
Tombol Gabung menjadi tersedia.
Di komentar skrip, Anda dapat melihat bahwa jumlah kesalahan di cabang fitur menjadi lebih dari yang diizinkan. Jadi semuanya BURUK.
Tombol Gabung berwarna merah. Saat ini, tidak ada larangan mengunggah perubahan pada kode yang salah, tetapi ini dilakukan atas kebijaksanaan pengembang yang bertanggung jawab. Di masa mendatang, Anda dapat mencegah komitmen tersebut dibuat ke cabang utama.
Berurusan sendiri dengan bug
Selanjutnya, Anda perlu memeriksa semua kesalahan yang terdeteksi oleh sistem, karena SonarQube menganalisis sesuai dengan standarnya yang ketat. Apa yang dia anggap sebagai kesalahan mungkin sebenarnya bukan kesalahan dalam kode kita. Oleh karena itu, Anda perlu memeriksa dan mencatat apakah ini benar-benar kesalahan, atau tidak perlu diedit dalam ketentuan kami. Dengan demikian, kami mengurangi jumlah kesalahan. Seiring waktu, sistem akan belajar memahami nuansa ini.
Apa yang telah kita datangi
Tujuan kami adalah untuk memahami apakah perlu untuk mentransfer verifikasi kode ke otomatisasi dalam kasus kami. Dan hasilnya sesuai ekspektasi. SonarQube memungkinkan kami untuk bekerja dengan bahasa yang kami butuhkan, melakukan analisis yang cukup kompeten, dan memiliki potensi untuk belajar dari tip pengembang. Secara umum, kami senang dengan pengalaman pertama kami dengan SonarQube dan berencana untuk mengembangkan lebih jauh ke arah ini. Kami berharap di masa mendatang kami akan dapat menghemat lebih banyak waktu dan tenaga dalam peninjauan kode dan membuatnya lebih baik dengan menghilangkan faktor manusia. Mungkin dalam prosesnya kami akan menemukan kekurangan platform, atau sebaliknya, kami akan memastikan sekali lagi bahwa ini adalah hal keren dengan potensi besar.
Dalam artikel ikhtisar ini, kami berbicara tentang kenalan kami dengan penganalisa statis SonarQube. Jika ada pertanyaan, silahkan tulis di komentar. Jika Anda tertarik dengan topik ini, dalam publikasi baru kami akan menjelaskan lebih detail cara mengatur semuanya dengan benar dan menulis kode untuk melakukan pemeriksaan semacam itu.
Penulis teks:
Sumber: www.habr.com