פתרון מסירה והרחבה עצמאית

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

המסמך של build מציין source revision וגם מצב שינויים מקומיים. הוא נועל architecture וגרסאות tools ומפרט את פקודת ההרצה. אם סביבת הפיתוח מייצרת קובץ חיוני באופן סמוי, מעבירים את היצירה לbuild או מוסיפים את המקור המתאים לריפו.

העבודה החדשה מקבלת kind חדש עם payload וresult מוגדרים. הserver הישן דוחה kind שאינו מכיר בלי לנסות לפרש אותו כעבודה קיימת. הserver החדש שומר את החוזה של kind ישן. הclient החדש בודק capability לפני הצגת פעולה שהserver אינו תומך בה.

הjournal שומר את kind ואת גרסת הpayload יחד עם מזהה ותוצאה. אם reader ישן אינו מסוגל להבין רשומה חדשה, rollback אליו נחסם לפי החוזה או משתמש במסלול migration מפורש. אסור למחוק את הרשומה כדי לגרום לגרסה הישנה להיראות תקינה.

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

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