מערכת בנייה היא אחד מהחלקים החשובים ביותר בארגון הנדסי כי כל מפתח יוצר איתה אינטראקציה בעשרות או במאות ימים. כדי לאפשר פרודוקטיביות של מפתחים כאשר הארגון מתרחב, יש צורך במערכת build מלאה. עבור מפתחים ספציפיים, זה פשוט להרכיב את הקוד שלך וכך מערכת build עשויה להיראות מיותרת. אבל בקנה מידה גדול יותר, ניהול מערכת build עוזר בניהול יחסי תלות משותפים, כמו הסתמכות על חלק אחר של בסיס הקוד, או משאב חיצוני כמו ספרייה. מערכות build עוזרות לוודא שיש לכם את כל מה שצריך לבניית הקוד לפני שהוא מתחיל בבנייתו. מערכות build גם מגדילות את המהירות כאשר הן מוגדרות כדי לעזור למהנדסים לשתף משאבים ותוצאות.
הקטע עוסק בהיסטוריה וביסודות של בנייה ובנייה של מערכות, כולל החלטות בנוגע לעיצוב שהתקבלו בבזל. אם אתם מכירים מערכות פיתוח המבוססות על פריטי מידע שנוצרו בתהליך פיתוח (Artifact), כגון בזל, באק ומכנסיים, תוכלו לדלג על קטע זה, אך זוהי סקירה כללית שימושית כדי להבין מדוע מערכות build המבוססות על פריטי מידע שנוצרו בתהליך פיתוח (Artifact) מעולות בהפעלת קנה מידה.
-
אם לא השתמשתם במערכת build בעבר, התחילו כאן. דף זה סוקר את הסיבה לכך שעליך להשתמש במערכת build, ומדוע קומפילרים וסקריפטים הם לא הבחירה הטובה ביותר כאשר הארגון מתחיל להתרחב מעבר לכמה מפתחים.
-
דף זה דן במערכות פיתוח מבוססות משימות (כמו Make, Maven, ו-Garedle) ובכמה מהאתגרים שלהם.
-
דף זה דן במערכות בנייה המבוססות על חפצים בתגובה לכאבים של מערכות בנייה מבוססות משימות.
-
דף זה מכסה גרסאות build מבוזרות או גרסאות build המופעלות מחוץ למחשב המקומי שלכם. לשם כך נדרשת תשתית חזקה יותר כדי לשתף משאבים ולבנות תוצאות (והוא המקום שבו הקוסם האמיתי מתרחש!)
-
דף זה מכסה חלק מהסיבוכים של יחסי תלות בקנה מידה גדול ואסטרטגיות להתמודדות עם סיבוכים אלה.