איך הטמענו את 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 אינו תואם לשפות תכנות מסוימות, כולל דלפי. כרגע, עבור המערכת שלנו, אנו מנתחים רק קוד PLSql.

זה עובד ככה:

• אנו מנתחים רק קוד PL/SQL עבור הפרויקט שלנו.
• QualityGate מוגדר ב- SonarQube כך שמספר השגיאות לא יגדל עם הביצוע.
• מספר השגיאות בהפעלה הראשונה היה 229. אם יש שגיאות נוספות במהלך ה-commit, אז מיזוג אינו מותר.
• בנוסף, בכפוף לתיקון שגיאות, ניתן יהיה להגדיר מחדש את QualityGate.
• ניתן גם להוסיף פריטים חדשים לניתוח, למשל, כיסוי קוד עם בדיקות וכו'.

תוכנית עבודה:

בהערות של הסקריפט, ניתן לראות שמספר השגיאות בענף הפיצ'רים לא גדל. אז הכל בסדר.

כפתור המיזוג הופך לזמין.

בהערות של הסקריפט, ניתן לראות שמספר השגיאות בענף הפיצ'רים הפך ליותר מהמותר. אז הכל גרוע.

כפתור המיזוג אדום. נכון לעכשיו, אין מניעה להעלות שינויים בקוד שגוי, אך הדבר נעשה לפי שיקול דעתו של המפתח האחראי. בעתיד תוכל למנוע התחייבויות כאלה לסניף הראשי.

התמודדות עצמית עם באגים

לאחר מכן, עליך לבדוק את כל השגיאות שזוהו על ידי המערכת, מכיוון ש- SonarQube מנתח בהתאם לסטנדרטים המחמירים שלה. יתכן שמה שהוא מחשיב כשגיאה לא ממש בקוד שלנו. לכן צריך לבדוק ולשים לב האם זו באמת טעות, או שאין צורך לערוך בתנאים שלנו. לפיכך, אנו מצמצמים את מספר השגיאות. עם הזמן, המערכת תלמד להבין את הניואנסים הללו.

למה הגענו

המטרה שלנו הייתה להבין האם כדאי במקרה שלנו להעביר אימות קוד לאוטומציה. והתוצאה עמדה בציפיות. SonarQube מאפשר לנו לעבוד עם השפות שאנו צריכים, מבצע ניתוח מוכשר למדי, ויש לו פוטנציאל ללמוד מטיפים למפתחים. באופן כללי, אנו מרוצים מהניסיון הראשון שלנו עם SonarQube ומתכננים להתפתח עוד בכיוון זה. אנו מצפים שבעתיד נוכל לחסוך יותר זמן ומאמץ בבדיקת קוד ולשפר אותו על ידי ביטול הגורם האנושי. אולי תוך כדי נגלה את החסרונות של הפלטפורמה, או להיפך, נוודא שוב שמדובר בדבר מגניב עם פוטנציאל גדול.

במאמר סקירה זה, דיברנו על ההיכרות שלנו עם מנתח הסטטי SonarQube. אם יש לך שאלות, אנא כתוב בתגובות. אם אתה מעוניין בנושא זה, בפרסום החדש נתאר ביתר פירוט כיצד להגדיר הכל נכון ולכתוב קוד כדי לבצע בדיקה כזו.

מחבר הטקסט: אתניה

מקור: www.habr.com