הטמעת Pact Contract Testing ב-CI/CD למיקרו-שירותים

בדיקות חוזה: היכן נשברות האינטגרציות של מיקרו-שירותים

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

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

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

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

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

אפקט מדיד: פחות כשלים בחיבורים בין שירותים

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

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

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

האפקט השלישי — זמן ההתאוששות. אירוע בחיבור בין שירותים означал בעבר או חזרה לאחור של השחרור, או דיבוג משותף של שתי קבוצות, כל עוד חלק מהפונקציונליות אינו זמין.

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

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

אפשרויות בדיקה: בדיקות חוזה וחלופות

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

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

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

סדר היישום: מביקורת חיבורים ועד העברה לקבוצה

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

1. ביקורת חיבורים. אוספים מפת קריאות: מי פונה למי, אילו שדות הצרכן באמת קורא, היכן הציפיות סוטות מהתגובה בפועל. בפלט — רשימת קשרים עם עדיפות לפי תדירות השינויים והקריטיות.
2. סכמת חוזים. לכל קשר מתעדים את ציפיות הצרכן: שדות חובה, טיפוסים, קודי תגובה, התנהגות בעת שגיאה. חוזים על Pact מגורסנים וחיים במאגר הקוד של שירות הספק.
3. הגדרת בדיקות. מחברים את ההרצה לקו הבנייה: הבדיקה מופעלת על כל קומיט ונכשלת לפני פרסום הארטיפקט. בנפרד מגדירים תצוגה שבה רואים איזה חיבור בדיוק נשבר.
4. בדיקה בסביבה. מריצים את החוזים על העתק של סביבת הייצור עם פרופיל נתונים אמיתי — כך עולים פערים שאינם נראים על סטאבים: פורמטי תאריכים, ערכים ריקים, טיפול שונה בשגיאות.
5. ניתוח פערים. כל כשל מסווגים: אי-תאימות אמיתית, התראת שווא או ציפייה מיושנת. התראות שווא עוברות להגדרות, אמיתיות — לתוכנית תיקונים בשני צדי החיבור.
6. העברה לקבוצה. מוסרים תיעוד על קשרים, כללים לשינוי חוזים, נוהל תורנות והדרכת מהנדסים. בהמשך הקבוצה מתקנת את החוזים בעצמה, בלי השתתפותנו.

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

ארטיפקטים של היישום: סכמות חיבורים וכללי ניהול גרסאות

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

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

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

מקרה בוחן: כיצד התקצר זמן השחרור לאחר בדיקות חיבורים

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

מדדים לפני ואחרי

מה עשינו

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

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

מה לעשות אם השירותים כבר מחוברים ישירות?

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

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

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

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

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

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

ספקות של מהנדסים: תאימות גרסאות והתראות שווא

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

התראות שווא יעצרו שחרורים?

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

אין לנו תיאורי ממשקים — ממה להתחיל?

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

מי אחראי לבדיקות לאחר היישום?

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

מה עם תמיכה בבדיקות לאחר ההעברה?

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

נדון במשימה: מה לשלוח להערכה ותוכנית

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

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

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