הדגמה: מהם Quality Gates ב- SonarQube ?

בוידאו הקצר הבא אנו מדגימים מהם Quality Gates ב- SonarQube , משתפים בדרך מומלצת לשפר את איכות הקוד בצורה מהירה, ומדגימים תוצאות ריצה של SonarQube .

הטקסט המלא של הוידאו נמצא בסוף מאמר זה.

לצפייה (4 דקות):

חברת ALM-Toolbox היא המפיצה הרשמית של SonarQube בישראל, ומספקת יעוץ, הטמעה, הדרכות, התאמת רישוי Enterprise לצרכי הלקוח, מכירת רישוי, וכן חיבור לתהליכי פיתוח ו- CI pipelines.

החברה מציעה פתרונות מקצה לקצה בתחומי ALM, Kubernetes, DevOps, CI/CD pipelines ,
ובפרט Bitbucket, Selenium, git, Rancher, Jira, GitLab, Jenkins ב- on-premises ובענן.

שאלות? נשמח לענות על כל שאלה – אפשר לפנות אלינו במייל sonarqube@almtoolbox.com או טלפונית 072-240-5222

המלל המלא של הוידאו:

שלום,

אנחנו עושים כאן הדגמה קצרה על SonarQube ועל Quality Gates .

אנו נותנים סקירה קצרה מהם Quality Gates ואיך SonarQube מאפשר לנו להטמיע quality gates בתוך תהליך ה- CI (Continuous integration) שלנו בפיתוח.

אז בואו נתחיל לצלול.

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

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

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

התהליך הזה הרבה יותר קל מבחינת כמות הפיתוח . הרבה יותר מהיר ומאפשר בעצם לאותם קטעי קוד שנמצאים בשימוש הכי תכוף להיות באיכות הכי גבוהה – ואז אנחנו מקבלים את כל הדברים הטובים ב"מכה אחת" בלי להשקיע הרבה עבודה.

זה בעצם מאפשר תחילת עבודה מיידית עם SonarQube .

Quality Gates

בואו נדבר על Quality Gates שזהו התהליך עצמו.

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

אנחנו משתמשים ב- measures שהם ציון על מטריקות מסויימות.

אנחנו קובעים מטריקות ולכל מטריקה קבענו threshold . ואם הציון שאותה מטריקה לא עובד בסף שקבענו בנקודת זמן מסויימת אז בעצם ה- quality gate מכשיל את הפרוייקט ואנחנו נקבל failed .

אם כל ה- measures שלנו עוברים אנחנו נקבל PASS שמאפשר להתקדם הלאה. ובציון אחד pass/fail נדע אם הפרוייקט שלנו בנקודת זמן מסויימת עומד ב- quality שקבענו.

את הדבר הזה אפשר לשלב עם תהליך ה- CI ואז כל מפתח בעצם, לכל branch, מקבל איזשהו ציון.

אנחנו יכולים לדעת per branch פר מפתח האם ה- quality

הדבר הזה גם נותן פידבק מאוד מהיר למפתחים ומאפשר למפתחים לתקן את הבעיות שלהם במקום ומיידית ולא רק אחרי שהיה merge לתוך master או איזשהו dev branch שרחוק מתהליך הפיתוח – כלומר ממש מתוך תהליך CI .

הסתכלות מתוך הפרוייקט

אני רוצה להראות לכם איך זה נראה בתוך הפרוייקט.

[3:06] הנה פרוייקט שאני עובד עליו. אתם יכולים לראות אחד מהחלקים של הפרוייקט נמצא כרגע ב- Failed . אפשר לראות את הציונים הכלליים שהפרוייקט הזה מקבל: כמות הבאגים; vulnerabilities ; duplication; code smells; coverage

אני מקבל פה כל מיני ציונים.

אפשר לראות שבפרוייקט B למרות שיש פה 4 באגים ובפרוייקט A רק באג אחד, עדיין פרוייט B עבר (Passed) לעומת פרויקט A שנכשל – וזה בגלל שה- measures של הפרוייקטים הם שונים. ואני באמת יכול להכיר gates לכל פרוייקט – לפי העדפות שלי ; לפי חשיבות רמת ה- quality שנדרשת לאותו פרוייקט וכד'.

[03:51] אם אני צולל יותר לתוך פרוייקט A כדי להבין יותר טוב למה הפרוייקט הזה נכשל, אני יכול לראות בעצם שה- reliability rating על קוד חדש נמוך מ- A , וה- security rating על קוד חדש נמוך מ- A .

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

לסיכום: כשאנחנו מתחילים להשתמש ב SonarQube אנחנו לא צריכים לנקות את כל הקוד. אנחנו נשתמש ב- Quality gates כדי לוודא שהמפתחים יכולים להכניס קוד ב- quality המתאים ואנחנו יכולים לקבל visibility מאוד גבוהה לתוך הפרוייקט באופן מיידי.