როგორ განვახორციელეთ SonarQube და გავაცნობიერეთ მისი დიდი პოტენციალი

ჩვენ გვინდა გავუზიაროთ SonarQube პლატფორმის დანერგვის გამოცდილება უწყვეტი ანალიზისა და კოდის ხარისხის გაზომვისთვის DPO სისტემის (დამატება Alameda-ს დეპოზიტარისა და კლირინგული აღრიცხვის სისტემის დამატებით) განვითარების ეროვნულ საანგარიშსწორებო დეპოზიტარის განვითარების პროცესებში.

ეროვნული ანგარიშსწორების დეპოზიტარი (კომპანიების მოსკოვის ბირჟის ჯგუფი) არის ფინანსური ინფრასტრუქტურის ერთ-ერთი მთავარი კომპანია, რომელიც ინახავს და აღრიცხავს რუსული და უცხოური ემიტენტების ფასიანი ქაღალდების 50 ტრილიონ რუბლზე მეტი ღირებულების. სისტემის მიერ განხორციელებული ოპერაციების მზარდი მოცულობა, ისევე როგორც ფუნქციონირების უწყვეტი გაფართოება, მოითხოვს სისტემის მაღალი ხარისხის წყაროს კოდის შენარჩუნებას. ამ მიზნის მისაღწევად ერთ-ერთი ინსტრუმენტია SonarQube სტატიკური ანალიზატორი. ამ სტატიაში ჩვენ აღვწერთ SonarQube სტატიკური ანალიზატორის შეუფერხებლად დანერგვის წარმატებულ გამოცდილებას ჩვენი დეპარტამენტის განვითარების არსებულ პროცესებში.

მოკლედ განყოფილების შესახებ

ჩვენი კომპეტენცია მოიცავს შემდეგ მოდულებს: გადახდები NSD კლიენტებისთვის, ელექტრონული დოკუმენტების მართვა (EDF), სავაჭრო საცავის შეტყობინებების დამუშავება (აბსტრაქტული ტრანზაქციების რეგისტრაცია), კლიენტებსა და NSD-ს შორის ელექტრონული ურთიერთქმედების არხები და მრავალი სხვა. ზოგადად, საოპერაციო საქმიანობის ტექნიკურ მხარეზე ბევრი სამუშაოა გასაკეთებელი. ჩვენ ვმუშაობთ მოთხოვნის საფუძველზე. ოპერაციული ოფიცრების განაცხადებს ანალიტიკოსები ამუშავებენ: ისინი აგროვებენ მომხმარებლის მოთხოვნებს და წარმოგვიდგენენ თავიანთ ხედვას, თუ როგორ უნდა მოერგოს ის პროგრამას. შემდეგი არის სტანდარტული სქემა: კოდის შემუშავება - ტესტირება - საცდელი ოპერაცია - კოდის მიწოდება წარმოების წრეში უშუალო მომხმარებლისთვის.

რატომ SonarQube?

ეს არის ჩვენი განყოფილების პირველი გამოცდილება კოდის ხარისხის კონტროლის პლატფორმის დანერგვაში - ადრე ამას ხელით ვაკეთებდით, მხოლოდ კოდის მიმოხილვას ვაკეთებდით. მაგრამ სამუშაოს მზარდი მოცულობა მოითხოვს ამ პროცესის ავტომატიზაციას. გარდა ამისა, გუნდში ასევე შედიან გამოუცდელი თანამშრომლები, რომლებიც ბოლომდე არ იცნობენ შიდა განვითარების რეგულაციებს და უფრო მეტი შეცდომის დაშვების ტენდენცია აქვთ. კოდის ხარისხის გასაკონტროლებლად გადაწყდა სტატიკური ანალიზატორის დანერგვა. ვინაიდან SonarQube უკვე გამოიყენებოდა ზოგიერთ NSD სისტემაში, დიდი არჩევანი არ იყო. ადრე სხვა დეპარტამენტების კოლეგები მას იყენებდნენ მიკროსერვისების კოდის გასაანალიზებლად Alameda სისტემაში (NSD-ის საკუთარი სადეპოზიტო და სააღრიცხვო აღრიცხვის სისტემა), CFT-ში (საინფორმაციო სისტემა ბუღალტრული აღრიცხვის, ბალანსების, სავალდებულო და შიდა ანგარიშგების მომზადებისთვის) ზოგიერთში. სხვა სისტემები. ექსპერიმენტებისთვის გადავწყვიტეთ დაგვეწყო SonarQube-ის უფასო ვერსიით. ასე რომ, გადავიდეთ ჩვენს საქმეზე.

განხორციელების პროცესი

Ჩვენ გვაქვს:

• სისტემის ავტომატური აწყობა TeamCity-ში;
• დაკონფიგურირებულია MergeRequest-ის საშუალებით კოდის ატვირთვის პროცესი GitLab-ის ფუნქციების ფილიალიდან მთავარ ფილიალში (განვითარების პროცესი GitHub Flow-ის მიხედვით);
• SonarQube, კონფიგურირებულია DPO სისტემის კოდის გასაანალიზებლად გრაფიკის მიხედვით.

Ჩვენი მიზანი: კოდის ავტომატური ანალიზის განხორციელება DPO-ის CI/CD პროცესებში.

საჭიროა კონფიგურაცია: კოდის ავტომატურად შემოწმების პროცესი სტატიკური ანალიზატორით ყოველი MergeRequest მთავარ ფილიალში.

იმათ. სამიზნე სურათი ასეთია: როგორც კი დეველოპერი ატვირთავს ცვლილებებს ფუნქციების ფილიალში, იწყება კოდის ახალი შეცდომების ავტომატური შემოწმება. თუ შეცდომები არ არის, მაშინ ცვლილებების მიღება დაშვებულია, წინააღმდეგ შემთხვევაში, შეცდომები უნდა გამოსწორდეს. უკვე საწყის ეტაპზე ჩვენ შევძელით კოდში გარკვეული რაოდენობის შეცდომების დადგენა. სისტემას აქვს ძალიან მოქნილი პარამეტრები: მისი კონფიგურაცია შესაძლებელია ისე, რომ მუშაობს დეველოპერების კონკრეტული ამოცანებისთვის, თითოეული სისტემისთვის და პროგრამირების სტილისთვის.

QualityGate-ის დაყენება SonarQube-ში

QualityGate ანალიზი არის ის, რასაც ვკითხულობთ ინტერნეტის სიღრმეში. თავდაპირველად, ჩვენ ვიყენებდით განსხვავებულ მიდგომას, უფრო რთულ და, გარკვეულწილად, მთლად სწორი. პირველ რიგში, ჩვენ ორჯერ ჩავატარეთ სკანირება SonarQube-ის საშუალებით: ჩვენ დავასკანირეთ ფუნქციების ფილიალი და ის ფილიალი, სადაც ვაპირებდით ფუნქციების ფილიალის გაერთიანებას, შემდეგ კი შევადარეთ შეცდომების რაოდენობა. ეს მეთოდი არ იყო სტაბილური და ყოველთვის არ აძლევდა სწორ შედეგს. შემდეგ კი გავარკვიეთ, რომ SonarQube-ის ორჯერ გაშვების ნაცვლად, შეგვიძლია დავაწესოთ დაშვებული შეცდომების რაოდენობა (QualityGate) და გავაანალიზოთ მხოლოდ ის ფილიალი, რომელსაც ატვირთავთ და შევადარებთ.

ამჟამად ჩვენ კვლავ ვიყენებთ საკმაოდ პრიმიტიულ კოდის მიმოხილვას. აღსანიშნავია, რომ SonarQube არ არის თავსებადი პროგრამირების ზოგიერთ ენასთან, მათ შორის Delphi-სთან. ამ დროისთვის, ჩვენ ვაანალიზებთ მხოლოდ PLSql კოდს ჩვენი სისტემისთვის.

მუშაობს ასე:

• ჩვენ ვაანალიზებთ მხოლოდ PL/SQL კოდს ჩვენი პროექტისთვის.
• SonarQube-ს აქვს QualityGate კონფიგურირებული ისე, რომ შეცდომების რაოდენობა არ გაიზარდოს ჩადენისას.
• შეცდომების რაოდენობა პირველი გაშვებისას იყო 229. თუ დაშვების დროს მეტი შეცდომაა, მაშინ შერწყმა დაუშვებელია.
• გარდა ამისა, თუ შეცდომები გამოსწორდება, შესაძლებელი იქნება QualityGate-ის ხელახლა კონფიგურაცია.
• თქვენ ასევე შეგიძლიათ დაამატოთ ახალი ქულები ანალიზისთვის, მაგალითად, კოდის დაფარვა ტესტებით და ა.შ.

მუშაობის სქემა:

სკრიპტის კომენტარები აჩვენებს, რომ ფუნქციების ფილიალში შეცდომების რაოდენობა არ გაიზარდა. ასე რომ, ყველაფერი წესრიგშია.

შერწყმის ღილაკი ხელმისაწვდომი ხდება.

სკრიპტის კომენტარებში ხედავთ, რომ ფუნქციების ფილიალში შეცდომების რაოდენობა უფრო მისაღები გახდა. ასე რომ ყველაფერი ცუდია.

შერწყმის ღილაკი წითელია. ამ დროისთვის, არ არის აკრძალული ცვლილებების ატვირთვა არასწორი კოდის საფუძველზე, მაგრამ ეს კეთდება პასუხისმგებელი დეველოპერის შეხედულებისამებრ. მომავალში, თქვენ შეგიძლიათ თავიდან აიცილოთ ასეთი ვალდებულებების მთავარ ფილიალში დამატება.

შეცდომებზე დამოუკიდებელი მუშაობა

შემდეგი, თქვენ უნდა შეამოწმოთ სისტემის მიერ აღმოჩენილი ყველა შეცდომა, რადგან SonarQube აანალიზებს მისი მკაცრი სტანდარტების მიხედვით. ის, რასაც ის შეცდომად მიიჩნევს, შეიძლება რეალურად არ იყოს ჩვენს კოდში. ამიტომ, თქვენ უნდა შეამოწმოთ და გაითვალისწინოთ, არის თუ არა ეს ნამდვილად შეცდომა, ან არ არის საჭირო ჩვენს პირობებში რედაქტირება. ამ გზით ჩვენ შევამცირებთ შეცდომების რაოდენობას. დროთა განმავლობაში სისტემა ისწავლის ამ ნიუანსების გაგებას.

რა მივედით

ჩვენი მიზანი იყო გაგვეგო, მიზანშეწონილი იქნებოდა თუ არა ჩვენს შემთხვევაში კოდის მიმოხილვის ავტომატიზაციაზე გადატანა. და შედეგმა გაამართლა მოლოდინი. SonarQube საშუალებას გვაძლევს ვიმუშაოთ ჩვენთვის საჭირო ენებთან, აკეთებს საკმაოდ კომპეტენტურ ანალიზს და აქვს პოტენციალი ვისწავლოთ დეველოპერის რჩევებიდან. საერთო ჯამში, ჩვენ კმაყოფილი ვართ SonarQube-ის გამოყენებით ჩვენი პირველი გამოცდილებით და ვგეგმავთ შემდგომ განვითარებას ამ მიმართულებით. ჩვენ ველით, რომ მომავალში ჩვენ შევძლებთ დაზოგოთ მეტი დრო და ძალისხმევა კოდის განხილვაზე და გავაუმჯობესოთ ის ადამიანური ფაქტორის აღმოფხვრის გზით. შესაძლოა ამ პროცესში აღმოვაჩინოთ პლატფორმის ნაკლოვანებები ან, პირიქით, კიდევ ერთხელ დავრწმუნდეთ, რომ ეს არის მაგარი რამ დიდი პოტენციალით.

ამ მიმოხილვის სტატიაში ვისაუბრეთ SonarQube სტატიკური ანალიზატორის გაცნობაზე. თუ თქვენ გაქვთ შეკითხვები, გთხოვთ დაწეროთ კომენტარებში. თუ თქვენ დაინტერესებული ხართ ამ თემით, ახალ პუბლიკაციაში უფრო დეტალურად აღვწერთ, თუ როგორ უნდა დააყენოთ ყველაფერი სწორად და დავწეროთ კოდი ასეთი შემოწმების გასაკეთებლად.

ტექსტის ავტორი: ატანა

წყარო: www.habr.com