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

הפוסט, שפורסם בבלוג ההנדסה של Linear ב-21 בספטמבר, התחיל, כפי שדברים אלה עושים לעתים קרובות, בכרטיס קצר מלמעלה. מוקדם יותר השנה, אמג'ד פתח את Linear כדי לגלות ש-Tuomas, ה-CTO של החברה, הקצה לו נושא שכותרתו "עלויות ה-CI גבוהות" - וביקש ממנו להפוך את ה-CI למהיר יותר בזמן שהוא עוסק בזה. להקשר נוסף על הסיפור הזה, עיין בסיקור תעשיית הבינה המלאכותית שלנו.

כאשר סוכנים עוברים את האימות

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

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

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

מכונות מהירות יותר ומהדר מקורי

חלק מהרווחים המוקדמים ביותר לא דרשו כמעט אופטימיזציה של ה-CI עצמו. העברת עומסי העבודה מ-GitHub Actions לרצים של צד שלישי עם מעבדים מהירים יותר, אחסון בעל ביצועים גבוהים יותר ותשתית מטמון טובה יותר השתלם באופן מיידי: בהשוואה דומה של היומיים משני צדי המתג, עבודות רצו ב-34% מהר יותר בממוצע, עם עומסי עבודה מסוימים כמו `tsc` ירדו ב-52%.

מודרניזציה של שרשרת הכלים החריפה את הניצחון. המעבר ל-'tsgo', מהדר TypeScript המקורי, חתך את החציון השבועי של בדיקת הטיפוס ב-73% - גדול מספיק כדי להזיז את צוואר הבקבוק מבדיקת הסוג לחלוטין.

מוך ללא גרף הסוג

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

הצוות כתב מחדש את הכללים כדי להשתמש בניתוח סטטי על עץ התחביר המופשט, תוך זיהוי מבנים דמויי פונקציות ודפוסי שמירה ללא מידע מסוג כלשהו. זה נתן ל-ESLint להוריד לחלוטין את TypeScript, והפחית את זמן המוך של ה-API ב-68% ואת זמן המוך של המאגר המלא ב-55%, כאשר השימוש בזיכרון ירד באופן משמעותי. זה גם הקל על ההגירה המאוחרת ל-Oxlint, מה שהפחית עוד יותר את הדקות של רצי ה-CI שהושקעו על מוך.

כיווץ הנתיב הקריטי

עם בדיקות בודדות מהר יותר, Linear התרחק והתייחס ל-CI כמערכת. זה משך את תשומת הלב למשימות הקטנות שעומדות מול כל השאר - זיהוי שינויי נתיב ומטמון של תוצאות בדיקה בודק את השער הזה ברמת העבודה, כלומר אף אחד משמונה רסיסי בדיקת ה-API לא יכול להתחיל עד שהם מסתיימים.

התיקונים היו פרטניים אך תוספים. מכסת עומק האחזור לקחה את השער האיטי ביותר מ-94 שניות ל-20. הסרת הקופה לחלוטין מעבודות שמעולם לא נזקקו לעץ עובד חתכה את אלה מ-27 שניות ל-7. קופה דלילה ללא כתמים עם היסטוריה מוגבלת חסכה עוד 11 שניות מוזרות לאירועי דחיפה ומיזוג בתור. במצטבר, משך הזמן החציוני של עבודת זיהוי השינוי ירד מ-26 שניות ל-8, ה-p90 שלה מ-31 ל-12, והריצה האיטית ביותר שלה מ-138 שניות ל-37.

גם אמינות התשלום דרשה עבודה: מכיוון שהרצים של צד שלישי יושבים מחוץ לרשת של GitHub ומסתמכים על קישור IP ישיר, השפלה לסירוגין של קישור עצרה מדי פעם את השליפות. ליניארי החליף את 'פעולות/תשלום' בפעולה מורכבת משלה שמנסה שוב עם גיבוי, מגדירה את 'GIT_HTTP_LOW_SPEED_LIMIT' ו-'GIT_HTTP_LOW_SPEED_TIME' כך שחיבור שנתקע מופסק לאחר כ-30 שניות במקום להיתקע, ומשתמש במטמון קופה ששומר על דיסק קבוע ב-giyt.

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

פחות שניות מבוזבזות לכל עבודה

עלות ההתקנה האחרונה שהותקפה בקטגוריה חוזרת על עצמה בכל עבודה. כל רסיס מבחן API בילה 7 עד 8 שניות בהתקנת אותו לקוח Postgres עם apt בכל הפעלה; העברת אותו לתמונת בסיס קטנה של CI לצד Node פירושו שרסיסים יכולים להתחיל מוכנים לפעול. מאוחר יותר הצוות הוסיף כותרות בנייה מקוריות לתמונה לאחר שגילה שהורדתן במהלך ההגדרה עלולה להיתקע מדי פעם.

למה זה הדהד

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

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

---

הישאר לפני AI

קבל את החדשות, הניתוחים ופריצות הדרך האחרונות של AI - הכל במקום אחד.

קרא עוד חדשות AI →