Blueprint עבור TON: סביבת פיתוח לחוזים חכמים

Blueprint TON: היכן נשברת הבנייה והפריסה של חוזים

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

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

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

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

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

מה נותנת סביבת בנייה ובדיקות אחידה לחוזים

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

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

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

הבחירה כאן אינה בין «כלי או כלום», אלא בין דרכים לארגן את הבנייה והבדיקות.

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

Blueprint TON או בנייה ידנית: השוואת גישות

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

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

שלבי הטמעת סביבת פיתוח לחוזים

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

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

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

ערכת המסירה: קונפיגורציות, תרשימים ותקנונים

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

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

מקרה בוחן: העברת חוזים לסביבת בנייה אחידה

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

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

מה השתנה במטריקות

הבנייה המלאה התקצרה מ-12–15 דקות לכשתי דקות: קודם הארטיפקטים נבנו ברצף, כעת השלבים נשמרים במטמון ורצים במקביל. שיעור מסלולי ניתוח ההודעות המכוסים בבדיקות עלה מכ-40% לכ-85%, והוצאת העדכון — מכמה שעות של פעולות ידניות לכ-20 דקות לפי תרחיש אחד.

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

במה נבדל ריצה מקומית מבדיקה ברשת הבדיקות?

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

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

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

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

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

ספקות טכניים: שאלות נפוצות על הסביבה

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

כיצד בנויות הגישות למפתחות?

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

האם אפשר לעדכן לוגיקה של חוזה שכבר הושק?

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

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

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

נדון במשימה: ממה נתחיל את העבודה על החוזים

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

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

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

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