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