משתנים דינמיים ב-CI/CD: איך הצינור מחשב בעצמו את הסביבה

הארדקוד של סביבות שובר את הפייפליין: משתנים דינמיים ב-CI/CD

מחרוזת החיבור למסד הנתונים, כתובת ה-registry של ה-images ומצב הלוגים כתובים ישירות בתיאור קו הבנייה. הבנייה ירוקה, ה-artifact מפורסם, אבל אחרי מעבר לסביבת pre-prod האפליקציה עולה מול מסד נתונים לבדיקות וכותבת לוגים לאינדקס משותף. השגיאה אינה משוחזרת בענף הפיתוח — שם הערכים תואמים במקרה, כי מישהו העתיק אותם ידנית פעם.

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

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

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

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

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

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

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

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

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

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

דרכים לחישוב משתנים: קובץ, תבנית, רגע ההרצה

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

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

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

איך אנחנו מטמיעים: מביקורת תצורה ועד העברה

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

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

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

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

4. הגדרת החישוב. מתארים כללי הזרקה ומשתנים מחושבים, מוציאים כתובות ופרטי התחברות מקובצי ה-pipeline ומשאירים הפניות למאגרים.

5. בדיקה על עותק של הסביבה. פורסים עותק, מריצים בנייה, release ו-rollback, ומשווים את הערכים הסופיים לערכים הצפויים — אי-ההתאמה נראית לפני היציאה לסביבות העבודה.

6. העברת נהלים. מוסרים תיעוד על משתנים, הוראה „איך להוסיף משתנה חדש”, מינוי בעלים וסדר שינוי עדיפויות.

מה נשאר ב-repository: סכימות, תפקידים, נהלים

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

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

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

מקרה בוחן: monorepo עם 40 שירותים בלי משתנים ידניים

Monorepo עם 40 שירותים ושלושה סטנדים — dev, stage, prod. ערכי הסביבה (כתובת ה-registry, שם ה-cluster, תג ה-image, קידומת הדומיין) חיו בהגדרות ידניות של הפרויקט ב-GitLab CI — עותק נפרד לכל שירות ולכל סטנד. כל מה שלא תאם התברר רק בזמן הפריסה.

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

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים והתשובות שלנו

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

האם משתנים דינמיים ישברו בניות מקבילות?

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

מה יישאר לצוות אחרי ההעברה?

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

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

כדי שההערכה תהיה עניינית ולא „לפי מספרים ממוצעים”, אנחנו צריכים תמונה של הסביבות שלכם ושל ה-pipeline הנוכחי לבנייה ולפריסה.

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

• כמה סביבות יש ומה מבדיל ביניהן: פיתוח, pre-prod, production, אתרים נפרדים ללקוחות או סניפים.
• איפה נמצאים כעת ערכי המשתנים: בהגדרות מערכת הבנייה, בקובצי ה-repository, במאגר הסודות — ואיזה חלק מוגדר ידנית לפני ההרצה.
• איך נקבעת הסביבה: לפי שם הענף, לפי תג ה-release, בבחירה בזמן ההרצה, לפי ספריית ה-manifests.
• אילו סודות והרשאות משויכים לכל סביבה ומי מהצוותים צריך לראות אותם ומי לא.
• כמה שלבים ידניים נשארו ב-pipeline ובאיזה שלב הפריסה נשברת לרוב.
• מגבלות הסביבה: סביבה סגורה בלי יציאה החוצה, אישורים משלכם, registry נפרד ל-images, נוהל לתקופות שמירת artifacts.
• אילו בדיקות צריכות לחסום פריסה: בדיקות, ניתוח סטטי, מדיניות אבטחה, אישור לפני production.

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