תיבת catch-all בסביבת בדיקות: נוחות ומחירה

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

מה עושה תיבת catch-all בפועל

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

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

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

מדוע צוותי סביבת בדיקות נמשכים לכך?

המניע הוא כמעט תמיד חיכוך. הנה מה שתיבת catch-all מסירה מהדרך:

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

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

מה משתבש כשהכול נוחת בתיבה אחת?

בעיקר נפח ורגישות, והם מחזקים זה את זה.

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

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

הרחקת דואר ייצור מתיבת בדיקות

הכלל שצריך לתכנן סביבו הוא משפט אחד: סביבת בדיקות לא אמורה להיות מסוגלת לקבל דואר שנשלח למשתמש בייצור. כל השאר הוא מימוש.

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

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

שמירת נתונים וניקוי כהחלטת תכנון

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

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

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

למפתחים: ניתוב לפי קידומת וצמצום היקף המתג

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

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

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

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

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

צעדים הבאים

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