כיצד Coroid מאמת את עבודתו באופן עצמאי

כל pull request מ־Coroid עובר תהליך אימות לפני שאתם רואים אותו. הפרק הזה מסביר מה פירוש הדבר וכיצד להגדיר אותו.

השכבות#

תהליך האימות אינו אחיד. ישנן ארבע שכבות, כל אחת עונה על שאלה שונה.

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

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

סקירה. סוכן הסקירה קורא את ה־diff המושלם ומפיק ממצאים. ממצאים שניתן לתקן מוחזרים למפתח כעבודה נוספת; השאר מצורפים ל־pull request.

ראיות. פריסות תצוגה מקדימה, תוצאות סריקה ושינויי כיסוי קוד המצורפים ישירות ל־pull request, כך שהאימות מגיע יחד עם הקוד. ראו ראיות לסקירה.

מה שתהליך זה מוכיח ומה לא#

תהליך האימות מאשר שהשינוי עושה את מה שהוא אמור לעשות, שאינו שובר את הקיים, ושהוא עומד בתקנים שקבעתם.

הוא אכן אינו מאשר שהשינוי הוא הדבר הנכון לפתח. זה בדיוק תפקידם של קריטריוני הקבלה ב־ מפרט ושל תהליך הסקירה שלכם.

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

הסיבה להרצתו מראש#

כל שכבה פועלת לפני קיומו של ה־pull request, כך שכישלונות חוזרים כעבודה נוספת בתוך אותו תהליך ולא כ־pull request שתדחו בסופו של דבר.

זול יותר לכשל בסביבת העבודה מאשר על המסך שלכם. הסקירה שלכם צריכה להיות ה־ אדם הראשון שרואה אותו, ולא הראייה הראשונה.

מאיפה להתחיל#

אם אתם מגדירים זאת בפעם הראשונה:

1. ודאו שסט המבחנים שלכם פועל – ראו תצורת בנייה ומבחנים. שום דבר אחר אינו רלוונטי אם זה אינו תקין.
2. קבעו מדיניות ברירת מחדל לארגון ברמת ה־ סטנדרט ולא ברמת הקפדנית ביותר.
3. חברו את ספקי הראיות שאתם כבר משתמשים בהם.
4. הוסיפו שערי איכות אחד אחד, תחילה כשערי המלצה.

בפרק זה#

• מדיניות איכות ושערי איכות
• בדיקות, הרצות וממצאים
• ראיות לסקירה
• מבחני דפדפן
• חובות
• חוזי תוצאות