תהליכי CI/CD ב-Drone CI: אוטומציה של בניות ופריסה ב-Kubernetes

בניות ב-Drone CI: מה נשבר כשפרויקטים גדלים

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

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

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

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

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

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

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

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

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

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

מצבי הרצה של בניות: ענן, סוכנים עצמאיים, היברידי

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

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

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

הטמעת Drone CI: שלבי עבודה הנדסית

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

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

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

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

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

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

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

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

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

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

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

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

המערך לפני השינויים

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

מה שינינו ומה קיבלנו

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

הבנייה החציונית התקצרה מ-38 ל-9 דקות, שיעור ההצבות האוטומטיות עלה ל-95%. החזרה לאחור — הרצה חוזרת של הפייפליין המוצלח הקודם: כמה דקות במקום שעות.

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

ספקות טכניים: סודות, מטמון, סוכנים עצמאיים

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

מטמון מאיץ את הבנייה — האם הוא לא שובר את יכולת השחזור?

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

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

האם נדרשים סוכנים משלנו או שמספיקים בענן?

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

כבר עובד מערך אחר — להעביר הכול בבת אחת?

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

נדון במשימה: מה לשלוח להערכה מהירה

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

מה לשלוח:

• קישורים למאגרים והרשאות קריאה להגדרות הפייפליין — נראה כיצד מאורגנים בנייה, בדיקות ופרסום אימג'ים.
• קונפיגורציות בנייה ופריסה: קבצי בניית אימג'ים, מניפסטים של Kubernetes, סכימות סביבות ומשתנים.
• תיאור סביבות — כמה אשכולות, אילו סביבות (פיתוח, קדם-פרודקשן, פרודקשן), מי וכיצד מקבל גישה.
• סכימת עבודה עם סודות ומאגר אימג'ים: היכן נשמרים מפתחות, כיצד מוענקות הרשאות, האם יש הפרדה לפי סביבות.
• תהליך השחרור הידני הנוכחי: כמה זמן אורכים בנייה, בדיקות והצבה, באיזה שלב הכי часто נשבר.
• דרישות אבטחה: בדיקות פגיעויות, חתימת אימג'ים, הפרדת הרשאות, תיעוד פעולות.
• מצב השחרורים הרצוי: תדירות הצבות, חלונות עדכון, דרישות לחזרה לאחור ולזמן השבתה מותר.

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

במה סוכני בנייה עצמאיים נבדלים מניהוליים?

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

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

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

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

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

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

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