Kami ingin berkongsi pengalaman kami dalam melaksanakan platform untuk analisis berterusan dan pengukuran kualiti kod SonarQube ke dalam proses sedia ada untuk membangunkan sistem DPO (tambahan kepada sistem perakaunan depositari dan penjelasan Alameda) bagi Depositori Penyelesaian Nasional.
Depositori Penyelesaian Nasional (Kumpulan Syarikat Bursa Moscow) ialah salah satu syarikat infrastruktur kewangan utama yang menyimpan dan merekodkan sekuriti penerbit Rusia dan asing bernilai lebih daripada 50 trilion rubel. Jumlah operasi yang semakin meningkat yang dijalankan oleh sistem, serta peningkatan berterusan dalam fungsi, memerlukan mengekalkan kualiti tinggi kod sumber sistem. Salah satu alat untuk mencapai matlamat ini ialah penganalisis statik SonarQube. Dalam artikel ini, kami menerangkan pengalaman kejayaan melaksanakan penganalisis statik SonarQube dengan lancar ke dalam proses pembangunan sedia ada jabatan kami.
Secara ringkas tentang jabatan
Kecekapan kami merangkumi modul berikut: pembayaran kepada pelanggan NSD, pengurusan dokumen elektronik (EDF), pemprosesan mesej repositori perdagangan (pendaftaran transaksi luar pertukaran), saluran interaksi elektronik antara pelanggan dan NSD, dan banyak lagi. Secara umum, lapisan kerja yang besar pada bahagian teknikal operasi. Kami bekerja berdasarkan aplikasi. Permohonan juruwang diproses oleh penganalisis: mereka mengumpul keperluan pelanggan dan membentangkan kepada kami visi mereka tentang cara ia patut dimuatkan ke dalam program. Selanjutnya, skim standard: pembangunan kod - ujian - operasi percubaan - penghantaran kod ke litar produktif kepada pelanggan langsung.
Mengapa SonarQube?
Ini adalah pengalaman pertama jabatan kami dalam melaksanakan platform untuk kawalan kualiti kod - sebelum ini kami melakukannya secara manual, hanya semakan kod. Tetapi jumlah kerja yang semakin meningkat memerlukan automasi proses ini. Di samping itu, terdapat juga pekerja yang tidak berpengalaman dalam pasukan yang tidak mengetahui sepenuhnya peraturan pembangunan dalaman dan cenderung membuat lebih banyak kesilapan. Untuk mengawal kualiti kod, ia telah memutuskan untuk melaksanakan penganalisis statik. Memandangkan SonarQube telah pun digunakan dalam beberapa sistem NSD, ia tidak mengambil masa yang lama untuk memilih. Sebelum ini, rakan sekerja dari bahagian lain menggunakannya untuk menganalisis kod perkhidmatan mikro dalam sistem Alameda (sistem perakaunan depositori dan penjelasan NSD sendiri), dalam CFT (sistem maklumat untuk perakaunan, baki, penyediaan pelaporan mandatori dan dalaman), dalam beberapa yang lain. sistem . Untuk percubaan, kami memutuskan untuk bermula dengan versi percuma SonarQube. Jadi mari kita beralih kepada kes kita.
Proses pelaksanaan
Kami ada:
- pemasangan automatik sistem di TeamCity;
- sediakan proses memuat naik kod melalui MergeRequest daripada cawangan ciri ke cawangan induk dalam GitLab (proses pembangunan mengikut Aliran GitHub);
- SonarQube dikonfigurasikan untuk menganalisis kod untuk sistem DPO mengikut jadual.
Matlamat kami: melaksanakan analisis kod automatik dalam proses CI/CD AVE.
Perlu menyesuaikan: proses menyemak kod secara automatik oleh penganalisis statik dengan setiap MergeRequest ke cawangan utama.
Itu. gambar sasaran adalah seperti berikut: sebaik sahaja pembangun memuat naik perubahan pada cawangan ciri, semakan automatik untuk ralat baharu dalam kod bermula. Sekiranya tiada kesilapan, maka perubahan dibenarkan diterima, jika tidak kesilapan itu perlu diperbetulkan. Sudah pada peringkat awal, kami dapat mengenal pasti beberapa ralat dalam kod. Sistem ini mempunyai tetapan yang sangat fleksibel: ia boleh dikonfigurasikan sedemikian rupa sehingga ia berfungsi untuk tugas khusus pembangun, untuk setiap sistem dan gaya pengaturcaraan.
Mengkonfigurasi QualityGate dalam SonarQube
Analisis QualityGate ialah perkara yang kita baca dalam isi perut Internet. Pada mulanya, kami menggunakan pendekatan yang berbeza, lebih kompleks dan, dalam beberapa cara, tidak betul sepenuhnya. Mula-mula, kami menjalankan imbasan melalui SonarQube dua kali: kami mengimbas cawangan ciri dan cawangan tempat kami akan menggabungkan cawangan ciri, dan kemudian kami membandingkan bilangan ralat. Kaedah ini tidak stabil dan tidak selalu memberikan hasil yang betul. Dan kemudian kami mengetahui bahawa daripada menjalankan SonarQube dua kali, anda boleh menetapkan had pada bilangan ralat yang dibuat (QualityGate) dan menganalisis hanya cawangan yang anda muat naik dan bandingkan.
Buat masa ini, kami masih menggunakan semakan kod yang agak primitif. Perlu diingatkan bahawa SonarQube tidak serasi dengan beberapa bahasa pengaturcaraan, termasuk Delphi. Pada masa ini, untuk sistem kami, kami hanya menganalisis kod PLSql.
Ia berfungsi seperti ini:
- Kami menganalisis hanya kod PL/SQL untuk projek kami.
- QualityGate dikonfigurasikan dalam SonarQube supaya bilangan ralat tidak meningkat dengan komit.
- Bilangan ralat pada larian pertama ialah 229. Jika terdapat lebih banyak ralat semasa komit, maka gabungan tidak dibenarkan.
- Selanjutnya, tertakluk kepada pembetulan ralat, adalah mungkin untuk mengkonfigurasi semula QualityGate.
- Anda juga boleh menambah item baharu untuk analisis, contohnya, liputan kod dengan ujian, dsb.
Skim kerja:
Dalam ulasan skrip, anda dapat melihat bahawa bilangan ralat dalam cawangan ciri tidak meningkat. Jadi semuanya OK.
Butang Gabung menjadi tersedia.
Dalam ulasan skrip, anda dapat melihat bahawa bilangan ralat dalam cabang ciri telah menjadi lebih daripada yang dibenarkan. Jadi semuanya BURUK.
Butang Gabung berwarna merah. Pada masa ini, tiada larangan untuk memuat naik perubahan kepada kod yang salah, tetapi ini dilakukan mengikut budi bicara pembangun yang bertanggungjawab. Pada masa hadapan, anda boleh menghalang komitmen sedemikian daripada dibuat ke cawangan utama.
Berurusan sendiri dengan pepijat
Seterusnya, anda perlu menyemak semua ralat yang dikesan oleh sistem, kerana SonarQube menganalisis mengikut piawaian yang ketat. Apa yang dia anggap sebagai ralat mungkin sebenarnya bukan salah dalam kod kami. Oleh itu, anda perlu menyemak dan ambil perhatian sama ada ini benar-benar satu kesilapan, atau sama ada tidak perlu mengedit dalam keadaan kami. Oleh itu, kami mengurangkan bilangan ralat. Dari masa ke masa, sistem akan belajar memahami nuansa ini.
Apa yang telah kita datangi
Matlamat kami adalah untuk memahami sama ada suai manfaat dalam kes kami untuk memindahkan pengesahan kod kepada automasi. Dan hasilnya menepati jangkaan. SonarQube membolehkan kami bekerja dengan bahasa yang kami perlukan, melakukan analisis yang cukup cekap, dan berpotensi untuk belajar daripada petua pembangun. Secara umum, kami gembira dengan pengalaman pertama kami dengan SonarQube dan merancang untuk mengembangkan lagi ke arah ini. Kami menjangkakan bahawa pada masa hadapan kami akan dapat menjimatkan lebih banyak masa dan usaha pada semakan kod dan menjadikannya lebih baik dengan menghapuskan faktor manusia. Mungkin dalam proses itu kami akan menemui kelemahan platform, atau, sebaliknya, kami akan memastikan sekali lagi bahawa ini adalah perkara yang hebat dengan potensi yang besar.
Dalam artikel gambaran keseluruhan ini, kami bercakap tentang perkenalan kami dengan penganalisis statik SonarQube. Jika anda mempunyai soalan, sila tulis dalam komen. Jika anda berminat dengan topik ini, dalam penerbitan baharu kami akan menerangkan dengan lebih terperinci cara menetapkan semuanya dengan betul dan menulis kod untuk melakukan pemeriksaan sedemikian.
Pengarang teks:
Sumber: www.habr.com