בדיקות חוזים מונחות צרכן: Pact, CI/CD ופריסה עצמאית

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

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

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

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

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

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

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

מה נותנות בדיקות חוזה לשירותים ולמהדורות

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

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

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

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

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

אפשרויות לבדיקת תאימות: השוואת גישות

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

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

כיצד אנו מטמיעים בדיקות חוזה: שלבי העבודה

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

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

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

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

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

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

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

מה נשאר במאגר ובתיעוד של הצוות

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

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

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

מקרה בוחן: מהדורות בלתי-תלויות בלי הסכמות ידניות

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

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

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

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

במה נבדלות בדיקות חוזה מבדיקות אינטגרציה?

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

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

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

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

מגבלות הגישה וספקות טכניים נפוצים

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

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

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

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

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

אפשר להטמיע בשלבים?

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