نريد أن نشارك تجربتنا في تنفيذ منصة SonarQube للتحليل المستمر وقياس جودة الكود في عمليات التطوير الحالية لنظام DPO (بالإضافة إلى نظام Alameda للإيداع ومحاسبة المقاصة) لمستودع التسوية الوطنية.
تعد شركة إيداع التسوية الوطنية (مجموعة شركات بورصة موسكو) واحدة من الشركات الرئيسية في البنية التحتية المالية، حيث تقوم بتخزين ومحاسبة الأوراق المالية الخاصة بالمصدرين الروس والأجانب بقيمة تزيد عن 50 تريليون روبل. يتطلب الحجم المتزايد للعمليات التي يقوم بها النظام، فضلاً عن التوسع المستمر في الوظائف، الحفاظ على كود مصدر عالي الجودة للأنظمة. إحدى الأدوات لتحقيق هذا الهدف هي محلل SonarQube الثابت. سنصف في هذه المقالة التجربة الناجحة لتطبيق محلل SonarQube الثابت بسلاسة في عمليات التطوير الحالية لقسمنا.
باختصار عن القسم
تشمل كفاءتنا الوحدات التالية: المدفوعات لعملاء NSD، وإدارة المستندات الإلكترونية (EDF)، ومعالجة رسائل المستودع التجاري (تسجيل المعاملات خارج البورصة)، وقنوات التفاعل الإلكتروني بين العملاء وNSD، وغير ذلك الكثير. بشكل عام، هناك الكثير من العمل الذي يتعين القيام به على الجانب الفني للأنشطة التنفيذية. نحن نعمل على أساس الطلبات. تتم معالجة الطلبات المقدمة من مسؤولي العمليات من قبل المحللين: فهم يجمعون متطلبات العميل ويقدمون لنا رؤيتهم لكيفية ملاءمتها للبرنامج. التالي هو المخطط القياسي: تطوير الكود – الاختبار – التشغيل التجريبي – تسليم الكود إلى دائرة الإنتاج إلى العميل المباشر.
لماذا سونار كيوب؟
هذه هي التجربة الأولى لقسمنا في تنفيذ منصة لمراقبة جودة التعليمات البرمجية - لقد قمنا بذلك يدويًا في السابق، ونجري مراجعات التعليمات البرمجية فقط. لكن حجم العمل المتزايد يتطلب أتمتة هذه العملية. بالإضافة إلى ذلك، يضم الفريق أيضًا موظفين عديمي الخبرة وليسوا على دراية كاملة بأنظمة التطوير الداخلي ويميلون إلى ارتكاب المزيد من الأخطاء. للتحكم في جودة التعليمات البرمجية، تقرر تنفيذ محلل ثابت. وبما أن SonarQube تم استخدامه بالفعل في بعض أنظمة NSD، فلم يستغرق الاختيار وقتًا طويلاً. في السابق، استخدمه زملاء من الإدارات الأخرى لتحليل كود الخدمات الصغيرة في نظام Alameda (نظام الإيداع والمقاصة الخاص بـ NSD)، في CFT (نظام معلومات للحفاظ على المحاسبة والميزانيات العمومية وإعداد التقارير الإلزامية والداخلية)، في بعض أنظمة أخرى. لإجراء التجارب، قررنا البدء بالإصدار المجاني من SonarQube. لذلك دعونا ننتقل إلى قضيتنا.
عملية التنفيذ
لدينا:
- تجميع النظام التلقائي في TeamCity؛
- تم تكوين عملية تحميل التعليمات البرمجية عبر MergeRequest من فرع الميزات إلى الفرع الرئيسي في GitLab (عملية التطوير وفقًا لـ GitHub Flow)؛
- SonarQube، تم تكوينه لتحليل التعليمات البرمجية لنظام DPO وفقًا لجدول زمني.
هدفنا: تنفيذ تحليل الكود التلقائي في عمليات CI/CD الخاصة بـ DPO.
تحتاج إلى تكوين: عملية فحص الكود تلقائيًا باستخدام محلل ثابت مع كل MergeRequest إلى الفرع الرئيسي.
أولئك. الصورة المستهدفة هي كما يلي: بمجرد أن يقوم المطور بتحميل التغييرات إلى فرع الميزات، يتم تشغيل التحقق التلقائي من وجود أخطاء جديدة في التعليمات البرمجية. إذا لم تكن هناك أخطاء، فسيتم قبول التغييرات، وإلا فسيتعين تصحيح الأخطاء. بالفعل في المرحلة الأولية تمكنا من تحديد عدد معين من الأخطاء في الكود. يحتوي النظام على إعدادات مرنة للغاية: يمكن تهيئتها بطريقة تناسب المهام المحددة للمطورين، لكل نظام ونمط برمجة.
إعداد QualityGate في SonarQube
تحليل QualityGate هو شيء نقرأه في أعماق الإنترنت. في البداية، استخدمنا نهجًا مختلفًا، وأكثر تعقيدًا، وفي بعض النواحي، ليس صحيحًا تمامًا. أولاً، قمنا بإجراء الفحص مرتين من خلال SonarQube: قمنا بفحص فرع الميزات والفرع الذي كنا سنقوم بدمج فرع الميزات فيه، ثم قمنا بمقارنة عدد الأخطاء. لم تكن هذه الطريقة مستقرة ولم تسفر دائمًا عن النتيجة الصحيحة. وبعد ذلك اكتشفنا أنه بدلاً من تشغيل SonarQube مرتين، يمكننا وضع حد لعدد الأخطاء التي تم ارتكابها (QualityGate) وتحليل الفرع الذي تقوم بتحميله ومقارنته فقط.
في الوقت الحالي، ما زلنا نستخدم مراجعة تعليمات برمجية بدائية إلى حد ما. ومن الجدير بالذكر أن برنامج SonarQube غير متوافق مع بعض لغات البرمجة ومن بينها لغة دلفي. في الوقت الحالي، نقوم بتحليل كود PLSql فقط لنظامنا.
يعمل مثل هذا:
- نقوم بتحليل كود PL/SQL لمشروعنا فقط.
- قام SonarQube بتكوين QualityGate بحيث لا يزيد عدد الأخطاء مع الالتزام.
- كان عدد الأخطاء عند الإطلاق الأول 229. إذا كان هناك المزيد من الأخطاء أثناء الالتزام، فلن يُسمح بالدمج.
- علاوة على ذلك، إذا تم تصحيح الأخطاء، فسيكون من الممكن إعادة تكوين QualityGate.
- يمكنك أيضًا إضافة نقاط جديدة للتحليل، على سبيل المثال، تغطية التعليمات البرمجية بالاختبارات، وما إلى ذلك.
مخطط العمل:
تظهر تعليقات البرنامج النصي أن عدد الأخطاء في فرع الميزات لم يزد. لذلك كل شيء على ما يرام.
يصبح زر الدمج متاحًا.
في تعليقات البرنامج النصي، يمكنك أن ترى أن عدد الأخطاء في فرع الميزات أصبح أكثر من مقبول. لذلك كل شيء سيء.
زر الدمج باللون الأحمر. في الوقت الحالي، لا يوجد حظر على تحميل التغييرات بناءً على تعليمات برمجية خاطئة، ولكن يتم ذلك وفقًا لتقدير المطور المسؤول. في المستقبل، يمكنك منع إضافة مثل هذه الالتزامات إلى الفرع الرئيسي.
العمل المستقل على الأخطاء
بعد ذلك، تحتاج إلى التحقق من جميع الأخطاء التي اكتشفها النظام، لأن SonarQube يقوم بالتحليل وفقًا لمعاييره الصارمة. ما يعتبره خطأً قد لا يكون في الواقع خطأً في الكود الخاص بنا. لذلك، تحتاج إلى التحقق وملاحظة ما إذا كان هذا خطأ بالفعل، أو ما إذا كانت هناك حاجة للتعديل في شروطنا. بهذه الطريقة نقوم بتقليل عدد الأخطاء. بمرور الوقت، سيتعلم النظام فهم هذه الفروق الدقيقة.
ما وصلنا إليه
كان هدفنا هو فهم ما إذا كان من المستحسن في حالتنا نقل مراجعة التعليمات البرمجية إلى الأتمتة. وكانت النتيجة ترقى إلى مستوى التوقعات. يتيح لنا SonarQube العمل باللغات التي نحتاجها، وإجراء تحليل كفؤ إلى حد ما، ولديه القدرة على التعلم من نصائح المطورين. بشكل عام، نحن سعداء بتجربتنا الأولى في استخدام SonarQube ونخطط لمزيد من التطوير في هذا الاتجاه. نتوقع أن نتمكن في المستقبل من توفير المزيد من الوقت والجهد في مراجعة الكود وتحسينه من خلال التخلص من العامل البشري. ربما سنكتشف في هذه العملية أوجه القصور في المنصة، أو على العكس من ذلك، سنقتنع مرة أخرى بأن هذا شيء رائع ذو إمكانات كبيرة.
تحدثنا في مقالة المراجعة هذه عن معرفتنا بالمحلل الثابت SonarQube. إذا كان لديك أسئلة، يرجى الكتابة في التعليقات. إذا كنت مهتمًا بهذا الموضوع، فسنشرح في منشور جديد بمزيد من التفصيل كيفية إعداد كل شيء بشكل صحيح وكتابة التعليمات البرمجية لإجراء مثل هذا الفحص.
مؤلف النص:
المصدر: www.habr.com