למה בנייה ידנית שוברת שחרורים: מתי צריך להגדיר Bamboo
בנייה ידנית של שחרורים נשענת על זיכרון והסכמות. כל עוד יוצא שחרור אחד לשבועיים, מהנדס בונה את הענף, מריץ בדיקות מקומית ומעתיק את הארטיפקט לסביבת הבדיקה.
ברגע ששחרורים נעשים תכופים יותר או שמפתח שני מצטרף לצוות, השלב „לבנות כמו בפעם הקודמת” הופך להגרלה: לכל אחד גרסת תלויות משלו, משתנים משלו וסדר פקודות משלו.
בנייה שאינה ניתנת לשחזור היא המקור העיקרי לפגמים שקטים. ארטיפקט ממכונת המפתח וארטיפקט מסביבת הייצור נבדלים בהרכב התלויות ובפרמטרי הבנייה, ולכן באג ש„משתחזר רק בפרודקשן” אינו מיסטיקה, אלא תוצאה של תנאי קלט שונים.
חוסר סנכרון בין סביבות מוסיף את החלק השני: קונפיגורציות של סביבת הבדיקה וסביבת הייצור נערכות ידנית ונפרדות זו מזו בתוך שבועות ספורים.
סיכון נפרד הוא שחרורים שנשענים על אדם אחד. הרשאות, סקריפטים לפריסה וסדר החזרה לאחור חיים בראש שלו ובתיקייה מקומית, ולא במאגר הקוד. חופשה או מעבר לפרויקט אחר עוצרים את השחרור, וחלון החזרה לאחור בעת פריסה כושלת גדל מדקות לשעות.
אוטומציה של פריסה הופכת לחובה כאשר שחרורים יוצאים לעיתים קרובות יותר מפעם בשבוע, יש יותר משתי סביבות, או שביקורת דורשת מחבר מאומת לכל שינוי. אז נדרשת הגדרת Bamboo בשילוב עם שאר האקוסיסטם של Atlassian: בנייה, בדיקות ופריסה מתוארות באופן הצהרתי ומבוצעות באותו אופן בכל סביבה. נסביר כיצד זה נסגר.
מה נותן צינור הבנייה: שחזוריות, מהירות, פחות כשלים
צינור בנייה אחיד מסיר את הסיבה העיקרית לאי-התאמות — סביבות שונות אצל המפתח, על סוכן הבנייה ועל השרת. תלויות מקובעות בקובץ מניפסט, השלבים מתוארים בקוד, הסוכנים עולים בסביבה מבודדת ונהרסים לאחר ההרצה.
אותו קומיט מפיק אותו ארטיפקט ללא תלות במי ומתי הפעיל את הבנייה — „אצלי זה עובד מקומית” מפסיק להיות טיעון.
זמן הבנייה והשחרור מתקצר לא באמצעות אופטימיזציה לשם אופטימיזציה, אלא באמצעות מבנה: מטמון תלויות בין הרצות, שלבי בדיקה במקביל, הפרדה בין בדיקות מהירות לבין הרצות רגרסיה ארוכות לפי לוח זמנים.
הארטיפקט נבנה פעם אחת ומתקדם בין סביבות בלי בנייה מחדש, ולכן הדרך מקומיט לשחרור מוכן נמדדת בעשרות דקות במקום בשעות. צוואר הבקבוק נראה על ציר הזמן של השלבים, ולא מתברר בוועידה בדיעבד.
שיעור החזרות לאחור של שחרור יורד בגלל שסוג שלם של שגיאות נעלם — מיגרציות שנשכחו, אי-התאמות בקונפיגורציות, שלבים שנעשו ידנית ו„בדרך כלל עבדו”.
השבתה בגלל כשל בנייה מפסיקה להיות הפתעה: הצינור נופל בקומיט עם סיבה מובנת, ולא בסביבת העבודה בלילה, והחזרה לארטיפקט הקודם נשארת זמינה בצעד אחד.
Bamboo בשילוב עם מערכת מעקב משימות ומאגר קוד נותן זאת בלי סקריפטים תוצרת בית מפוזרים: חוקי בנייה, הרשאות והיסטוריית הרצות חיים במקום אחד. בהמשך נסביר כיצד מועבר תהליך הבנייה הנוכחי ומה נשאר מהעטיפות הסקריפטיות שנצברו.
אפשרויות הרצת בניות: סוכנים ייעודיים, ענן, קונטיינרים
אופן הפעולה של הסוכנים קובע היכן מתבצעת הבנייה ועד כמה התוצאה ניתנת לשחזור. ב-Bamboo זה מתואר באמצעות דרישות המשימה והיכולות של הצומת: המתזמן מעביר את הבנייה רק לסוכן שהמאפיינים שלו תואמים. מכאן ארבע סכמות שבהן באמת בוחרים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכני בנייה ייעודיים על תשתית משלכם | זרימת בניות יציבה, גישה לרשת פנימית ולמאגרים סגורים | זמן השבתה בין משימות, עדכונים והרחבה ידנית, הצומת הופך לנקודת כשל |
| סוכנים לפי דרישה בענן | עומס לא אחיד, ענפים במקביל, בדיקות כבדות נדירות | אתחול ארוך של הצומת, מטמון התלויות מתחמם מחדש בכל בנייה |
| סביבות בנייה מבודדות בקונטיינרים | התוצאה צריכה להיות זהה במכונת המפתח ועל הסוכן | תמונה לכל טכנולוגיה, מטמונים מועברים בנפרד, חלק מהפעולות דורשות הרשאות מורחבות |
| מצב שחרור היברידי | הבדיקות מתבצעות במקביל, והשחרור — לאחר אישור ידני מצומת מהימן | השחרור ארוך יותר, הרשאות וסודות מסונכרנים בין המצבים |
בפועל מערבבים בין הסכמות: הבנייה מתבצעת בסביבה מבודדת, הבדיקות מפוזרות במקביל על סוכנים לפי דרישה, והשחרור מבוצע על צומת ייעודי. כך סוגרים בבת אחת גם שיאי עומס וגם דרישות בקרת גישה.
שלבי הגדרת Bamboo: מביקורת מאגרי קוד ועד מסירה
סדר העבודה ב-Bamboo זהה לכל מאגר קוד — משתנה ההיקף, לא הרצף. מתחילים מביקורת: בלעדיה האוטומציה רק מעבירה אל תוך הצינור את אותן הנחות סמויות שחיות בבניות ידניות על מכונות המפתחים.
- ביקורת מאגרי קוד ותסריטי בנייה נוכחיים. בודקים מה נבנה ידנית ולמה, היכן נמצאות תלויות וסודות, אילו ענפים באמת פעילים, כמה זמן הבנייה אורכת כיום.
- תכנון סכמת צינור בנייה. מפרקים את התהליך לשלבים: קומפילציה, בדיקות, ניתוח סטטי, פרסום ארטיפקט, פריסה לסביבות. קובעים מה רץ על כל קומיט ומה רק לפי תג גרסה.
- הגדרת סוכנים ותוכניות בנייה. פורסים סוכנים לפלטפורמות הנדרשות ומגבילים מקביליות כדי שבנייה כבדה לא תדחוק משימות אחרות. שלבים משותפים מוציאים לתבניות — שירות חדש מחובר באמצעות עריכת משתנים, לא בהעתקת סקריפטים.
- בדיקה על ענף שחרור פיילוט. מריצים את כל הצינור על שירות אחד: מודדים זמן בנייה, שיעור הרצות מוצלחות, התנהגות בנפילת בדיקות. בנפרד בודקים חזרה לארטיפקט הקודם.
- הדרכת הצוות. מראים למפתחים היכן לראות לוגים, כיצד להוסיף שלב לתוכנית וכיצד להפעיל מחדש רק את החלק שנפל במקום את כל הבנייה.
- מסירת תיעוד. סכמת הצינור, תיאור משתנים והרשאות, הוראות לעריכת תוכניות, סדר פעולות בעת כשל בנייה.
חבילת מסירה: קונפיגורציות תוכניות, סכמות סביבות, נהלים
לאחר הגדרת Bamboo נשאר לצוות לא אוסף הגדרות בצ'אט ולא מהנדס אחד ש„יודע היכן ללחוץ”, אלא ערכה מתוקננת בגרסאות של ארטיפקטים. קונפיגורציית התוכניות נשמרת לצד הקוד, ולכן שינוי עובר בדיקה כמו קומיט רגיל, והסביבה משוחזרת מתוך תיאור, לא נבנית מחדש ביד.
- קונפיגורציית תוכניות בנייה — תיאור התוכניות והקשרים ביניהן בקבצי מאגר הקוד: שלבים, תנאי הפעלה, תלויות. ערכים שנבדלים בין סביבות מוצאים למשתנים, וסודות — לאחסון חיצוני, ולא לטקסט הקונפיגורציה.
- מטריצת סוכנים ויכולותיהם — איזה סוג משימות עובר למבצעים משותפים, איזה לייעודיים, וכיצד מוצבות התגיות. זה מסיר תחרות בין בנייה לפריסה: השחרור לא ממתין עד שמתפנה סוכן לבדיקות כבדות.
- סכמת סביבות וזרימות שחרור — השרשרת מסביבת הפיתוח ועד סביבת הייצור, טריגרים למעבר ונקודות אישור ידניות. הארטיפקט הבנוי מתקדם בין סביבות בלי בנייה מחדש, ולכן לייצור מגיע בדיוק מה שעבר בדיקות.
- חוקי הפרדת הרשאות — תפקידים: למי מותרת הרצה, למי עריכת קונפיגורציית תוכנית, מי מאשר פריסה לייצור. הם מתואמים עם ההרשאות במאגרי הקוד ובמערכת המשימות, כדי שלא יישאר מסלול עוקף תהליך.
- נוהל חזרה לאחור של שחרור — איזה ארטיפקט נלקח לחזרה, מי מקבל החלטה, תוך כמה דקות הסביבה חוזרת למצב עבודה. חזרה משינויים בסכמת הנתונים מתוארת בתרחיש נפרד, משום שהיא לא מסתכמת בחזרה לבנייה הקודמת.
- הוראות למהנדס תורן — כשלים אופייניים: סוכן לא זמין, בדיקות נפלו, פריסה נתקעה בהמתנה. לכל אחד — סדר פעולות, דרך אבחון ונקודת הסלמה.
- נוהל תחזוקה — תוחלת החיים של ארטיפקטים והיסטוריית בניות, עדכון תקופתי של סביבות בסיס לסוכנים ובחינה מחדש של תוכניות כשהרכב השירותים משתנה.
מקרה בוחן: מעבר משחרורים ידניים לצינור — מדדים לפני ואחרי
איך זה היה לפני
לפני הפרויקט השחרור נבנה ביד: מהנדס הקים סביבה, הריץ בנייה מקומית, העתיק ארטיפקטים לסביבת הבדיקה והפעיל מיגרציות בפקודה נפרדת. סדר השלבים חי בראש של אדם אחד — בזמן חופשה השחרור פשוט לא יצא. השחרור ארך 3–4 שעות בחלון לילה, וסיבת הכשל התבררה רק אחרי שמשתמשים ראו את השגיאה.
מה שינו ומה קיבלנו
הרכיבו צינור ב-Atlassian Bamboo: בנייה, בדיקות, פרסום ארטיפקטים עם מספר מגורסא, פריסה לפי סביבות — כרצף אחד של משימות קשורות. ענף הפיתוח נבדק בכל שינוי, ולייצור עוברת רק בנייה שעברה את כל הבדיקות.
את החזרה לאחור עשו כשלב זהה בצינור: חזרה לארטיפקט הקודם וחזרה של סכמת בסיס הנתונים בפקודה אחת, בלי עריכות ידניות בשרתים. אם הבדיקות לאחר הפריסה לא עוברות, הצינור עוצר את השחרור בעצמו ומחזיר את המצב הקודם.
זמן הבנייה של גרסת שחרור הצטמצם מ-3–4 שעות ל-20–25 דקות. מספר החזרות לאחור ירד מארבע לעשרה שחרורים לאחת לעשרים — רוב הפגמים נתפסים בבדיקות, לפני הגעה לייצור. זמן ההתאוששות לאחר כשל ירד משעתיים-שלוש ל-10–15 דקות: החזרה לאחור הפסיקה להיות פעולה חירום תחת לחץ.
אפקט נפרד הוא יכולת חיזוי: השחרור כבר לא תלוי באדם אחד ובחלון לילה, ויומן הבנייה שומר מי ומה שינה. שלבים חדשים — בדיקות אבטחה, התראות — נוספו בלי לשכתב את התהליך.
מה לעשות אם חלק מהבניות כבר מוגדר בכלי אחר?
חלק מהפרויקטים כבר נבנים בכלי אחר — זה מצב עבודה רגיל, לא בעיה. לשכתב הכול בבת אחת זה מסוכן: השחרורים ממשיכים כרגיל, ועצירת קו הבנייה פוגעת מיד בלוחות הזמנים. לכן אנחנו לא מעבירים הכול בבת אחת, אלא קודם בונים דו-קיום של שני מסלולים.
מתחילים במיפוי: אילו משימות וטריגרים יש לכל פרויקט, מאיפה מגיעים הארטיפקטים, מי ואיך מקבל התראות על בנייה. מהתמונה הזו רואים אילו תרחישים מועברים אחד לאחד, ואילו דורשים עיבוד מחדש — לרוב הפערים הם במשתני סביבה ובשלבי פרסום ארטיפקטים.
בזמן שפרויקט אחד חי בכלי הישן, השני כבר נבנה ב-Bamboo: שניהם כותבים ארטיפקטים לאותו מאגר ומפעילים לפי אירועים במערכת בקרת הגרסאות. את מה שעובד לא שוברים — התרחיש הקודם נשאר, החדש מוצב לצידו ונבדק על אותם ענפים ואותן ערכות בדיקה.
נקודת שחרור אחידה נבנית בהדרגה: גרסאות, יומני בנייה, הרשאות והתראות רואים במקום אחד, גם אם הביצוע מתבצע בשתי מערכות. הלקוח רואה רשימת שחרורים אחת וסטטוס אחד לכל שירות במקום שתי תמונות לא מתואמות. זה גם מסיר את השאלה מי ומתי ביצע שינוי בתסריט הבנייה.
הגירה מדורגת של הצינור מתבצעת לפי סיכון: קודם שירותים לא קריטיים ובניות לילה, אחר כך ענפי שחרור, ולבסוף מה שקשור לסביבת הייצור. כל שלב הפיך: התרחיש הקודם נשאר פעיל עד שהחדש יעבוד כמה שחרורים ברצף. הגדרת Bamboo במצב כזה לא דורשת עצירת שחרורים נוכחיים.
שאלות טכניות נפוצות: סוכנים, הרשאות, העברת בניות
בידוד בניות מתחיל בסוכנים: לכל בריכת סוכנים יש סט יכולות משלו — כלים מותקנים, גישה למאגרים פנימיים, משתני סביבה. תוכנית נקשרת לבריכה הנכונה באמצעות דרישות, ולכן בנייה זרה לא תתפוס סוכן שהתפנה ולא תראה משתנים של צוות שכן.
סודות חיים בנפרד מהתוכנית — בפרטי חשבון משותפים של הפרויקט, בפרמטרים של סביבות פריסה ובאחסון חיצוני. הערכים מוזרקים ברגע ההרצה ומוסתרים בלוגים, והגישה אליהם ניתנת לפי תפקידים.
האם בניות של צוותים שונים על סוכנים משותפים לא מפריעות זו לזו?
מפרידים סוכנים לפי בריכות ודרישות: צוות הפלטפורמה וצוות המוצר עובדים על סטים משלהם של יכולות, ומשימות במקביל לא דוחקות זו את זו. בריכה משותפת נשארת למשימות ניטרליות — ניתוח סטטי ובדיקות סגנון, עם הגבלה על מספר ההרצות בו-זמנית.
כיצד ניתנות הרשאות לסביבות?
הרשאות לפריסה קשורות לסביבה ולתפקיד: מפתח בונה ארטיפקט, אבל את הפריסה לייצור מבצע מעגל מאושר. החלפת פרטי חשבון לא דורשת עריכת תוכניות — משתנה הערך באחסון.
מה לעשות עם תוכניות בנייה קיימות?
מעבירים בשני מסלולים: ייצוא-ייבוא של קונפיגורציה למעבר נקודתי או תיאור התוכנית כקוד — אז ההגדרות נמצאות במאגר הקוד, עוברות סקירה ומשוחזרות במסלול חדש. לפני ההעברה משווים קישורים למאגרי קוד, טריגרים ומשתנים.
מי מתחזק את הצינור לאחר המסירה?
נשארים בתחזוקה: מעדכנים סוכנים ותוספים, עוקבים אחר תור המשימות וזמן הבנייה, מנתחים כשלים. מדדים — משך הבנייה, שיעור הרצות מוצלחות, זמן עד התאוששות לאחר כשל.
נדון במשימה: נסתכל על הבניות שלכם ונחזור עם תוכנית
כדי שההערכה תישען על עובדות ולא על הנחות, מתחילים בניתוח התהליך הנוכחי. בודקים כיצד בנויות תוכניות הבנייה ב-Bamboo, כמה סוכנים מעורבים, כיצד מאגרי הקוד מקושרים למערכת מעקב המשימות ובאיזה שלב הקוד מגיע לסביבת היעד.
בנפרד מתעדים צווארי בקבוק: היכן הבנייה אורכת יותר ממה שיכלה, אילו שלבים מבוצעים ידנית ואילו שחרורים תלויים במהנדס מסוים.
בניתוח מבהירים את מה שאי אפשר לראות מתוך הקונפיגורציות:
- אילו ענפים וכיצד נכנסים לבנייה, היכן כעת נשבר הצינור ולמה;
- כמה שלבי אוטומציה חסרים — מבדיקות ועד פריסה;
- אילו סביבות קיימות ובמה הן נבדלות, היכן נדרשים אישורים ידניים;
- כיצד בנויים הרשאות, תפקידים ואחסון סודות, מי ומה יכול לשנות;
- כיצד נוצרים ארטיפקטים, ממוספרות גרסאות ומבוצעת חזרה לאחור;
- אילו מגבלות מציבה התשתית — רשת, סוכנים, מגבלות של מערכות חיצוניות;
- מה כבר מוגדר ומשמש מחדש, ומה יהיה צריך לבנות מאפס.
לפי תוצאות הניתוח נחזור עם תוכנית להטמעת הצינור: שלבים, סדר עבודה, תחומי אחריות והערכת מאמץ לאוטומציה. את התוכנית נתאם לפני ההתחלה — תראו מראש מה ישתנה בכל שלב וכיצד זה ישפיע על השחרורים הנוכחיים. תארו את המשימה ואשלחו הרשאות לקונפיגורציות — נחזור עם הערכה וסכמת עבודה.