מערכת AI ליצירה אוטומטית של צינורות CI/CD

יצירה אוטומטית של CI/CD: היכן צינורות ידניים נשברים

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

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

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

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

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

מה משתנה לאחר ההטמעה: אפקטים מדידים

בניית השחרור מתבצעת במעבר אחד

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

שחזור הצינור נמדד בדקות

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

מחלקת כשלים עקב תיקון ידני בוטלה

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

יכולת חיזוי של שחרורים

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

האפקט של אוטומציית הבנייה

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

אפשרויות ליצירה אוטומטית של צינורות: השוואת גישות

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

השוואת גישות

מה נשאר באחריות המהנדס

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

שלבי הטמעה: מביקורת מאגרים ועד מסירה

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

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

מה נשאר במאגר לאחר מסירת העבודות

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

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

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

מקרה בוחן: איך הצוות הפסיק לתקן צינורות בידיים

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

כמה זה עלה לפני ההטמעה

שני מהנדסים החזיקו תור משימות נפרד לתיקוני תצורות: לעדכן גרסת אימג', להוסיף שלב בדיקות, לשנות תנאי פרסום. תיקון טיפוסי התגלגל ל-30–40 מיזוגים וארך 2–3 ימים, והפערים הצטברו: חלק מהשירותים נבנו לאט יותר רק מפני שהתיקון לא הגיע להעתק התבנית שלהם.

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

מה קרה אחר כך

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

העברנו בשלבים: צילום מצב של התצורות הנוכחיות, יצירה לצד הידנית, השוואת שלבים, מעבר שירות-שירות עם אפשרות לחזור. כעבור חודשיים כ-90% מהשינויים מוזנים למודל, זמן הבנייה ירד ל-8–11 דקות בזכות מטמון משותף, שחרורים עם תצורה שבורה — 1–2 ברבעון. החזרה לאחור פשוטה: הקובץ המחולל נמצא במאגר ונראה בהיסטוריה.

מה לעשות אם הצינורות כבר נכתבו ידנית?

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

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

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

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

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

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

איך מוגנים הסודות והגישות בבנייה?

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

למה צריך שרת בנייה משלנו?

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

איך בודקים את הצינור לפני הפעלה ומה עם התחזוקה?

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

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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