הגדרת מטמון תלויות בצינור CI/CD

מטמון תלויות ב-CI/CD: היכן הבנייה מאבדת דקות

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

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

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

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

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

מה משתנה במהירות הבנייה ובאמינות האספקה

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

מפתח המטמון מחושב לפי סכום ביקורת (checksum) של קובץ התלויות, ולכן שלבים שבעבר פנו למרשם שולפים ארטיפקטים מוכנים מהמאגר המקומי. הרשת יוצאת מהמשוואה ב-80–90% מהבניות: פניות חוץ נשארות רק במקום שבו התלויות באמת השתנו.

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

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

זמן בנייה צפוי הוא תוצאה ישירה: הפער בין הרצה מהירה לאיטית מצטמצם ל-10–15% במקום פי שניים. לפי משך כזה כבר אפשר לתכנן שחרור ולשמור על חלון אספקה קבוע.

דרכי אחסון ארטיפקטים של בנייה: השוואת אפשרויות

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

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

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

סדר ההטמעה: מהאודיט ועד מסירה לצוות

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

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

ערכת המסירה: קונפיגורציות, מדיניות, נהלים

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

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

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

מקרה בוחן: בנייה של מונורפו הואצה פי כמה

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

גרוע מכך, בכשלי רשת בצד המרשם נפל כל הצינור: 5–7 בניות שנפלו בשבוע, כל אחת — הרצה מחדש ידנית ושעות אבודות של הצוות.

מה שינו

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

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

מדדים לפני ואחרי

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

במה נבדל מטמון תלויות מאחסון שכבות?

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

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

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

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

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

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

מגבלות שמירה וטעויות הגדרה אופייניות

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

נעבור עליהם אחד-אחד, עם סימן התקלה ואופן ההגדרה.

שתי סביבות דורסות זו את המטמון של זו

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

מה עושים עם מרשם חבילות סגור?

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

המאגר גדל בלי סוף — איך מגבילים?

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

נדון במשימה: מה לברר לפני ההתחלה

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

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

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