چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

ما می خواهیم تجربه خود را از پیاده سازی بستری برای تجزیه و تحلیل مستمر و اندازه گیری کیفیت کد SonarQube در فرآیندهای موجود برای توسعه سیستم DPO (افزودنی به سیستم سپرده گذاری و تسویه حسابداری Alameda) سپرده گذاری تسویه ملی به اشتراک بگذاریم.

سپرده گذاری تسویه ملی (گروه شرکت های بورس مسکو) یکی از شرکت های کلیدی زیرساخت مالی است که اوراق بهادار ناشران روسی و خارجی را به ارزش بیش از 50 تریلیون روبل ذخیره و ثبت می کند. حجم فزاینده عملیات انجام شده توسط سیستم و همچنین افزایش مداوم عملکرد، مستلزم حفظ کیفیت بالای کد منبع سیستم ها است. یکی از ابزارهای دستیابی به این هدف، تحلیلگر استاتیک SonarQube است. در این مقاله، ما تجربه موفقیت آمیز پیاده سازی یکپارچه تحلیلگر استاتیک SonarQube را در فرآیندهای توسعه موجود در بخش خود شرح می دهیم.

مختصری در مورد بخش

صلاحیت ما شامل ماژول های زیر است: پرداخت به مشتریان NSD، مدیریت اسناد الکترونیکی (EDF)، پردازش پیام های مخزن تجارت (ثبت تراکنش های خارج از بورس)، کانال های تعامل الکترونیکی بین مشتریان و NSD، و موارد دیگر. به طور کلی، یک لایه بزرگ از کار در سمت فنی عملیات. ما بر اساس برنامه های کاربردی کار می کنیم. کاربردهای باجه ها توسط تحلیلگران پردازش می شوند: آنها خواسته های مشتری را جمع آوری می کنند و دیدگاه خود را در مورد اینکه چگونه باید در برنامه قرار گیرد را به ما ارائه می دهند. علاوه بر این، طرح استاندارد: توسعه کد - آزمایش - عملیات آزمایشی - تحویل کد به مدار تولیدی به مشتری مستقیم.

چرا SonarQube؟

این اولین تجربه بخش ما در پیاده سازی یک پلتفرم برای کنترل کیفیت کد است - قبلاً ما آن را به صورت دستی و فقط بررسی کد انجام می دادیم. اما حجم رو به رشد کار مستلزم اتوماسیون این فرآیند است. علاوه بر این، کارمندان بی‌تجربه‌ای نیز در تیم وجود دارند که کاملاً با مقررات توسعه داخلی آشنا نیستند و تمایل به اشتباهات بیشتری دارند. برای کنترل کیفیت کد تصمیم گرفته شد که یک تحلیلگر استاتیک پیاده سازی شود. از آنجایی که SonarQube قبلاً در برخی از سیستم‌های NSD استفاده شده است، انتخاب آن طولی نکشید. قبلاً، همکاران سایر بخش‌ها از آن برای تجزیه و تحلیل کد ریزخدمات در سیستم Alameda (سیستم حسابداری سپرده‌گذاری و تسویه حساب NSD)، در CFT (سیستم اطلاعاتی برای حسابداری، تعادل، تهیه گزارش‌های اجباری و داخلی)، در برخی دیگر از آن استفاده می‌کردند. سیستم ها . برای آزمایش، تصمیم گرفتیم با نسخه رایگان SonarQube شروع کنیم. پس بیایید به پرونده خودمان بپردازیم.

روند اجرا

ما داریم:

  • مونتاژ خودکار سیستم در TeamCity.
  • فرآیند آپلود کد را از طریق MergeRequest از شاخه ویژگی به شاخه اصلی در GitLab تنظیم کنید (فرایند توسعه مطابق GitHub Flow).
  • SonarQube پیکربندی شده است تا کد سیستم DPO را طبق برنامه تجزیه و تحلیل کند.

هدف ما: پیاده سازی تجزیه و تحلیل کد خودکار در فرآیندهای CI/CD AVE.

نیاز به سفارشی سازی: فرآیند بررسی خودکار کد توسط یک تحلیلگر استاتیک با هر MergeRequest به شعبه اصلی.

آن ها تصویر هدف به شرح زیر است: به محض آپلود تغییرات توسط توسعه دهنده در شاخه ویژگی، بررسی خودکار خطاهای جدید در کد شروع می شود. اگر خطایی وجود نداشته باشد، تغییرات مجاز به پذیرش هستند، در غیر این صورت خطاها باید اصلاح شوند. از قبل در مرحله اولیه، ما توانستیم تعداد مشخصی از خطاها را در کد شناسایی کنیم. این سیستم تنظیمات بسیار انعطاف پذیری دارد: می توان آن را به گونه ای پیکربندی کرد که برای وظایف خاص توسعه دهندگان، برای هر سیستم و سبک برنامه نویسی کار کند.

پیکربندی QualityGate در SonarQube

تجزیه و تحلیل QualityGate چیزی است که ما در بطن اینترنت می خوانیم. در ابتدا، ما از رویکرد متفاوتی استفاده کردیم، پیچیده تر و از برخی جهات کاملاً صحیح نبود. ابتدا، دوبار اسکن را از طریق SonarQube اجرا کردیم: شاخه ویژگی و شاخه ای را که قرار بود شاخه ویژگی را ادغام کنیم، اسکن کردیم و سپس تعداد خطاها را با هم مقایسه کردیم. این روش پایدار نبود و همیشه نتیجه درستی نمی داد. و سپس متوجه شدیم که به جای اجرای دوبار SonarQube، می توانید محدودیتی برای تعداد خطاهای ایجاد شده (QualityGate) تعیین کنید و تنها شاخه ای را که آپلود و مقایسه می کنید، تجزیه و تحلیل کنید.

چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

در حال حاضر، ما هنوز از یک بررسی کد نسبتاً ابتدایی استفاده می کنیم. لازم به ذکر است که SonarQube با برخی از زبان های برنامه نویسی از جمله دلفی سازگاری ندارد. در حال حاضر، برای سیستم خود، ما فقط کد PLSql را تجزیه و تحلیل می کنیم.

اینطوری کار میکنه:

  • ما فقط کد PL/SQL را برای پروژه خود تجزیه و تحلیل می کنیم.
  • QualityGate در SonarQube پیکربندی شده است تا تعداد خطاها با commit افزایش پیدا نکند.
  • تعداد خطاها در اجرای اول 229 بود. اگر در حین commit خطاهای بیشتری وجود داشته باشد، ادغام مجاز نیست.
  • علاوه بر این، با توجه به اصلاح خطاها، پیکربندی مجدد QualityGate امکان پذیر خواهد بود.
  • شما همچنین می توانید موارد جدیدی را برای تجزیه و تحلیل اضافه کنید، به عنوان مثال، پوشش کد با تست و غیره.

طرح کار:

چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

در نظرات اسکریپت مشاهده می کنید که تعداد خطاهای شاخه ویژگی افزایش نیافته است. پس همه چیز اوکی است.

چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

دکمه Merge در دسترس می شود.

چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

در نظرات اسکریپت می بینید که تعداد خطاهای شاخه ویژگی بیش از حد مجاز شده است. پس همه چیز بد است.

چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

دکمه Merge قرمز است. در حال حاضر هیچ منعی برای آپلود تغییرات در کدهای اشتباه وجود ندارد، اما این کار با صلاحدید توسعه دهنده مسئول انجام می شود. در آینده می توانید از انجام چنین تعهداتی به شعبه اصلی جلوگیری کنید.

چگونه SonarQube را پیاده سازی کردیم و به پتانسیل بزرگ آن پی بردیم

کار مستقل روی اشکالات

در مرحله بعد، باید تمام خطاهای شناسایی شده توسط سیستم را بررسی کنید، زیرا SonarQube طبق استانداردهای سختگیرانه خود تجزیه و تحلیل می کند. آنچه او به عنوان یک خطا در نظر می گیرد ممکن است در واقع یکی از خطاهای کد ما نباشد. بنابراین، باید بررسی کنید و توجه داشته باشید که آیا این واقعا یک اشتباه است یا در شرایط ما نیازی به ویرایش نیست. بنابراین، تعداد خطاها را کاهش می دهیم. با گذشت زمان، سیستم یاد می گیرد که این تفاوت های ظریف را درک کند.

به چی رسیدیم

هدف ما این بود که بفهمیم آیا انتقال تأیید کد به اتوماسیون در مورد ما مصلحت است یا خیر. و نتیجه انتظارات را برآورده کرد. SonarQube به ما اجازه می دهد تا با زبان های مورد نیاز خود کار کنیم، تجزیه و تحلیل نسبتاً شایسته ای انجام می دهد و پتانسیل یادگیری از نکات توسعه دهندگان را دارد. به طور کلی، ما از اولین تجربه خود با SonarQube خرسندیم و قصد داریم در این مسیر توسعه بیشتری داشته باشیم. ما انتظار داریم که در آینده بتوانیم در زمان و تلاش بیشتری در بررسی کد صرفه جویی کنیم و با حذف عامل انسانی آن را بهتر کنیم. شاید در این فرآیند کاستی‌های پلتفرم را کشف کنیم، یا برعکس، یک بار دیگر مطمئن شویم که این یک چیز جالب با پتانسیل زیاد است.

در این مقاله مروری درباره آشنایی خود با تحلیلگر استاتیک SonarQube صحبت کردیم. اگر سوالی دارید، لطفا در نظرات بنویسید. اگر به این موضوع علاقه دارید، در نشریه جدید با جزئیات بیشتر نحوه تنظیم درست همه چیز و نوشتن کد برای انجام چنین بررسی را شرح خواهیم داد.

نویسنده متن: آتانیا

منبع: www.habr.com

اضافه کردن نظر