מה זה Jenkins ולמה משתמשים בו¶
תארו לכם שכל פעם שמישהו בצוות דוחף קוד, מישהו צריך ידנית להריץ טסטים, לבנות את הפרויקט, ואם הכל עבר - לפרוס אותו לשרת. עכשיו תכפילו את זה בעשרות דחיפות ביום, בכמה מפתחים, ובכמה סביבות. זה בדיוק התהליך שהפך את Jenkins לאחד הכלים הכי נפוצים בעולם ה-DevOps, עוד לפני שהמונח DevOps בכלל היה נפוץ.
הבעיה ש-Jenkins פותר¶
בנייה, בדיקה ופריסה ידניים הם לא רק מייגעים, הם גם מקור אינסופי לטעויות אנוש. מישהו שוכח להריץ טסט, מישהו פורס גרסה ישנה בטעות, מישהו מדלג על שלב כי "זה בטח בסדר". ברגע שיש לכם יותר ממפתח אחד ומכפולת קוד אחת, אתם צריכים תהליך אוטומטי ועקבי שרץ בדיוק אותו דבר בכל פעם - בלי קשר למי שדחף את הקוד ובאיזו שעה.
Jenkins הוא שרת אוטומציה שרץ אצלכם, ועושה בדיוק את זה: בכל פעם שקורה משהו - קוד נדחף, pull request נפתח, שעון מגיע לזמן מסוים - הוא מריץ תהליך מוגדר מראש של בנייה, בדיקה, ולעיתים גם פריסה.
איך Jenkins עובד בפועל¶
היחידה הבסיסית ב-Jenkins היא ה-job, או במונחים מודרניים יותר, ה-pipeline. פייפליין מתאר סדרה של שלבים - stages - שצריכים לרוץ אחד אחרי השני, כמו "התקן תלויות", "הרץ טסטים", "בנה את החבילה", "פרוס לסביבת בדיקות".
הדרך המודרנית להגדיר את זה היא באמצעות קובץ שנקרא Jenkinsfile, שיושב בתוך ריפוזיטורי הקוד עצמו ומתאר את הפייפליין כקוד - pipeline as code. זה משמעותי כי זה אומר שתהליך הבנייה עצמו עובר code review יחד עם שאר הקוד, נשמר בהיסטוריית הגרסאות, ואפשר לשחזר בדיוק איך פרויקט נבנה בכל נקודת זמן בעבר.
Jenkins גם תומך בבנייה מבוזרת - הוא יכול להריץ את השלבים על מכונה מרכזית שנקראת controller, אבל לחלק את העבודה בפועל לכמה agents (או nodes) שמותקנים על מכונות שונות, מה שמאפשר להריץ בנייות במקביל ולתמוך בסביבות שונות - נניח, agent אחד עם לינוקס ואחד עם ווינדוס.
פלאגין-אקוסיסטם עצום¶
מה שהפך את Jenkins לכל כך שולט הוא האקוסיסטם של plugins שלו. יש אלפי תוספים שמתחברים לכל כלי שאפשר לחשוב עליו - Docker, Kubernetes, מערכות ניהול גרסאות, כלי בדיקות, פלטפורמות ענן, מערכות התראות. כמעט בכל תהליך שאתם רוצים לבנות, כבר יש plugin שמקל עליו, וזה חוסך המון עבודת פיתוח בהשוואה לכתיבת אינטגרציות מאפס.
למה ארגונים עדיין נדבקים ב-Jenkins¶
למרות שיש כלים חדשים יותר, Jenkins עדיין רץ בהמון ארגונים, ולא בטעות. הוא open source ומתארח באופן עצמאי - self-hosted - מה שאומר שיש לכם שליטה מלאה על התשתית, על הנתונים, ועל איפה הכל רץ, בלי תלות בספק חיצוני. זה קריטי בארגונים עם דרישות אבטחה או רגולציה מחמירות. הוא גם גמיש להפליא - כמעט כל תהליך בנייה מורכב, ולא משנה כמה הוא ייחודי לארגון הספציפי, אפשר לבנות ב-Jenkins.
Jenkins מול GitHub Actions¶
השאלה הזאת עולה כל הזמן, אז שווה להבהיר בקצרה. GitHub Actions הוא שירות מנוהל שמובנה ישירות בתוך GitHub, קל להתחיל איתו, ולא דורש שום תשתית משלכם. Jenkins, לעומת זאת, דורש שתקימו ותתחזקו שרת בעצמכם, אבל בתמורה מקבלים גמישות וקונטרול מלאים - לא מוגבלים לפלטפורמה אחת, ואפשר להתאים אותו לכל תהליך מורכב שהארגון צריך. הבחירה בין השניים היא לרוב שאלה של כמה תשתית אתם מוכנים לתחזק מול כמה שליטה אתם צריכים.
מלכודת נפוצה¶
טעות שכיחה היא לבנות פייפליינים מסובכים ישירות דרך ממשק הניהול של Jenkins - freestyle jobs - במקום להשתמש ב-Jenkinsfile. זה עובד בהתחלה, אבל התהליך נשאר "תקוע" בתוך שרת Jenkins עצמו, בלי היסטוריה, בלי code review, וקשה מאוד לשחזר או להעביר לסביבה אחרת. תמיד עדיף להתחיל ישר עם pipeline as code, גם אם זה דורש רגע נוסף של למידה.
אם אתם רוצים להבין את כל התמונה של איך שרתים, פריסות ותהליכי עבודה מתחברים יחד בצד השרת, מומלץ להעיף מבט על קורס צד שרת.
Jenkins הוא לא הכלי הכי מבריק או המודרני שיש, אבל הוא יציב, מוכח, וגמיש בדיוק במקומות שבהם כלים חדשים יותר עדיין מתקשים. זו בדיוק הסיבה שהוא עדיין כאן, שנים אחרי שכולם חזו את סופו.