הרמוניה

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

סקירה כללית

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

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

שני ההיבטים החשובים של ההרמטיות הם:

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

יתרונות

היתרונות העיקריים של גרסאות לבנייה:

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

זיהוי לא-הורשה

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

  • עיבוד אקראי ב-.mk קבצים
  • פעולות או כלים שיוצרים קבצים באופן לא ידוע, לרוב עם מזהים או חותמות זמן של בנייה
  • קבצים בינאריים של מערכת השונים בין מארחים (כמו קבצים בינאריים של /usr/bin, נתיבים מוחלטים, מהדרים של מערכת C++ לתצורה אוטומטית של כללי C++)
  • כתיבה בעץ המקור במהלך ה-build. המדיניות הזו מונעת שימוש באותו עץ עץ ליעד אחר. העץ הראשון כותב את עץ המקור, ומתקן את עץ המקור עבור יעד א'. לאחר מכן, ניסיון לבנות את יעד ב' עלול להיכשל.

פתרון בעיות בגרסת build לא-הירמטית

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

  • הקפדה על גרסאות build רציפות: אם מריצים את make ומקבלים build מובנה, לא מומלץ להריץ שוב את ה-build את היעדים. אם מריצים כל שלב build פעמיים או במערכות שונות, משווים בין גיבוב (hash) של תוכן הקובץ ומקבלים תוצאות שונות, כי לא ניתן לשחזר את ה-build.
  • מומלץ לבצע את השלבים לניפוי באגים בהיטים ששמורים במטמון המקומי ממגוון מכונות לקוח פוטנציאליות, כדי לוודא שתזהו מקרים של מקרי לקוח שדלפו בפעולות.
  • הפעלת מבנה בתוך מאגר תגים שמכיל רק את עץ המקור ורשימה מפורסמת של הכלים למארחים. בניית שברים והודעות שגיאה תזהה יחסי תלות מרומזים של המערכת.
  • כללי ההפעלה מרחוק מאפשרים לכם לפתור בעיות שקשורות לטכנולוגיה.
  • הפעלת ארגז חול קפדני ברמת הפעולה, מאחר שפעולות ב-build יכולות להיות מצביות ולהשפיע על ה-build או על הפלט.
  • כללי סביבת העבודה מאפשרים למפתחים להוסיף יחסי תלות לסביבות עבודה חיצוניות, אבל הם עשירים מספיק כדי לאפשר עיבוד שרירותי לתהליך. אפשר להוסיף יומן של פעולות שעלולות להיות על פי חוק ב-Bazel על ידי הוספת הסימון ל---experimental_workspace_rules_log_file=PATH ל-Bazel.

הרמוניה עם בזל

למידע נוסף על הצלחה של פרויקטים אחרים באמצעות מבנים בארכיטקטורה עם Bazel, קראו את המאמרים הבאים ב-BazelCon: