למה מערכת בנייה?

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

מהי מערכת build?

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

האם אין לי אפשרות להשתמש רק בקומפיילר?

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

javac *.java

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

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

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

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

מה לגבי סקריפטים של מעטפת?

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

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

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

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

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

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

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

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

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