Woodpecker CI: היכן נקרע צינור הבנייה
הבנייה נופלת בשלב שאתמול עבר ללא שינויים, ובאופן מקומי הכול ירוק — סימן קלאסי לחוסר סנכרון בין סביבות. גרסת סביבת ההרצה בסוכן, סט ספריות המערכת והמשתנים שונים מאלה שהמפתח רואה.
כל עוד סביבת הבנייה אינה מתוארת באופן דקלרטיבי, כל הרצה היא הגרלה, והזמן הולך לא על תיקון קוד אלא על חיפוש "במה השרת היום שונה".
צוואר הבקבוק השני של הצינור — שלבים ידניים בין השלבים. תג התמונה מוצב ידנית, המיגרציות מופעלות בפקודה נפרדת, הסודות מועתקים למשתני הפרויקט בלי הפרדה לפי שלבים. כל שלב שהוחמץ לא שובר את הבנייה מיד, אלא צף בעת הפריסה, ולכן נפילות בנייה מיוחסות לא לסיבה אלא לתוצאה.
היעדר בידוד בין משימות מחמיר את זה: שלבים מקבילים כותבים לאותה תיקיית עבודה משותפת ומשבשים זה לזה את הארטיפקטים.
המקור השלישי — קבצי תצורה תפחו. כשקובץ אחד מתאר עשרה שירותים, תנאים לפי ענפים ובלוקים חוזרים, כל תיקון דורש רגרסיה של כל הצינור. המטמון של התלויות אינו מופרד לפי משימות, ובנייה אחת מנפחת אותו עד כדי כך שהבאות אחריה מתחילות לאט יותר מאשר בנייה מאפס.
המחיר של כל שלושת הגורמים זהה — מהדורות ארוכות. הפריסה מפסיקה להיות פעולה שגרתית, הזמן מהקומיט ועד לפרודקשן גדל, ולעיתים לא ניתן לחזור לתמונה הקודמת, כי הארטיפקט הדרוש כבר נדחק החוצה. בהמשך נפרק כיצד זה נסגר ב-Woodpecker CI: בידוד שלבים, הגדרות משותפות וכללים צפויים לשמירת תמונות.
מה נותנת בנייה מנוהלת ואספקת קוד
הצינור מפסיק להיות תור: בנייה, בדיקות, בדיקות סגנון ופרסום ארטיפקטים רצים בשלבים מקבילים, ולכן הזמן הכולל נקבע לפי הענף הארוך ביותר ולא לפי הסכום של כולם.
בפרויקט טיפוסי המסלול מקומיט ועד ארטיפקט מוכן מתקצר פי כמה — וגם בלי החלפת חומרה: האפקט נובע מהקבלה יחד עם מטמון תלויות בין הרצות.
הסביבה של כל שלב מתוארת באופן דקלרטיבי: Woodpecker CI מקים אותה מחדש בכל הרצה. בגלל זה הפער "עובד מקומית, נופל בשרת" נעלם — נעלמים אי-התאמות בגרסאות תלויות, משתנים שנשכחו ועקבות של בניות קודמות בתיקיית העבודה. סביבה זהה בכל השלבים, מבדיקה ועד מהדורה, משמעותה שנפילה משוחזרת לפי מספר הבנייה, לא לפי הזיכרון.
ההתאוששות אחרי כשל נמדדת בדקות, לא במעבר חוזר על כל השרשרת: שלב שנפל מופעל מחדש בנפרד, עם מטמון שכבר חם. עבור התורן זה ההבדל בין "להפעיל מחדש בדיקה אחת" לבין "לחזור על הכול מאפס", ועבור הצוות — פחות פעולות ידניות ברגע שבו המשוב נדרש מהר מכול.
כשהם מצטברים, האפקטים האלה מסירים מחלקה שלמה של כשלים — כשלי סביבה, לא כשלי לוגיקה: הבנייה מפסיקה להיות תלויה במכונה שבה הורצה. אנחנו מקבעים זאת כמדדים מדידים — זמן מעבר, שיעור הרצות חוזרות, זמן התאוששות — ועוקבים אחריהם לאחר מסירת המערכת.
אפשרויות פריסה של Woodpecker CI: השוואה
הפריסה של Woodpecker CI מצטמצמת לשלוש החלטות: היכן חי השירות המנהל, על אילו צמתים מתבצעות המשימות ובמה מבודדת כל בנייה. מזה תלויות דרישות ההרשאות, הגישה לשקע של הקונטיינר והאם אפשר להגדיל את מספר הבניות המקבילות בלי לבנות מחדש את כל הסכימה.
אותה תצורה לעיתים רחוקות מתאימה גם למתאר קטן וגם לצוות עם עשרות משימות מקבילות. להלן חלופות אמיתיות שבוחרים ביניהן בעת התקנה ובעת מיגרציה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שירות מנהל וסוכנים על צומת אחד | מתאר אחד, בודדים של בניות במקביל | אין מרווח משאבים: בנייה כבדה מאטה את הממשק ואת האירועים מהמאגר |
| סוכנים על צמתים נפרדים | כמה צוותים, נדרש גידול במספר המשימות המקבילות | נדרש מטמון משותף והגדרת תוויות, אחרת משימה מגיעה לצומת הלא נכון |
| הרצת משימות בקונטיינרים | בניות רגילות, בדיקות, בניית ארטיפקטים | הבידוד נשען על כללי גישה לשקע; בניית תמונות דורשת מצב נפרד |
| הרצת משימות ישירות על הצומת | בניות עם גישה למארח או לחומרה | אין בידוד בין פרויקטים — מקצים את הצומת למבצע מהימן אחד |
| סוכנים באשכול תזמור | עומסי שיא, סביבה ארעית לכל משימה | ניפוי שגיאות קשה יותר: לוגים וארטיפקטים חיים בדיוק כל עוד המשימה חיה |
קודם מקבעים את המתאר, פרופיל העומסים ודרישות הבידוד — ורק אחר כך בוחרים אפשרות. אחרת בשלב הצמיחה צריך להעביר סוכנים ולשכתב תסריטי בנייה למצב החדש.
שלבי הטמעה: מביקורת ועד מסירה
ההטמעה מתבצעת בשלבים, וכל שלב נסגר בתוצאה ניתנת לבדיקה — אחרת המעבר ל-Woodpecker CI הופך לניפוי שגיאות ישירות על מהדורות ייצור.
הצעד הראשון — ביקורת הצינור: מתעדים כיצד הבניות עוברות כעת, היכן נותרו פעולות ידניות, אילו ענפים ותגיות מפעילים פרסום, מאין מגיעים הסודות וכמה נמשכת הרצה טיפוסית. לפי הנתונים האלה מתכננים את סכימת הבנייה ורק אחר כך נוגעים בסביבת העבודה.
- ביקורת הצינור. מלאי של הבניות הנוכחיות: משך השלבים, שיעור ההרצות שנפלו, תלויות בין שירותים, שלבים ידניים שמשאירים את המהדורה תלויה באדם.
- תכנון סכימת הבנייה. פריסת השלבים לפי ענפים מקבילים, כללי הפעלה לפי ענפים ותגיות, מטמון תלויות, סט אחיד של בדיקות חובה לפני מיזוג.
- הגדרת סוכנים והרשאות. סוכנים לסוגי משימות שונים, הרשאות לפי עקרון המינימום הנדרש, סודות באחסון מאובטח, הרשאות נפרדות לסביבות ולפרסום.
- בדיקת בניות על משימות אמיתיות. הרצה על מאגר ייצור וענפים אמיתיים: משווים זמן ויציבות לסכימה הקודמת, מתרגלים חזרה לאחור והפעלה מחדש של שלב בודד שנפל.
- מסירה לתחזוקה. סכימה ונוהל שינויים בתיעוד, התראות על נפילות וירידת ביצועים בזמן, הדרכת הצוות, נקודת כניסה מוגדרת לשאלות.
מה נשאר במאגר: קבצים, סכימות, נהלים
כל מה שמתואר בפרויקט נשאר במאגר שלכם, לא בהתכתבות עם הספק. אפשר להקים סביבה שנייה, לשנות שלב בנייה או לצרף מהנדס חדש על ידי קריאת הקבצים והנוהל — בלי לפנות אלינו.
- קבצי תצורה של הצינור — אחד לכל ענף ולכל סביבה, עם הערות: מה עושה השלב, אילו סודות הוא צריך, באילו תנאים הוא מדולג.
- סכימות הצינור — סדר המשימות, נקודות ההרצה המקבילה, מה חוסם פריסה לענף הראשי ואילו בדיקות חובה לפני מיזוג.
- סכימת האינטראקציה בין הצמתים — היכן חי השרת המנהל, היכן הסוכנים, לאן נשמרים ארטיפקטים ותמונות, אילו רשתות ופורטים חייבים להיות פתוחים ביניהם.
- מדיניות גישה — תפקידים בפאנל הניהול, הרשאות להפעלה ולביטול בניות, מי יכול לערוך סודות וכללי הגנת ענפים.
- עבודה עם סודות — היכן נשמרים מפתחות וטוקנים, כיצד הם ניתנים לשלב מסוים, כיצד מתבצעת רוטציה כשעובד עוזב.
- תיעוד — כיצד לפרוס את הצינור מאפס, כיצד לחזור למהדורה קודמת עם הארטיפקט הקודם, לאן להסתכל כשבנייה נופלת או כשמאבדים קשר עם סוכן.
- נוהל תחזוקה — תדירות עדכון הצמתים והצינור עצמו, ניקוי לוגים וארטיפקטים ישנים, גיבוי מצב ובדיקת שחזור.
כל מסמך נכתב עבור הצוות שלכם, לא עבורנו: עם שמות אמיתיים של צמתים, ענפים וסביבות. הקבלה מתבצעת לפי צ'קליסט — אנחנו עוברים עליו יחד עם המהנדס שלכם, כדי שהמסירה לא תהפוך לפורמליות.
מקרה בוחן: העברת בניות ומדדים לפני ואחרי
לקוח הגיע עם צינור על שרת בנייה משותף: מבצע אחד, תור קבוע, מטמון תלויות בין משימות אינו מנוצל מחדש, פרסום ארטיפקטים — ידנית לפי הוראה בוויקי. זמן המעבר הממוצע של בנייה עמד על כ-14 דקות, בשעות שיא המהדורה נכנסה לתור, ועד שליש מהנפילות נבעו מתשתית ולא מקוד. המהנדסים התרגלו להפעיל מחדש משימות שנפלו עד ל"ירוק" — פגמים אמיתיים אבדו ברעש הזה.
מה עשינו במעבר
העברנו את הבניות ל-Woodpecker CI, את התצורה הוצאנו לקובץ דקלרטיבי לצד הקוד, את השלבים הפרדנו לשלבים עם תמונות משל עצמם. את המבצעים אספנו למאגר עם הרחבה אוטומטית — ענפי שיא הפסיקו לחסום ענפי מהדורה.
מטמון התלויות והארטיפקטים הפכנו למשותף בין הרצות, הוספנו מטריצת בדיקות לשני סביבות יעד ושלב פרסום נפרד עם אישור ידני.
מדדים לפני ואחרי
זמן המעבר של בנייה התקצר מ-14 ל-6 דקות, שיעור התקלות בגלל תשתית ירד מ-12% ל-2%. חזרה לארטיפקט הקודם — פעולה אחת במקום בנייה ידנית, המהדורה כבר לא תלויה במי שנמצא בתורנות.
תדירות המהדורות עלתה בערך פי שניים באותו גודל צוות, וההפעלות מחדש "עד ירוק" כמעט נעלמו: נפילת בנייה מעתה מסמנת פגם בקוד, ולסימן הזה סומכים.
ספקות טכניים לפני תחילת העבודה
ספקות הנדסיים לפני התחלה הם כמעט תמיד אותם ספקות: היכן עוברים גבולות הפתרון, מה יהיה צריך לשנות בתשתית הנוכחית ואיך נראה המסלול חזרה. להלן תשובות למה ששואלים לרוב לפני תחילת העבודה: תאימות לאחסון הקוד, סדר המעבר, חזרה לאחור והפרדת הרשאות.
האם Woodpecker תואם לאחסון הקוד שלנו
הוא עובד עם שרתי ניהול קוד ציבוריים ופרטיים שנפרסו במתאר שלכם דרך וובהוקים וטוקן גישה למאגר — אין צורך בפלטפורמה נפרדת לכך. אם המתאר סגור, הסוכנים מותקנים בתוכו ופונים החוצה רק לעדכוני תמונות.
האם אפשר לעבור בהדרגה בלי לעצור את הבניות
כן. צינורות חדשים מוקמים במקביל לקיים, ההפעלה נעשית מאגר אחד בכל פעם, והתוצאה מושווית על אותם קומיטים. כל עוד המסלול החדש לא מפיק את אותם ארטיפקטים, הישן נשאר ראשי ואף אחד לא ממתין.
כיצד לחזור משינויים ומי מקבל הרשאות
תיאור הצינורות נמצא במאגר לצד הקוד, ולכן חזרה לאחור היא קומיט הפוך, לא עריכת הגדרות בפאנל זר. הסודות נשמרים במופע עצמו ומוזרקים בשלב ההרצה: הגישה מוגדרת ברמת הצוות ואינה שוקעת בלוגים של הסוכן.
מה המגבלות של הפתרון
Woodpecker אינו מחליף מארגן קונטיינרים ואינו מתאים למקומות שבהם צריך לשמר מצב בין הרצות. החוזק שלו — צינורות צפויים של בנייה, בדיקות ופרסום; סביבות כבדות וניהול אשכול נשארים שכבה נפרדת.
מה לעשות אם הבניות כבר פרוסות אחרת?
עצירה מלאה והעברת כל הבניות בלילה אחד — האפשרות הגרועה ביותר: כל אי-תאימות צפה בדיוק ברגע המהדורה. תרחיש העבודה שונה — שרת הבנייה הישן ו-Woodpecker CI עובדים במקביל לזמן מה, והמאגרים מוחלפים אחד אחד.
העברת תצורות ניתנת למיכון: תיאורי הבניות נמצאים במאגרים לצד הקוד, ולכן המעבר לא דורש לשכתב את הלוגיקה מאפס. בנפרד מעבירים סודות, משתני סביבה והרשאות גישה — אותם בונים מחדש לפי התיעוד, ולא מייצאים מהמערכת הישנה, כדי לא לגרור אחרינו פרטי חשבון מיושנים.
היסטוריית הבניות אינה מועברת שורה-שורה, וזו לא אבידה. את השרת הישן מחזיקים במצב קריאה לכל תקופת המעבר: לוגים, ארטיפקטים וסטטוסים של הרצות קודמות נשארים זמינים בקישורים הקודמים, וההיסטוריה החדשה מצטברת מההרצה הראשונה במערכת החדשה.
עוברים בגלים: קודם שניים-שלושה מאגרים עם זרימת השינויים הפעילה ביותר, אחר כך השאר בקבוצות. את וובהוקים של ההפעלה מחליפים אחד אחד, ולכן עד להחלפה הצוות עובד כרגיל והמהדורות אינן תלויות בקצב המיגרציה. אם בנייה במקום החדש מתנהגת אחרת — המאגר חוזר לכתובת הקודמת בתיקון הגדרה אחד.
כשכל מאגר עבד במסלול החדש כמה הרצות, את המערכת הישנה מוציאים מפעילות: מבטלים הרשאות, עוצרים סוכנים, משאירים נקודת כניסה אחת. מעבר משרת בנייה אחר עובר בלי לעצור את הפיתוח.
נדבר על המשימה: מה להכין לשיחה
כדי שהשיחה תהיה עניינית ולא סקירה כללית, כדאי לאסוף מראש כמה נתוני פתיחה. אין צורך להכין משהו מיוחד — די במה שכבר קיים בצוות ובמערכות ניהול הגרסאות.
ככל שנתוני הפתיחה מדויקים יותר, כך קצר יותר המסלול להערכה: מהם רואים את היקף המעבר, מספר צומתי הבנייה ומה מהתיעוד חסר לצוות שלכם אחרי ההפעלה.
- מלאי הבניות. אילו מאגרים נבנים, לאילו ענפים מגיבה ההפעלה, מה רץ לפי לוח זמנים ומה לפי אירוע במאגר.
- הרשאות למאגרים. חשבון שירות עם הרשאות קריאה ולוובהוקים — ולא חשבון אישי של מהנדס שכבר עבר פרויקט.
- גבולות המתאר. היכן יחיו סוכני הבנייה, האם יש רשתות מבודדות בלי יציאה החוצה, והאם נדרש מצב סגור לחלוטין.
- נקודות פליטה. רישום תמונות, עמדות בדיקה וסביבות: לאן לשמור תוצאות בנייה ומאין לקחת סודות ומפתחות חתימה.
- תקלות נוכחיות. מה נשבר לרוב, כמה נמשכת הבנייה הארוכה ביותר, אילו שלבים כבר מבוצעים ידנית ועל ידי מי בדיוק.
- ציפיות ללוחות זמנים. התאריך שעד אליו נדרש מתאר פעיל, והאם יש חלון למעבר בלי לעצור מהדורות נוכחיות.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית שבה ייראו השלבים, נקודות הבקרה ומה שתקבלו בסוף.