הגדרת צינור CI/CD לפריסת חוזים חכמים

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

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

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

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

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

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

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

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

מה נותן צינור פריסה אוטומטי של חוזים

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

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

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

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

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

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

דרכי פריסה: מחתימה ידנית ועד צינור מלא

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

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

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

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

שלבי הגדרת הצינור בהתאם לחוזים שלכם

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

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

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

ארטיפקטים ותקנות שתקבלו לידיכם

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

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

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

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

מה היה לפני

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

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

מה שינו

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

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

מה נהיה

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

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

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

במה שונה פריסת חוזים משחרור רגיל של אפליקציה

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

האם ניתן לחזור לאחור מפריסה כושלת?

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

האם הצינור תואם לתהליך הנוכחי שלנו?

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

עד כמה הצינור עצמו מאובטח?

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

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

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

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

מה כדאי להכין לשיחה:

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

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

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