הגדרת TeamCity: היכן נשבר צינור הבנייה
הגדרת TeamCity מתחילה לא במסך הבנייה, אלא בשאלה: כמה זמן עובר מקומיט ועד סביבת עבודה פעילה. אם התשובה היא "שעה ויותר", צוואר הבקבוק נמצא כמעט תמיד בחיבורים — תור סוכנים, צעדים ידניים בין בנייה לפריסה, סביבות שהתפצלו.
בנייה איטית רק לעיתים רחוקות מוסברת בחומרה חלשה. לעתים קרובות סוכן אחד משרת כמה פרויקטים, המשימות נעמדות בתור, וזמן ההמתנה לבנייה עולה על זמן ההידור עם הבדיקות עצמו.
צעדים ידניים בשחרור — נקודת האובדן השנייה. כל עוד מעבירים ארטיפקט ידנית או ממתינים למי שיודע מה ללחוץ, אספקת השינויים נעשית בקפיצות: בסוף השבוע אף אחד לא מסתכן, ועד תחילת השבוע הבא מצטברת חבילת תיקונים שקשה יותר לבדוק.
חוסר יכולת לשחזר סביבה יוצר את סוג התקלות היקר ביותר: מקומית הכול ירוק, על הסוכן — לא. גרסאות שונות של כלים, מטמונים מחוממים ומשתני סביבה הופכים את הפתרון לניסוי וטעייה בין השערות.
בנפרד — בדיקות לא יציבות. בדיקה שנופלת כל פעם שנייה מרגילה את הצוות לא להסתכל על סטטוס אדום, ותקלה אמיתית נכנסת לענף הראשי יחד איתה.
לכן אנחנו מסתכלים על הצינור כמערכת: היכן הוא ממתין, היכן הוא תלוי באדם והיכן התוצאה אינה חוזרת על עצמה. בהמשך נבחן כיצד זה נסגר — מהגדרה המתוארת בקוד ב-Kotlin DSL ועד סוכנים בענן שמתכווננים לפי עומס.
הגדרת TeamCity: מה משתנה במהירות ובאמינות
הגדרת TeamCity מתחילה לא בהתקנת שרת, אלא במיפוי מה בפרויקט עדיין נעשה בידיים. לאחר מכן הבנייה מתוארת בקוד ב-Kotlin DSL, וצעדים כבדים עוברים לסוכנים בענן: הם מתרוממים לפי עומס ואינם בטלים בין שחרורים.
כיצד מתקצר זמן בדיקת השינויים
שמירה במטמון של תלויות וארטיפקטים בין הרצות והרצה במקביל של צעדים בלתי תלויים מקצרות את זמן הבנייה פי כמה — בדיקת שינויים בשירות טיפוסי יורדת מעשרות דקות לדקות בודדות.
המפתח מקבל תוצאה עבור הענף שלו בלי להמתין לתור המשותף על סוכן יחיד, ולכן תור הבניות מפסיק להיות צוואר בקבוק עם גדילת הצוות.
כיצד נעלם סוג התקלות מפעולות ידניות
צעד ידני שובר שחרור באותה צורה צפויה מראש: שכחו מיגרציה, בנו מענף שגוי, פרסו הגדרה לא נכונה. כל פעולה כזו הופכת לשלב בשרשרת הבנייה עם בדיקות לפני פריסה — שיעור הפעולות הידניות יורד, ויציבות השחרורים עולה בלי תורנויות לילה.
התוצאה מדידה: זמן הבנייה ומהירות בדיקת השינויים מתקצרים, השבתת הצוות בגלל בניות שבורות נעלמת, וחזרה לארטיפקט הקודם הופכת לפעולה שגרתית.
סוכני בנייה בענן ובבעלות עצמית: בחירת מצב עבודה
סוכן הוא מכונה שלמעשה מבצעת את שלבי הבנייה, וממצב העבודה שלו תלויים גם זמן ההמתנה בתור וגם התנהגות הצינור בשיאים. TeamCity מנהלת סוכנים בענן וסוכנים בבעלות עצמית באותה צורה, ולכן החלפת מצב היא עניין של הגדרה, לא של כתיבה מחדש של תרחישי בנייה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכנים בענן | זרימה יציבה, משימות כבדות נדירות, לא רוצים לרכוש חומרה | התנעה קרה פוגעת בבניות קצרות, הסביבה אפמרלית — המטמון מתחמם מחדש |
| צי בבעלות עצמית | נדרש מתחם סגור או מאגר מקומי, עומס יציב | בטלה בשעות שקטות, תמונות וטלאים בצד שלכם, הקיבולת מוגבלת במספר המכונות |
| תצורה היברידית | זרימה בסיסית אצלכם, שיאים עוברים לענן | נדרשים כללי ניתוב משימות לפי מאגרים וחשבונאות נפרדת |
מתי נדרש צי סוכנים בבעלות עצמית
מכונות משלכם מוצדקות אם הבנייה זקוקה לגישה למתחם סגור, למאגר מקומי או לסביבת בדיקה בלי כתובת חיצונית. סימן שני — זרימה יציבה: אם בשעות העבודה הסוכנים עסוקים כל הזמן, הצי נותן זמן תור צפוי מראש.
בד בבד נפתרת גם הבידוד של סביבות בנייה: מאגרים מוצמדים לצוות או לסוג משימות, ובנייה זרה לא גוזלת משאבים משלכם.
כיצד מחושבת עומסת שיא על הבניות
עומסת שיא מחשבים לפי יומן ההרצות: גרף של בניות במקביל בתקופה אופיינית, אחוזון עליון במקום ממוצע, ומרווח לגידול במספר הצוותים. לאחר מכן משווים למספר הסוכנים ולזמן ההחזקה — רואים כמה מכונות חסרות בחלון הגרוע ביותר וכמה בטלות בדרך כלל. בתצורה היברידית אותו חישוב קובע את הסף שמעליו משימות עוברות אוטומטית למאגר בענן.
שלבי העבודה: מביקורת בניות ועד מסירת נהלים
העבודה מתנהלת כך שהבניות יישארו פעילות בכל שלב: קודם מתעדים את המצב הנוכחי, אחר כך מעבירים תיאורי בנייה לקוד, ורק לאחר בדיקה על עותק של פרודקשן מעבירים את הצוות לצינור החדש ב-TeamCity. סדר השלבים אינו תלוי בגודל הפרויקט — משתנה ההיקף, לא הסדר.
- ביקורת בניות — מיפוי הגדרות, מדידת זמן של כל בנייה, חיפוש בדיקות כפולות ושלבים שתלויים במצב של סוכן מסוים.
- העברת תיאורי בנייה ל-Kotlin DSL — הגדרות הופכות לקוד: תיקון עובר בדיקה לפני מיזוג, וחזרה נעשית על ידי החזרת הגרסה הקודמת של הקובץ.
- תרשים סביבות — איזה ענפים נבנים למה, היכן נמצאים ארטיפקטים, אילו הרשאות יש לחשבונות ומאין מגיעים סודות.
- סוכנים בענן — מאגרים לפי סוגי משימות, הרחבה אוטומטית כנגד תור בשיא, בידוד סוכנים זה מזה.
- בדיקה על עותק של פרודקשן — נתיב מלא של בנייה ופריסה מריצים על עותק ומשווים לצינור הנוכחי.
- מסירת נהלים — כיצד להוסיף שלב, להחזיר גרסה ששוחררה ומה לעשות כשסוכן נופל.
תרשים סביבות והעברת תיאורי בנייה
התרשים עונה על השאלה מה היכן רץ ולאן מגיעה התוצאה: מאגרי קוד, מאגרי סוכנים, ארטיפקטים, הרשאות. כל עוד הוא לא מסוכם, העברת תיאורים לקוד הופכת לכתיבה מחדש של אותה לוגיקה לכל פרויקט.
בדיקה על עותק של פרודקשן
העותק משחזר את הגדרת שרתי העבודה, ולכן רואים עליו פערים במשתני סביבה ושירותים שאינם נגישים מהסוכן. את המעבר עושים רק לאחר שהצינור הישן והחדש נותנים תוצאה זהה.
מה נשאר אצלכם: הגדרות, תרשימים, נהלים
ההטמעה מסתיימת לא בדוח, אלא בסט ארטיפקטים עובדים במתחם שלכם. הגדרות TeamCity, תרשימי סביבות ונהלים נשארים אצלכם כקבצים ומסמכים קריאים, לא כארכיון סגור — אפשר לערוך אותם ולהעביר למהנדס חדש בלעדינו.
הכול נמצא במערכת בקרת הגרסאות שלכם לצד הקוד: שינויים עוברים סקירה ומוחזרים כמו קומיט רגיל.
- הגדרת בניות — תיאורים ב-Kotlin DSL במאגר שלכם: שלבים, טריגרים, תלויות בין בניות, פרמטרים של סביבות. תיקונים עוברים דרך ענף וסקירה, לא דרך ממשק ווב.
- תיעוד בניות — מה עושה כל שלב, אילו ארטיפקטים הוא מפיק, אילו בדיקות חובה לפני פריסה.
- תרשים סביבות — אילו סביבות קיימות, במה הן שונות, לאן מכוון כל ענף וכיצד ארטיפקט מתקדם עד מתחם הייצור.
- מדיניות גישה — תפקידים והרשאות: מי מריץ בנייה, מי מאשר פריסה, אילו סוכנים מורשים לאילו מאגרים. בנוסף סדר מתן ושלילת גישות.
- נוהל תחזוקה — כיצד להוסיף שלב, לעדכן סוכן, לנקות מטמון ולהחזיר שחרור, עם גבול אחריות ברור בין הצד שלכם לצד שלנו.
- מדריך לחיבור סוכני ענן — כיצד להעלות סוכן חדש, אילו תגיות ומגבלות יש לו, וכיצד לבדוק שהוא נכנס למאגר הנכון.
מסירה כזו מסלקת את הסיכון העיקרי — תלות באדם ש"יודע איך הכול בנוי כאן". ההגדרה מנוהלת בגרסאות, המדיניות מתועדת, והנוהל נבדק על שחרורים חיים, לא נכתב מהזיכרון.
מקרה בוחן: קיצרנו את זמן הבנייה והסרנו צעדים ידניים
הפרויקט — מונורפוזיטורי לארבעה צוותים: שירותים ב-Kotlin, ספרייה משותפת, בנייה למובייל. הצינור חי ב-TeamCity, אך הוגדר דרך ממשק ווב: שלבים תוקנו ביד, הגדרות שוכפלו בין פרויקטים, ואיש לא עשה סקירה לשינויים.
מה היה לפני
הבנייה ארכה 24–28 דקות: מחצית השלבים רצו последовательно, אף שלא היו תלויים זה בזה. את השחרור בנו ידנית — 11 פעולות מהצבת תג ועד תיקון משתני סביבה, כל אחת 3–4 דקות ובהסתמכות על הזיכרון של האחראי.
השגיאות היו צפויות מראש: תג שנשכח, פרופיל בנייה לא נכון, הגדרות שהתפצלו. כל בנייה שלישית בענף הראשי נפלה, והטיפול ארך יותר מ-20 דקות — בלוג התערבבו שלבים מכל הפרויקטים.
כיצד מדדו את התוצאה ומה נחשב תקלה
את המדדים לקחו מהיסטוריית הבניות ב-60 ימי עבודה לפני ואחרי: חציון משך בנייה מוצלחת, שיעור הנפילות בענף הראשי, מספר הפעולות הידניות בצ'קליסט השחרור, זמן מקומיט ועד פרסום ארטיפקט.
תקלה נחשבה כל נפילה שלא בגלל הקוד: סוכן לא זמין, התנגשות גרסאות של תלויות, פרמטר סביבה שגוי. נפילות באשמת המפתח נמדדו בנפרד — אחרת המדד היה מודד איכות קוד, לא את הצינור.
תיאור הבנייה הועבר ל-Kotlin DSL במאגר, הסוכנים הפכו לסוכני ענן ולמשימה אחת, השלבים הורצו במקביל עד שישה, ונוסף מטמון תלויות. חציון הבנייה — 8 דקות, שיעור הנפילות — 4%, פעולות ידניות בשחרור — אחת, מקומיט ועד ארטיפקט — 14 דקות.
Kotlin DSL או בנייה דרך ממשק ווב: מה לבחור?
תשובה קצרה: אם הצינור משתנה לעתים קרובות יותר מפעם-פעמיים ברבעון ויותר ממהנדס אחד עובד עליו — תארו את הבנייה בקוד ב-Kotlin DSL. אם ההגדרה יציבה ומתקן אותה אדם אחד, ממשק הווב של TeamCity מספיק: מאגר הגדרות יוסיף עבודה בלי תמורה.
ב-Kotlin DSL תיאור הבנייה נמצא באותו מאגר שבו נמצא הקוד. כל שינוי — שלב, תלות, פרמטר סוכן — מגיע דרך בקשת מיזוג: רואים שורה-שורה מה ולמה שינו ומי אישר, וחזרה מחזירה את המצב הקודם מההיסטוריה. ניהול גרסאות של הגדרה וסקירת שינויי בנייה מפסיקים להיות הסכמה בעל פה — הם מובנים בתהליך.
ממשק הווב מנצח במהירות: הגדרה בקליקים מהירה יותר לפרויקטים אחידים, היסטוריית התיקונים נשמרת בתוך המערכת, ולצוות קטן זה מספיק. המגבלה מתגלה כשגדלים: תבניות משותפות משוכפלות ביד, וכדי להבין למה בנייה מתנהגת אחרת מאשר לפני חצי שנה, אפשר רק דרך היומן בתוך השרת.
אפשר לעבור בהדרגה, בלי לכתוב הכול מחדש בבת אחת. הפרויקט נשאר בממשק הווב, ואל הקוד מוציאים את המשותף: תבניות, פרמטרים של סביבות, כללי הרצה. אחר כך מעבירים את הצינורות אחד-אחד — עם בדיקה שהתנהגות הבנייה לא השתנתה.
הקריטריון פשוט: הרבה פרויקטים, ענפים וחובה לאשר תיקונים — Kotlin DSL; צינור או שניים יציבים ואחראי אחד — ממשק ווב. מצב משולב גם עובד: הוא מגביר את הנוהג של ניהול גרסאות להגדרה במקום שבו זה נותן אפקט.
ספקות נפוצים: גישות, סודות, חזרה של בנייה
ספקות שצפים לרוב לפני ההתחלה הם כמעט תמיד סביב דבר אחד: מה יקרה אם משהו יישבר או ידלוף. בהמשך — חמש שאלות שאנחנו מבררים עם הלקוח לפני הקומיט הראשון ב-TeamCity, והתשובות שלנו כברירת מחדל.
היכן נשמרים סודות הבנייה והאם הם ידלפו ללוג?
סודות אינם נכנסים למאגר עם תיאור הבנייה — הם נמצאים במאגר מאובטח של השרת או במנהל סודות חיצוני, ומוחדרים לשלב מסוים רק בזמן ההרצה. הערכים מוסתרים בפלט, ולכן הטוקן אינו נראה לא בלוגים, לא בארטיפקטים, ולא בממשק אצל מי שאין לו הרשאות לפרויקט. ההרשאה לערוך סוד נפרדת מההרשאה להריץ בנייה.
כיצד מופרדות הסביבות כדי שבדיקה לא תעבור לפרודקשן?
לכל סביבה — סט משלה של משתנים ומפתחות גישה, והפריסה לפרודקשן יוצאת רק מענף מאובטח ובאישור האחראי. הארטיפקט נבנה פעם אחת ומתקדם בין סביבות, ולא נבנה מחדש: מה שעבר בדיקות מגיע לפרודקשן בלי שינויים. כך "עובד בטסט, נופל בפרודקשן" מפסיק להיות סוג תקלה.
מה נגיש לסוכני הבנייה והאם משהו נשאר אחרי הבנייה?
הסוכן מקבל רק את הפרמטרים שנדרשים לשלב הנוכחי, ומפתח נפרד לקריאה מהמאגר — בלי הרשאת כתיבה. סוכני ענן נוצרים למשימה ונמחקים אחריה, ולכן בין פרויקטים ובין הרצות לא נשאר דבר.
כיצד מתעדכנים הסוכנים והאם הצינור לא ייעצר כולו?
העדכון נעשה בגלים: קודם מעדכנים סוכן אחד ובודקים אותו על בניות לא בפרודקשן, אחר כך את השאר. תאימות גרסת הסוכן והשרת נבדקת לפני עדכון המוני — אחרת הצינור נעצר כולו, וזו בדיוק התקלה שהיקרה ביותר בזמן השבתה.
מה לעשות אם תיאור הבנייה נפגע או שמישהו שבר אותו?
היסטוריית תיאור הבנייה נשמרת במערכת בקרת גרסאות, ולכן חזרה היא revert של קומיט, לא תיקון ידני מהזיכרון. בנוסף אנחנו מחזיקים את הארטיפקט העובד האחרון ואת פרמטרי ההרצה שלו: אפשר לבנות מחדש את השחרור מאותו קומיט, גם אם הצינור שבור.
נדבר על המשימה: מה נדרש להערכה ולתוכנית עבודה
כדי לחזור עם הערכה ותוכנית ריאליות, ולא עם טווח "מכאן ועד כאן", אנחנו צריכים תמונת מצב של התשתית הנוכחית שלכם. בהגדרת TeamCity היא נותנת הבנה של היקף העבודה, השלבים והסיכונים — מה אפשר להוציא לסוכנים בענן, מה ייאלץ להישאר על מכונות משלכם וכיצד לעבור בלי לעצור שחרורים.
- מיפוי בניות: כמה הגדרות ופרויקטים במתחם, אילו שפות וסביבות ריצה, היכן נשמרים ארטיפקטים, אילו בניות כבר אינן בשימוש ואפשר להוציא אותן.
- צינור הבנייה הנוכחי: במה הוא מופעל, אילו שלבים עובר הקוד מקומיט ועד פרודקשן, היכן נשארים צעדים ידניים ואישורים ידניים.
- דרישות גישה: תפקידים במאגרי קוד ובמאגר תמונות, היכן נמצאים הסודות ומי הבעלים שלהם, האם נדרש מתחם רשתי נפרד לסוכני בנייה.
- סביבת הרצה: סוכנים משלכם או בענן, אילו רישיונות ומכסות כבר יש, האם יש מגבלות רשת, אחסון ומשך בנייה.
- קריטריוני מוכנות: מה נחשב תוצאה — זמן בנייה, שיעור הבדיקות שעוברות אוטומטית, ויכולת חזרה לארטיפקט הקודם בשלב אחד.
- סדר מסירה: מי מקבל את העבודה, האם נדרשים נהלים והוראות לצוות שלכם, מי אחראי לצינור אחרי ההפעלה.
תארו את המשימה בצורה חופשית — לפי הנקודות האלה או איך שנוח. נחזור עם הערכה, תוכנית שלבים ולוחות זמנים, ואת הנקודות השנויות במחלוקת במיגרציה ובגישות נברר בנפרד.