עדכון תלויות: היכן Dependabot לא עובד
Dependabot פותח בקשות מיזוג כסדרן — ושם רבים עוצרים. פתיחת בקשה אינה זהה לעדכון תלויות: בלי כללי קיבוץ ותנאי מיזוג אוטומטי, התיקונים נערמים בתור, העמיתים מפסיקים לפתוח כרטיסים זהים, והצינור רץ שבועות שלמים על תלויות מיושנות.
ככל שהגרף רחב יותר, כך התור גדל מהר יותר — עשרות בקשות קטנות מתחרות על בדיקה אחת, ואף אחת מהן לא מקבלת אותה בזמן.
שבר אופייני נראה כך. תלות עקיפה מושכת גרסה מאז'ורית שאינה תואמת לזו שננעלה בקובץ הגרסאות — והבנייה השבורה מגיעה במודול שאיש לא נגע בו. הסיבה אינה בקוד החדש, אלא בפער הגרסאות שנצבר במשך חודשים: יש לפרק אותו ידנית, ולבטל תיקונים אחד-אחד.
כל עוד הבקשות תלויות ללא בדיקה, פרצות בתלויות נשארות פתוחות: יש התראה, יש תיקון, אך הוא לא נכנס לענף הראשי. עדכון המפורק למאות צעדים קטנים מגיע לענף השחרור רק מדי פעם, ואת המצטבר מפרקים במכה אחת.
אנו מסבירים כיצד סוגרים זאת: קיבוץ תיקונים לפי אקוסיסטמות, לוח זמנים, מיזוג אוטומטי של עדכונים בטוחים, ונוהל נפרד לגרסאות מאז'ור.
מה נותן עדכון תלויות מנוהל
פרצה בתלות עקיפה ממשיכה לחיות בפרויקט לא מפני שלא שמים לב אליה, אלא מפני שאין ידיים פנויות להגיע אליה. Dependabot קורא קבצי נעילה, מאתר חבילות מיושנות ופותח בעצמו תיקון עם הגרסה החדשה — זרם משימות במקום סריקה ידנית של מאגרים.
בלי מדיניות הזרם הזה מציף את הצוות: עשרות תיקונים זהים בשבוע, והזמן עד סגירת הפרצה נמדד שוב בחודשים.
- הזמן עד סגירת הפרצה — תיקון קריטי נכנס לעדכון בשעות הראשונות לאחר פרסומו, ולא במחזור התכנון הבא: את העדיפות קובעת מדיניות לפי רמת החומרה.
- שיעור התיקונים ללא מעורבות אדם — גרסאות פאצ' ועדכוני תחזוקה ממוזגים אוטומטית לאחר בדיקות ירוקות, בדרך כלל 70–80% מהזרם. הסקירה נשמרת לגרסאות מאז'ור ולשינויים בממשקים ציבוריים.
- מספר הבנייות שנשברו — קיבוץ עדכונים לפי אקוסיסטמה והגבלה על תיקונים במקביל מסירים קונפליקטים על קובץ נעילה אחד.
- הזמן לניתוח ידני — סיכום אחת לשבוע במקום דואר יומי: המהנדס בוחן רק תיקונים שלא אושרו.
עבור מאגרים סגורים ואקוסיסטמות לא סטנדרטיות, אותם כללים מתוארים ב-Renovate — הקונפיגורציה נמצאת במאגר ומנוהלת בגרסאות יחד עם הקוד.
התוצאה מדידה: אבטחת התלויות מפסיקה להיות תלויה בחלון פנוי בלוח הזמנים, החוב הטכני בגין חבילות מיושנות מצטמצם, וזמן הבנייה אינו גדל בגלל גרסאות מצטברות.
Dependabot או Renovate: איזה מוד לבחור
הבוט המובנה של פלטפורמת GitHub ומתזמן חיצוני פותרים אותה משימה — אך משתלבים בתהליך בדרכים שונות.
Dependabot מוגדר בתוך המאגר עצמו ואינו דורש שירות נפרד שמישהו צריך להחזיק פעיל; Renovate פועל כמתזמן עצמאי עם קובץ קונפיגורציה במאגר, ויודע לסרוק פרויקטים רבים בבת אחת, כולל בפלטפורמות שונות. האפשרות השלישית — מוד ידני, שבו העדכונים מוכנסים לפי נוהל השחרור ונבדקים בידי אדם.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הבוט המובנה של הפלטפורמה | מאגרים בודדים, צוות בלי מהנדס ייעודי | כללי התיקון מוגבלים להגדרות הפלטפורמה, לוגיקת קיבוץ עדינה אינה זמינה |
| מתזמן חיצוני | מאגרים רבים, מונורפוזיטוריות, כללים משלכם לקבלת תיקונים | נדרשים קובץ קונפיגורציה וטוקן גישה, שמתעדכנים בעת החלפת הרשאות |
| מוד ידני | שליטה קפדנית בתלויות, שחרורים נדירים | התלויות מתיישנות מהר יותר משהידיים מגיעות; גרסאות פגיעות חיות שבועות |
על ההתנהגות בכל אחד מהמודים משפיעים ביותר לוח הזמנים של העדכונים והקיבוץ. בלי קיבוץ, תיקונים לשלושים תלויות מגיעים בשלושים בקשות מיזוג נפרדות — הסקירה טובעת ברעש, וכעבור שבועיים מפסיקים לקרוא אותה.
ההגדרה «לעדכן אחת לשבוע, גרסאות מינור בקבוצה אחת, מאז'ור בנפרד» מקטינה את הזרם לשני-שלושה מארזים לבדיקה, ואת עדכוני האבטחה משאירים מחוץ ללוח הזמנים.
המודים אינם שוללים זה את זה: את הבוט המובנה מתקינים במאגרים קטנים, ואת המתזמן החיצוני בפרויקטים גדולים עם כללים משלהם. המעבר ביניהם אינו חוסם את העבודה: הקונפיגורציות בלתי תלויות, והחזרה לאחור מסתכמת במחיקת קובץ ההגדרות ובחזרה ללוח הזמנים הקודם.
סדר היישום: מהאודיט ועד למסירה
הטמעת עדכון אוטומטי אינה התקנת בוט, אלא הגדרת מוד שבו תיקוני התלויות מגיעים באופן צפוי ואינם שוברים את הבנייה. אנו עובדים לפי תכנית קבועה: קודם לראות את תמונת התלויות האמיתית, אחר כך להסכים על הכללים, ורק לבסוף להפעיל את האוטומציה.
- אודיט תלויות. עורכים מלאי של חבילות ישירות ועקיפות, מפרידים בין production ל-dev, מאתרים ספריות לא בשימוש ונטושות. בפלט — טבלה עם סדרי עדיפויות: מה מעדכנים ראשון, ומה דורש התערבות ידנית.
- תכנית מדיניות העדכונים. קובעים קבוצות חבילות, לוח זמנים לבדיקות, והגבלה על תיקונים פתוחים במקביל. פאצ'ים וגרסאות מינור עוברים במיזוג אוטומטי בבדיקות ירוקות, מאז'ור — רק באישור ידני.
- הגדרת האוטומציה. רושמים את הקונפיגורציה, כללי התעלמות מחבילות בעייתיות, תגיות ואחראים. כל תיקון מקבל תיאור של השינויים וקישור לריליס, כדי שהסוקר לא יצטרך לנחש.
- הרצה על ענף בדיקות. מפעילים את זרם התיקונים בענף מבודד ובוחנים את ההתנהגות בפועל: כמה מגיע בשבוע, האם הבנייה והבדיקות עוברות, והיכן נוצרים קונפליקטים.
- ניתוח התיקונים הראשונים. עוברים ידנית על עשרת העדכונים הראשונים ומכיילים את הכללים: מסירים חבילות רועשות, מוסיפים בדיקות שהוחמצו, מגדירים סדרי עדיפויות.
- מסירה עם הדרכה. מוסרים לצוות את הקונפיגורציות, הנוהל וניתוח מצבים טיפוסיים: כיצד להחזיר תיקון לאחור, כיצד לעצור את הזרם, ומה עושים בקונפליקט גרסאות.
לאחר המסירה נשארת לצוות תכנית עובדת וסדר פעולות ברור — העדכונים זורמים ברקע, ואינם הופכים למרתון חירום לפני הריליס.
קונפיגורציות, כללים ונהלי עדכון
בפלט נשאר במאגר לא אוסף תיקונים חד-פעמיים, אלא מעגל עדכונים עובד: קונפיגורציה תחת בקרת גרסאות, כללי מיזוג ונוהל שלפיו התור מנותח בלי מעורבותנו. להלן רשימת התוצרים וייעודו של כל אחד.
- קובץ קונפיגורציה — לוח זמנים לבדיקות, הגבלה על בקשות פתוחות במקביל, רשימת האקוסיסטמות והתיקיות שהכלי סורק או מתעלם מהן.
- כללי קיבוץ — עדכונים קשורים של ספרייה אחת או של סט אחד (בדיקות, לינטרים, טיפוסים) נאספים לבקשה אחת, כדי שתור הסקירה לא יתפח.
- מטריצת מיזוג אוטומטי — שורה-שורה: סוג העדכון (פאצ', מינור, מאז'ור), מצב סט הבדיקות, מי רשאי למזג. פאצ' בבדיקות ירוקות עובר מעצמו, מאז'ור ממתין לסקירה ולהרצה ידנית של תרחישים.
- מטריצת חריגים — חבילות הנעולות על ענף מסוים, עם ציון הסיבה: אי-תאימות לריצה הנוכחית, היעדר תמיכה, המתנה למעבר מתוכנן.
- נוהל עדכונים ותורנויות — מי מנתח את התור, באילו ימים, זמן התגובה להתראה על פרצה קריטית, ומה עושים כשסט הבדיקות אדום.
- נוהל החזרה לאחור — כיצד מבטלים מיזוג אוטומטי, על איזה ענף נבדקת ההחזרה, ואילו תגיות מראות שהכלל פעל.
- תיעוד וצ'ק-ליסט קבלה — כיצד להעמיד חבילה חדשה תחת מעקב, כיצד לבדוק שהכלל פעל, והיכן מתועדת סיבת החריג, כדי שכעבור חצי שנה יבין אותה כל מהנדס.
מקרה בוחן: כיצד זרם העדכונים הפסיק להצטבר
מה היה לפני
הפרויקט — כמה שירותים, שבהם את המניפסטים וקבצי נעילת הגרסאות תיקנו ידנית, אחת לרבעון. עד רגע הניתוח הצטברו יותר ממאה תיקונים פתוחים, חלקם תלו חודשים, ופרצה בתלות עקיפה נסגרה בתוך שלושה-ארבעה שבועות. ענף השחרור נפל בערך בכל בנייה שלישית — אי-תאימות גרסאות צפה כבר בזמן ההוצאה.
מה שינו
הגדרנו את Dependabot בקבוצות: פאצ' ועדכוני מינור של חבילות קשורות מגיעים בתיקון אחד, ולכן כמעט אין קונפליקטים בקובץ הנעילה. הפעלנו מיזוג אוטומטי של תיקונים — רק בבדיקות ירוקות ובהרצת בדיקות מלאה, בחלון שאינו בזמן הריליס.
גרסאות מאז'ור הועברו לתור נפרד עם ניתוח ידני ותיאור של שינויים שוברים; החזרה לאחור — החזרת קובץ הנעילה הקודם.
מה קרה בסוף
כשלוש רביעיות מהתיקונים מתקבלים אוטומטית. את השאר המהנדס סוקר בדקות: העדכונים כבר מקובצים, והשינויים קומפקטיים. הזמן עד סגירת הפרצה הצטמצם משבועות לשניים-שלושה ימים — התראה על בעיה בתלות הופכת לתיקון שהתקבל כבר למחרת בבוקר.
הבנייות שנשברו בגלל עדכון בענף השחרור פחתו פי כמה: אי-תאימויות נתפסות בתיקונים קטנים, ולא בזמן ההוצאה. מספר התיקונים הפתוחים נשמר בסביבות עשרה — זרם העדכונים הפסיק להצטבר.
מה עושים אם Dependabot פתח מאות תיקונים?
אם Dependabot פתח מאות תיקונים, אין אלו מאות משימות, אלא חוב תלויות אחד שהצטבר חודשים והתפרץ בבת אחת. אי אפשר למזג הכול בזה אחר זה: בין התיקונים המצטברים יש גם פאצ'ים של אבטחה וגם עדכוני מאז'ור ששוברים את הבנייה.
מתחילים מקו בסיס — מביאים את הענף הראשי למצב נעול של קובץ ה-lock, ורק ממנו מחשבים מה באמת דורש תשומת לב.
מכאן — ניתוח תור העדכונים לפי רמות סיכון. גרסאות פאצ' ותיקוני אבטחה נכנסים למנה הראשונה: מריצים אותם בבדיקות אוטומטיות וממזגים בקבוצות לפי אקוסיסטמה, ולא תיקון-תיקון. גרסאות מינור — המנה השנייה, לאחר שהראשונה מתייצבת בסביבת הבדיקות. מאז'ור עוברות ברשימה נפרדת: כל אחת נקראת לפי תיאור השינויים ונבדקת ידנית.
מגבילים את המנות, אחרת הניתוח יימשך חודשים: לא יותר מאחד-שניים עדכונים מקובצים ביום, ורק לאחר בדיקות ירוקות. בבוט עצמו מפעילים קיבוץ לפי אקוסיסטמה, לוח זמנים במקום זרם תיקונים יומי, ועיכוב לזמן החיים המינימלי של הריליס — הגרסה הטרייה מספיקה להתייצב לפני כניסתה לתור.
את השורש סוגרים בנפרד: הגבלה על מספר התיקונים הפתוחים במקביל, מיזוג אוטומטי של פאצ'ים לאחר בדיקות, ונוהל למעברי מאז'ור עם תכנית החזרה לאחור. אז החוב בתלויות מפסיק לגדול ואינו חוזר כעבור רבעון: התור נמדד בעשרות תיקונים במקום במאות.
ספקות טכניים נפוצים בנוגע לעדכון אוטומטי
מיזוג אוטומטי, החזרה לאחור וגישה למאגרים פרטיים — שלוש הגדרות שמכריעות אם אפשר בכלל למסור עדכוני תלויות לרובוט. ב-Dependabot ובבוטים דומים אנו מגדירים את הכללים כך שהבנייה השבורה לא תיכנס לענף הראשי, וכל גרסה ניתן יהיה להחזיר בפעולה אחת.
האם המיזוג האוטומטי חל על כל העדכונים?
לא — רק לגרסאות פאצ' בתוך ענף המאז'ור הנוכחי: שם אין שינויים בהתנהגות הציבורית. עדכוני מינור ומאז'ור, וכן תלויות של ריצה ובנייה, עוברים בבקשות מיזוג נפרדות, דרך הצינור וסקירת מהנדס.
מה עושים אם הבנייה נפלה לאחר עדכון?
הצינור חוסם את המיזוג כבר בנפילת הבדיקות הראשונה — ענף הבוט אינו נכנס לענף הראשי. החזרה לאחור — החזרת קובץ הגרסאות המדויקות לגרסה הקודמת: הוא נועל גם תלויות ישירות וגם עקיפות, ולכן הבנייה חוזרת למצב משוחזר בביטול אחד.
האם הבוט רואה חבילות פרטיות?
כן, דרך טוקן גישה למאגר הפנימי — הוא מונח בסודות הצינור ומעניק קריאה בלבד. הבוט מקבל רשימת גרסאות ומטא-נתונים, אך אינו יכול לפרסם או למחוק חבילות; הטוקן מוגבל בהיקפו ומבוטל ברישום אחד.
כיצד נפתרים קונפליקטים בתלויות?
קונפליקט בקובץ הגרסאות המדויקות הבוט פותר בעצמו: בונה מחדש את הענף מעל הענף הראשי ומחשב מחדש את הגרף. קונפליקט בקוד, כאשר נגעו בקבצים עם תיקונים ידניים, חוסם את המיזוג האוטומטי — המשימה עוברת למהנדס, ושינויים של אחרים אינם נמחקים.
נדון בתכנית עדכון התלויות שלכם
כדי שתכנית העדכונים תעבוד מההרצה הראשונה ולא לאחר כמה איטרציות, אנחנו צריכים קלט קצר על המאגר שלכם. להלן מה שאנחנו מבקשים בהתחלה ומה שאנחנו מחזירים: מנתונים אלה תלויים תדירות הבדיקות, רמת המיזוג האוטומטי והתנהגות הבוט בקונפליקטים.
- הרכב המאגרים ומנהלי החבילות — היכן נמצאות התלויות, האם יש מאגרים פרטיים, ואילו ענפים חסומים בפני עדכונים חיצוניים. מכך תלוי כיצד להגדיר Dependabot ו-Renovate כך שזרם בקשות המיזוג לא יסתום את תור הסקירה.
- תכנית ההסתעפות ומוד ההוצאות. אם הריליס אחת לשבועיים, נסנכרן את מרווח העדכונים איתו ונכוון לענף הפיתוח, ולא לענף הראשי.
- דרישות אבטחה — האם אתם מגיבים רק לפרצות קריטיות או לכולן. אנו מגדירים עדכונים קבוצתיים, חתימות קומיטים ובדיקת מקור החבילות.
- כללי מיזוג: מה מתקבל אוטומטית (פאצ'ים וגרסאות מינור), ומה דורש סקירה ידנית. מיזוג אוטומטי מפעילים רק בבדיקות ירוקות.
- סט הבדיקות לפני המיזוג — בדיקות, לינטרים, בנייה. ככל שהכיסוי צפוף יותר, אפשר לפתוח אוטומציה רחבה יותר בלי סיכון לענף הראשי.
- הרשאות והתראות: טוקנים לקריאת מאגרים, הרשאות ליצירת ענפים, ערוץ התראות ואחראי על עדכונים תקועים.
בפלט תקבלו קבצי קונפיגורציה לכל מאגר, מדיניות עדכונים עם לוח זמנים, כללי מיזוג אוטומטי ותכנית עבודה עם נקודות בקרה. מכאן, לפי בחירתכם, נעביר את הפרויקט לתחזוקה או נלווה אותו יחד עם הצוות שלכם. תארו את המשימה — נחזור עם הערכה ותכנית המותאמת לתכנית ההסתעפות שלכם.