שאלות נפוצות

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

מהי Bazel?

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

מה מיוחד בבזל?

Bazel תוכנן להתאים לאופן הפיתוח של התוכנה ב-Google. כולל את התכונות הבאות:

  • תמיכה בשפות רבות: Bazel תומכת בשפות רבות, וניתן להרחיב אותה כך שתתמוך בשפות תכנות שרירותיות.
  • שפת build כללית ברמה גבוהה: הפרויקטים מתוארים בשפה BUILD, פורמט טקסט תמציתי שמתאר פרויקט כקבוצות של ספריות קטנות, קבצים בינאריים ובדיקות. לעומת זאת, בעזרת כלים כמו 'יצרן', עליכם לתאר קבצים בודדים והפעלה של מהדרים.
  • תמיכה בפלטפורמות מרובות: אפשר להשתמש באותו כלי ובאותם BUILD קבצים כדי לבנות תוכנה לארכיטקטורות שונות, ואפילו לפלטפורמות שונות. ב-Google, אנחנו משתמשים ב-Bazel כדי לבנות כל דבר, החל מאפליקציות של שרתים שפועלות במערכות במרכזי הנתונים שלנו ועד לאפליקציות לקוח שפועלות בטלפונים ניידים.
  • יכולת שחזור: ב-BUILD קבצים, כל ספרייה, בדיקה ובינארית חייבים לציין את יחסי התלות הישירים שלהם באופן מלא. Bazel משתמשת במידע התלוי, כדי לדעת מה יש לבנות מחדש כאשר מבצעים שינויים בקובץ מקור, ואילו משימות יכולות לפעול במקביל. פירוש הדבר הוא שכל ה-build מצטבר ופועל תמיד עם אותה תוצאה.
  • ניתן להתאמה: Bazel יכול לטפל ב-builds גדולים. ב-Google, קורה שקובץ בינארי של קובץ נפוץ מכיל 100,000 קובצי מקור, ו-build עשוי להיות כ-200 אלפיות השנייה.

למה Google לא משתמשת...?

  • הגדרה ו'נינג'ה': כלים אלה מספקים שליטה מדויקת מאוד על הפקודות שמופעלות ליצירת קבצים, אבל המשתמשים צריכים לכתוב כללים נכונים.
    • המשתמשים מקיימים אינטראקציה עם Bazel ברמה גבוהה יותר. לדוגמה, Bazel משתמשת בכללים מובנים ל"בדיקת Java", לבינארי (C++ ) ולתיאורים כמו "פלטפורמת יעד" ו"פלטפורמת מארח". הכללים האלה נבדקו כעמידים בפני אבק.
  • נמלה ו-Maven: הנמלה ו-Maven מיועדות בעיקר ל-Java, ו-Bazel מטפלת במספר שפות. Bazel מעודדת חלוקת משנה של קודי בסיס ביחידות קטנות יותר שניתן להשתמש בהן שוב, ובונה מחדש רק יחידות שצריך לבנות מחדש. כך ניתן לעבוד מהר יותר כשעובדים עם בסיסים גדולים יותר.
  • Gradle: קובצי תצורה ב-Bazel מובנים יותר מאלה של Gradle, ומאפשרים ל-Bazel להבין בדיוק מה כל פעולה עושה. כך אפשר לשפר את במקבילות ולשפר את השחזור.
  • מכנסיים, באק: שני הכלים נוצרו ופותחו על ידי גוגלרים לשעבר ב-Twitter וב-F להפעיל, וב-Facebook בהתאמה. דגמים אלה נוצרו אחרי ב-Bazel, אבל התכונות שלהם שונות מבחינתנו, ולכן הם לא חלופה אפשרית.

מאיפה באזל?

Bazel הוא טעם של הכלי ש-Google משתמשת בו כדי לבנות את תוכנת השרת שלה באופן פנימי. היא התרחבה לבניית תוכנות נוספות, כמו אפליקציות לנייד (iOS, Android) שמתחברות לשרתים שלנו.

האם כתבתם מחדש את הכלי הפנימי כקוד פתוח? האם זה מזלג?

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

למה Google יצרה את Bazel?

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

האם יש דרישה לשימוש באשכול ב-Bazel?

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

איך פועל תהליך הפיתוח של Google?

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

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

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

רקע נוסף על תהליך הפיתוח ב-Google זמין בבלוג הכלים של eng.

למה פתחת את Bazel?

בניית תוכנה צריכה להיות מהנה וקלה. גרסאות build איטיות ובלתי צפויות גורמות לכיף ליהנות מהתכנות.

למה כדאי להשתמש בבזל?

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

אפשר לראות דוגמאות?

כן, אפשר לעיין בדוגמה פשוטה או לקרוא את קוד המקור של Bazel כדי לקבל דוגמה מורכבת יותר.

מה הכי טוב בבזל?

Bazel בוהקת בבנייה ובדיקה של פרויקטים עם המאפיינים הבאים:

  • פרויקטים עם בסיס קוד גדול
  • פרויקטים שנכתבו (בכמה) שפות
  • פרויקטים בפריסה במגוון פלטפורמות
  • פרויקטים שכוללים בדיקות מקיפות

היכן ניתן להריץ את Bazel?

Bazel פועלת ב-Linux, ב-macOS (OS X) וב-Windows.

ניוד לפלטפורמות UNIX אחרות צריך להיות קל יחסית, כל עוד JDK זמין לפלטפורמה.

למה לא להשתמש ב-Bazel?

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

עד כמה יציבה התכונה של Bazel?

לתכונות הליבה (C++ , Java וכללי מעטפת) יש שימוש נרחב ב-Google, ולכן הן נבדקות בקפידה ויש להן מעט מאוד נטישה. באופן דומה, אנחנו בודקים גרסאות חדשות של Bazel מדי יום במאות אלפי יעדים כדי למצוא רגרסיות, ומשיקים גרסאות חדשות כמה פעמים בכל חודש.

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

עד כמה Bazel יציבה בצורה בינארית?

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

איך מתחילים להשתמש ב-Bazel?

איך מתחילים

האם Docker לא פותר את בעיות השחזור?

בעזרת Docker, אפשר ליצור בקלות Sandbox עם גרסאות OS קבועות, לדוגמה, Ubuntu 12.04 ו-Fedora 21. פעולה זו פותרת את בעיית הרבייה של סביבת המערכת – כלומר, "איזו גרסה של /usr/bin/c++ I need? "

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

בתוך Google, אנחנו בודקים כלים לבקרת מקורות כדי להפעיל אותם מחדש. כך אנחנו יכולים לבדוק כלים ('שדרוג GCC ל-4.6.1') באמצעות אותו מנגנון כמו שינויים בספריות בסיסיות ("בדיקת גבולות התיקון ב-OpenSSL").

האם ניתן ליצור קבצים בינאריים לפריסה ב-Docker?

עם Bazel אפשר לבנות קבצים בינאריים עצמאיים עם סטטיים ב-C/C++ , ועם קובצי צנצנת עצמאיים ל-Java. הם פועלים עם מספר יחסי תלות במערכות UNIX רגילות, ולכן קל להתקין אותם בתוך מאגר Docker.

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

האם ניתן ליצור תמונות Docker עם Bazel?

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

האם Bazel תגדיר את גרסאות ה-build שלי באופן אוטומטי?

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

  • אין להשתמש בתלויות שלא הוצהרו עליהן. הפעלה בארגז חול (–spawn_strategi=sandboxed, רק ב-Linux) יכולה לעזור למצוא יחסי תלות לא מוצהרים.
  • אין לאחסן חותמות זמן ומזהי User-ID בקבצים שנוצרו. קובצי ZIP וארכיונים אחרים נוטים במיוחד לכך.
  • הימנע מהתחברות לרשת. גם הפעלה בארגז חול יכולה לעזור כאן.
  • כדאי להימנע מתהליכים שמשתמשים במספרים אקראיים, באופן ספציפי, המעבר למילון אקראי בשפות תכנות רבות.

האם יש לך גרסאות בינאריות?

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

אני משתמש ב-Eclipse/IntelliJ/XCode. איך אינטראקציה של Bazel עם מפתחים בסביבת פיתוח משולבת (IDE)?

ל-IntelliJ, אתם יכולים לעיין בפלאגין של IntelliJ עם Bazel.

ל-XCode, יש לעבור אל Tulsi.

ל-Eclipse, מומלץ לעיין בפלאגין E4B.

לאתרי IDE אחרים אפשר לקרוא את הפוסט בבלוג על אופן הפעולה של יישומי הפלאגין האלה.

אני משתמש/ת ב-Jenkins/ROUNDCI/TravisCI. איך אינטראקציה של Bazel עם מערכות CI?

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

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

אילו תכונות עתידיות נוכל לצפות ב-Bazel?

למידע על מפות הדרכים שלנו.

האם אוכל להשתמש ב-Bazel בפרויקט INSERT LANGUAGE HERE?

Bazel ניתן להרחבה. כל אחד יכול להוסיף תמיכה בשפות חדשות. יש הרבה שפות נתמכות: כדי לקבל רשימה מקיפה יותר של המלצות, אפשר לעיין ב-build אנציקלופדיה וב-awesomebazel.com.

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

האם ניתן לתרום לבסיס הקוד של Bazel?

כדאי לעיין בהנחיות לתרומות.

למה כל הפיתוח לא פתוח?

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

האם העסק שלך פתוח בבזל?

מיקור חוץ של Bazel נמצא בשלבי פיתוח. ספציפית, אנחנו עדיין עובדים על קוד פתוח:

  • הרבה בדיקות של יחידות ושילוב (שצפויות יותר להקל על תיקוני תוכן).
  • שילוב מלא של IDE.

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

האם יש חלקים מ-Bazel שמעולם לא יהיו בקוד פתוח?

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

איך פונים לצוות?

ניתן ליצור איתנו קשר בכתובת bazel-conversation@googlegroups.com.

איפה מדווחים על באגים?

פותחים בעיה ב-GitHub.

מה קורה עם המילה "בלאק" בבסיס הקוד?

זהו שם פנימי עבור הכלי. יש להתייחס אל Bazel בתור Bazel.

למה פרויקטים אחרים של Google (Android ו-Chrome) משתמשים בכלים אחרים לבניית גרסאות?

עד שהגרסה הראשונה (אלפא) לא הייתה זמינה, Bazel לא היה זמין באופן חיצוני, כך שפרויקטים בקוד פתוח כמו Chromium ו-Android לא יוכלו להשתמש בו. בנוסף, הבעיה המקורית בתמיכה ב-Windows הייתה בעיה בבניית אפליקציות Windows, כמו Chrome. מכיוון שהפרויקט התבגר והפך ליציב יותר, פרויקט הקוד הפתוח של Android נמצא בתהליך העברה ל-Bazel.

איך מבטאים 'בזל'?

בדיוק כמו "בזיליקום" (צמחי מרפא) באנגלית של ארה"ב: "BAY-zel". הוא מתחרז עם "hazel". IPA: /be='_z='_l/