הגדרת צינור CI/CD באמצעות CircleCI

הגדרת CircleCI: היכן נשברים הבנייה והאספקה

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

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

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

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

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

מה נותן צינור בנייה ואספקה אוטומטי

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

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

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

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

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

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

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

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

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

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

סדר העבודה: ביקורת, תרשים, הפעלה, בדיקה, מסירה

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

1. מיפוי מלאי של מאגרים וסביבות: רשימת ענפים, סביבות (בדיקות, טרום-ייצור, ייצור), נקודות כניסה, סודות ומערכות חיצוניות שהמהדורה תלויה בהן.
2. תכנון תרשים הצינור: גרף משימות — בנייה, בדיקות, טסטים, ארטיפקטים, פריסה — וכללי הפעלה לפי ענפים, תגים ואישור ידני.
3. העברת שלבים: מתארים קונפיגורציה בתיקיית .circleci, מפעילים מטמון תלויות, מפצלים משימות ארוכות למקבילות, מתאימים משאבים לבניות כבדות.
4. בדיקה בסביבת ניסוי: מריצים מחזור מלא על עותק של סביבת הייצור, בנפרד בודקים חזרה למהדורה קודמת והתנהגות כאשר טסט נכשל.
5. אספקת ניסיון: מהדורה אמיתית אחת של שינוי קטן עם מדידת זמן מהתיקון ועד סביבת העבודה; צווארי בקבוק מתקנים מיד.
6. מסירת הצינור: גישות, הקשרים עם סודות, תרשים והוראות; מלמדים את התורנים לקרוא פלט משימות ולהפעיל מחדש שלבים שנפלו.

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

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

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

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

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

מקרה בוחן: זמן בנייה ושיעור אספקות מוצלחות

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

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

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

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

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

לאחר השינויים, קומיט אופייני עובר את הצינור ב-7–9 דקות — הזמן עד לתוצאת הבדיקות הראשונה הצטמצם פי שלושה. שיעור האספקות המוצלחות במעבר הראשון עלה מ-60 ל-88%, מספר ההפעלות הידניות מחדש ירד פי עשרה, והחזרות הפכו לנדירות.

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

במה מבצעים בענן נבדלים ממשלכם?

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

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

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

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

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

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

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

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

האם ניתן להגביל את הרשאות המבצע?

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

מה יקרה לכלי הבנייה הקודם?

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

כיצד מתבצעת חזרה של מהדורה ומה קורה בכשל צומת?

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

מה להכין לדיון במשימה

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

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

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