פריסה לפי תג: היכן נקרע מסלול השחרורים
כתבת בשדה «ענף» את המילה main ולחצת «הפעל» — זו דרך אופיינית להוציא שחרור. אבל ענף הוא לא גרסה, אלא מצביע נע: בזמן שהבנייה מתבצעת, כבר מוזג לתוכו סט השינויים הבא, ובסביבת הבדיקות מופיע לא מה שהיה בקוד ברגע ההתחלה.
יכולת השחזור של הבנייה נשברת גם מבפנים: התלויות נמשכות מהרשת בלי נעילה, והרצה חוזרת מאותו קומיט מניבה תוצאה אחרת.
את הפער מבחינים לא מיד. ארטיפקט השחרור נבנה מחדש לכל סביבה, עם סט משתנים משלו, ובפרודקשן מופיעה בנייה שאינה נמצאת לא במאגר ולא בידי איש. אין במה לברר מה בדיוק נשלח: אין תג, ההאש של הקומיט לא נרשם בשום מקום, ויומן השחרורים סגור.
החזרה לאחור הופכת לבנייה מחדש של מצב קודם מהזיכרון, ובזמן שמכינים אותה, המסלול נשען על תיקונים ידניים בפרודקשן — הם לא עוברים בדיקות ונעלמים בשחרור הבא.
פריסה לפי תג מסלקת את הפיצול הזה. תג הוא תווית בלתי ניתנת לשינוי על קומיט מסוים, והארטיפקט נבנה פעם אחת בדיוק, נקשר לתג ומשמש מחדש בכל הסביבות: אותו תוכן בדיוק עובר את סביבת הבדיקות ועולה לפרודקשן. נבחן כיצד לארגן מסלול כזה והיכן הוא עדיין נקרע.
מה משתנה לאחר המעבר לתגי שחרור
כל עוד הפריסה בוצעה מראש הענף, הסימן ל«מה נפרס» היה הקומיט האחרון: לפרודקשן мог לעלות תמונת מצב שאף אחד לא בדק במלואו. תג שחרור מסיר את אי-הוודאות הזו — ההרצה יוצאת ממצביע בלתי ניתן לשינוי ב-Git, שלו מוצמדת תמונת מצב מסוימת של קוד והגדרות.
ההבדל מתגלה לא ביום הראשון, אלא במטריקות. הנה מה שאנחנו בודקים כבר בשבוע הראשון לאחר המעבר, כדי להבדיל בין אפקט אמיתי לבין סדר פורמלי:
- שיעור השחרורים המוצלחים — האם לכל אירוע אפשר לציין את תמונת המצב המדויקת שממנה נבנה הפרוד, והאם היא תואמת למה שעבר בדיקות.
- זמן החזרה לאחור — האם קיים תג של השחרור היציב הקודם, שאליו חוזרים בפעולה אחת: דקות לעומת עשרות דקות בבנייה מהענף.
- מספר האירועים בגלל אי-התאמה בין הקוד לבנייה — האם נעלמו המקרים שבהם נכנס לארטיפקט קוד שלא היה בתמונת המצב שנבדקה.
- היסטוריית השחרורים — האם ניתן לקרוא אותה לפי התגים: מה נכלל, מתי, מי אישר.
- בקרת גרסאות — האם התגים מוגנים מפני דריסה והאם יש כלל מי מציב אותם ואיך.
אם הסעיפים סגורים, השחרור משוחזר לפי התג, החזרה לאחור הופכת למעבר לתג הקודם, וניתוח האירוע מתחיל מתמונת מצב מסוימת, ולא מחיפוש «מה בעצם היה שם».
השוואה: פריסה לפי תג, לפי ענף או ידנית
בחירת מודל השחרור קובעת מה בדיוק מגיע לפרוד וכמה התוצאה ניתנת לחזרה. להלן ארבעה וריאנטים הנפוצים ביותר, עם גבולות היישום שלהם והמחיר שהם גוררים.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| פריסה לפי תג | מסלול מוצרי: התג מצביע על מצב קוד מסוים, פריסה חוזרת של אותו תג מניבה את אותו ארטיפקט | נדרשת משמעת שמות — תג מיותר יוצר שחרור. מתאים פחות לשינויים תכופים וקטנים |
| פריסה לפי ענף | סביבות פיתוח ובדיקות, שבהן נדרשת הרצה אוטומטית לאחר כל מיזוג | לפרוד עולה «מה שהצטבר»: אין גבול שחרור ברור, חזרה לאחור אפשרית רק למצב הקודם של הענף |
| הפעלה ידנית של שחרור | שחרורים נדירים ומוסדרים, שחרור בחלון מוסכם | תלוי באדם: פספסו הפעלה — בפרוד בנייה מיושנת, היסטוריית הפריסות מפוזרת |
| שחרור מותנה | השחרור מופעל לפי אירוע: תג, שינוי בתיקייה נפרדת, סגירת משימה | הכללים מתרבים ומתנגשים זה בזה, קשה יותר להסביר אותם לצוות ולבדוק לפני פריסה |
בפועל הגישות לא מתחרות, אלא מחלקות ביניהן מסלולים: תג כשער היחיד לפרוד, ענף — כתגובה מהירה בסביבות בדיקה, הפעלה ידנית — לחריגים כמו תיקון שלא תוכנן. שחרור מותנה הגיוני במקום שבו הכלל פשוט וניתן לבדיקה — למשל, שחרור רק כשמשתנה התיקייה של השירות. בהמשך נראה כיצד לאחד זאת לצינור אחד בלי לשכפל לוגיקה.
צינור שחרורים ב-CI/CD: שלבי העבודה ההנדסית
שלבי היישום זהים, יהיה אשר יהיה כלי הבנייה אצל הלקוח: תחילה ביקורת וכללים, אחר כך אוטומציה. המטרה — שהשחרור יופעל על ידי תג, ולא על ידי חבילה שנבנתה ידנית: אז הגרסה בפרודקשן ניתנת לשחזור באופן חד-משמעי לפי מזהה, והוויכוח «מה בעצם פרוס שם עכשיו» נעלם.
- ביקורת הצינור. מיפוי ענפים, תגים ושלבים ידניים: היכן נבנה הארטיפקט, איך הוא מגיע לסביבות, אילו פעולות נעשות ביד. התוצר — מפת אי-התאמות בין הבנייה לשחרור.
- סכמת ניהול גרסאות. קובעים את פורמט התג (major.minor.patch וקידומת נפרדת לגרסאות טרום-שחרור) ואת הכלל איזה תג מוביל למסלול הבדיקות ואיזה לפרודקשן.
- כללי שחרור. תגים מוגנים, הרשאות ליצירתם, בדיקות חובה לפני פרסום, אישור ידני לפרודקשן.
- הגדרת בנייה מתג. תג אחד — ארטיפקט אחד בלתי ניתן לשינוי, שאינו נבנה מחדש במעבר בין סביבות.
- הגדרת שחרורים לפריסה. קישור התג לסביבה, מיגרציות מסד נתונים, בדיקת חיות לאחר הפריסה וחזרה אוטומטית לתג הקודם במקרה של כשל.
- חזרה גנרלית. הרצה על שירות אחד: מודדים את הזמן מהצבת התג ועד סביבת העבודה, ובנפרד — את זמן החזרה לגרסה הקודמת.
- העברת ניהול. תקנון שחרור, תיאור החזרות לאחור והרשאות גישה, הדרכת צוות התורנות של הלקוח.
מה נשאר אצל הלקוח: קונפיגורציות ותקנונים
העברת פרויקט היא לא ארכיון עם קוד מקור, אלא מערכת עובדת שצוות המקבל יכול להפעיל, לשנות ולהחזיר לאחור בלי מעורבות המחבר. לכן לקראת סיום העבודה נאסף סט שבו לכל ארטיפקט יש בעלים ותרחיש שימוש ברור, ולא רק עצם קיומו של קובץ.
- קבצי הצינור — תיאורי הבנייה והשחרור נמצאים במאגר לצד הקוד, ולא בהגדרות ממשק האינטרנט: השינויים עוברים סקירה ומקבלים גרסאות יחד עם האפליקציה.
- סכמת הצינור — מהבנייה והבדיקות ועד פרסום הארטיפקט והפריסה, עם נקודות אישור ידני מסומנות בבירור ומקומות שבהם השחרור נעצר אוטומטית.
- מטריצת סביבות — אילו ענפים ותגים נכנסים למסלול הבדיקות ולמסלול הייצור, במה נבדלים הפרמטרים שלהם, כיצד מופרדים נתונים וסודות.
- מדיניות גישה — תפקידים להפעלת שחרור ולאישור פריסה למסלול הייצור; עבור האוטומציה משתמשים בחשבונות שירות נפרדים במקום בחשבונות אישיים.
- תקנון שחרור — כיצד נוצר התג, מי רשאי להציב אותו ומה נחשב עילה לשחרור, כולל הרכב בדיקות החובה.
- הוראות חזרה לאחור — חזרה מדורגת לשחרור הקודם: אילו פקודות, באיזה סדר, תוך כמה זמן המסלול חוזר למצב עבודה, ולפי אילו סימנים מפעילים את החזרה לאחור.
- תיעוד הצינור — היכן נשמרים סודות וכיצד הם מתעדכנים, כיצד מחברים תלויות, אילו בדיקות חוסמות ואילו רק מזהירות.
הסט נחשב כמקובל לא לפי חתימה, אלא בפועל: מהנדס הלקוח מציב בעצמו תג, מוביל את השחרור עד מסלול הייצור ומבצע חזרה לאחור לצורכי תרגול. הערות שנמצאו בשלב זה נסגרות לפני ההעברה — יחד עם הסכמות והתקנון הן נשארות בתוך הפרויקט ואינן דורשות פניות אלינו להסברים.
מקרה בוחן: שחרורים לפי תגים במקום בנייה מהענף
צוות המוצר של הלקוח תחזק כמה שירותים ובנה שחרורים ישירות מהענף הראשי. לשחרור לא הייתה נקודה בלתי ניתנת לשינוי: לא ניתן היה לתאר את מצב הסביבה במזהה אחד, ולכן «להחזיר כמו שהיה» פירושו היה לבנות מחדש — ובנייה חדשה מאותו ענף עלולה הייתה שלא להתאים למה שעבד בפועל.
לפני מקרה היישום מדדו שלושה גדלים ברבעון: השחרור ארך בין 35 ל-50 דקות של פעולות ידניות, כל שחרור רביעי הסתיים בחזרה לאחור, ובכעשרים אחוז מהמקרים הארטיפקט בסביבה לא תאם לקוד הענף — הספיקו להיכנס אליו קומיטים חדשים.
מה שינו
המעבר לתגים הפך את התג למקור היחיד לשחרור. צינור הבנייה בונה ארטיפקט רק מקומיט מתויג ב-Git ומניח אותו במאגר בלתי ניתן לשינוי, ופריסה לסביבת הייצור מהענף אסורה על פי כללים. חזרה לאחור היא לא בנייה מחדש, אלא מעבר לתג הקודם, באותה פקודה כמו השחרור. מרשם התגים הפך ליומן שחרורים: לפי מזהה אחד רואים מה ומתי עלה.
תוצאות הפרויקט
| מטריקה | לפני | אחרי |
|---|---|---|
| זמן שחרור | 35–50 דקות | 6–8 דקות |
| כשלי שחרור | כל שחרור רביעי | אחד מעשרים |
| אי-התאמות בין בנייה לקוד | כ-20% מהשחרורים | אינן משוחזרות |
| חזרה לשחרור קודם | כשעה | כמה דקות |
כעבור חצי שנה הצוות התחיל לשחרר לעתים תכופות יותר, לא פחות: השחרור הפסיק להיות אירוע עם סיכון, ומטריקות השחרור נקראות כעת מהיסטוריית התגים, ולא נאספות ידנית מהלוגים.
מה לעשות אם השחרור כבר נבנה מהענף?
כן, מעבר לתגים אינו מחייב לשכתב את הצינור. תג וענף הם שניהם מצביעים לקומיט, ולכן שלבי הבנייה, הבדיקות ופרסום הארטיפקט נשארים כשהיו. שני דברים משתנים: תנאי ההפעלה ומקור מספר הגרסה.
העבודה העיקרית היא להוציא את הגרסה מהתבנית אל הפרמטר. כיום המספר מחושב בדרך כלל משם הענף או מוזן ידנית, וזה בדיוק מה שמפריע להפעלה לפי תג. ברגע שהגרסה מגיעה מבחוץ, מהתג עצמו, הצינור נעשה אדיש למקור ההפעלה, והמעבר מצטמצם להגדרת טריגר.
כדאי ליישם זאת בהדרגה, בלי לקרוע סכמה עובדת. תחילה הפעלה לפי תג מתווספת במקביל: בנייה מהענף ממשיכה להוציא גרסאות ביניים, והתג מפעיל מעבר שחרור באותם שלבים.
את השחרורים הראשונים מריצים בשני הכיוונים ומשווים ארטיפקטים — ההרכב וסכום הביקורת צריכים להיות זהים, אחרת באחד השלבים מוטמעת תלות בענף.
ההיסטוריה לא נשברת. ניתן להציב תגים על קומיטים שכבר שוחררו בדיעבד — שחרורים ישנים יקבלו את אותם סימונים כמו החדשים, והקשר «תג — ארטיפקט — סביבה» יהפוך לרציף.
לאחר מכן שחרורים יציבים יוצאים רק לפי תג, והענף נשאר כלי פיתוח; ניתן לחזור לסכמה הקודמת בכל שלב, כל עוד ההפעלה המקבילה לא כובתה.
השלב האחרון — כלל האוסר פרסום לפרוד בלי תג, ואיסור בנייה מחדש של תג קיים: תג אחד נותן ארטיפקט אחד בלתי ניתן לשינוי. נמצאה שגיאה בשחרור — מוציאים תג חדש, ולא דורסים את הישן. זה בדיוק מה שהופך את החזרה לאחור לצפויה: הסביבה חוזרת לארטיפקט קבוע ומסוים.
שאלות נפוצות על תגי שחרור וחזרות לאחור
ספקות לגבי תגי שחרור מצטמצמים בדרך כלל לארבעה נושאים: מי רשאי לשחרר, כיצד לחזור לאחור, מה עם גרסאות מקבילות והאם יש צורך לשבור סכמה עובדת. להלן כיצד זה מסודר בצינור.
מי רשאי להציב תג שחרור?
הזכות לשחרר נתונה למעגל מוגבל של תפקידים: את התג מציב אחראי, ופריסה ישירה מהענף העובד חסומה בהגדרות הצינור. אי אפשר לעקוף את הכלל — הבדיקות מתבצעות ללא תלות במי שמשחרר.
כיצד לחזור לאחור אם השחרור התברר כרע?
הארטיפקט נבנה פעם אחת ונשמר בלתי ניתן לשינוי יחד עם התג, ולכן חזרה לאחור של שחרור היא פריסה של התג הקודם, ולא בנייה מחדש. החזרה לגרסה עובדת אורכת דקות ואינה תלויה במה שהספיקו לשנות בענף.
האם אפשר לנהל כמה גרסאות במקביל?
כן: לכל קו תמיכה יש ענף משלו ותגים משלו, ולכן תיקון בגרסה ישנה לא גורר אחריו שינויים מהחדשה. גרסאות מקבילות חיות בסביבות שונות ואינן מפריעות זו לזו.
מה יקרה לסכמת השחרור שכבר עובדת?
שדרוג הצינור מתבצע בשלבים: השיטה הישנה נשארת עובדת עד שהחדשה נבדקת בשחרור אמיתי. המעבר מתבצע שירות-שירות, עם אפשרות לחזור אחורה.
כמה זמן נשמרים ארטיפקטי שחרור?
מדיניות האחסון נקבעת במפורש: שחרורים לפי כל תג נשארים זמינים לחזרה לאחור, והשאר מוסרים לפי לוח זמנים. המאגר לא גדל ללא גבול.
נדון בסכמת השחרורים שלכם ונחזור עם תוכנית
כדי שסכמת הפריסה לפי תג תעבוד בתשתית שלכם, ולא תישאר סט כללים במאגר נפרד, יש צורך בתוכנית המותאמת לתהליך השחרור הנוכחי שלכם: כיצד מוקצות גרסאות כעת, מי ובאיזה רגע מציב תג שחרור, כמה סביבות עובר הארטיפקט ומה נחשב חזרה לאחור.
תארו זאת בצורה חופשית — מספיקים מבנה הענפים, שיטת הבנייה והמקומות שבהם יש כיום שלבים ידניים. המהנדסים שלנו יבחנו את הסכמה ויחזרו עם הערכת עבודה ותוכנית יישום: מה עושים בתחילת הפרויקט, מה אחר כך, ומה אפשר להשאיר כפי שהוא.
- תוכנית יישום בשלבים: סימון תגי שחרור וכללים להופעתם, בניית ארטיפקט ממצב קבוע, קידום בין סביבות
- סכמת חזרה לאחור: חזרה לתג הקודם בלי בנייה מחדש, תוך שמירה על קונפיגורציית הסביבה והנתונים
- מדיניות גישה וחתימה: מי רשאי להוציא תג, במה מאומתת אותנטיות הארטיפקט
- הפרדה בין בנייה לפריסה: מה עובר שימוש חוזר בין סביבות, והיכן נשארים הבדלים בהגדרות
- סט בדיקות לפני פריסה: אילו שערים אוטומטיים מניחים לשחרור לעבור, ואילו דורשים אישור
- תיעוד והעברה: תיאור סכמת השחרור, הוראות לתורנות, ניתוח תקלות אופייניות
תארו את המשימה — נחזור עם הערכת עבודה ותוכנית שבה מפורטים שלבים, תחומי אחריות וסדר ההפעלה.