מדוע ג'נקינס הופך להיות מנוע השטים

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

התמרון האחרון הוא איך CloudBees הפכה לחברה שהיא היום. בעבר היה ספק PaaS ענן ציבורי עצמאי עבור קודני Java (שדורג מאוד על ידי אנדרו אוליבר בסעיף "באיזה PaaS פריקי עלי להשתמש?"), CloudBees הסתובבה בחדות לפני 18 חודשים כדי להשיק מחדש את הספק המוביל של ג'נקינס, פתוח מאוד פופולרי. כלי מקור לניהול תהליך פיתוח תוכנה.

לדברי המנכ"ל סשה לבורי, כספק Java PaaS CloudBees "גדל יפה", אך "הרבה בחורים גדולים יותר עם המחאות הגדולות יותר" היססו להתחייב בשוק PaaS תנודתי, חסר סטנדרטיזציה. במקביל ג'נקינס המריא כמו רקטה - ולבורי ראה הזדמנות גדולה, במיוחד מכיוון ש CloudBees כבר הציעה את ג'נקינס כשירות וכבר שכרה את Kohsuke Kawaguchi, היוצר של ג'נקינס. התוספת של ג'נקינס הפכה למנה העיקרית.

הג'אגרנאק של ג'נקינס

מה עומד מאחורי הפופולריות של ג'נקינס? במילים פשוטות, ג'נקינס הפך לסטנדרט קוד פתוח לניהול צד ההתפתחות של devops, החל מניהול קוד מקור ועד למסירת קוד לייצור. לדברי Labourey, "הקהילה רואה בג'נקינס מנוע תזמור ואוטומציה ... אני חושב שהסיבה שבגינה ג'נקינס הפך למנוע בפועל היא בגלל שהוא ניתן לניתוק מאוד." נוצרה מערכת אקולוגית של יותר מ -1,100 תוספים המאפשרת ללקוחות להוסיף כל מיני פונקציונליות ולשלב את ג'נקינס עם כל דבר, החל מ- Active Directory ועד GitHub ועד ל- OpenShift PaaS.

ג'נקינס הוא פתרון לאינטגרציה רציפה (CI) ואספקה ​​רציפה (CD). הרעיון של CI הוא למזג קוד ממפתחים בודדים לפרויקט מספר פעמים ביום ולבדוק ברציפות כדי למנוע בעיות במורד הזרם. תקליטור לוקח את זה צעד קדימה כדי להבטיח שכל הקוד הממוזג יהיה תמיד במצב מוכן לייצור. Jenkins מאפשר למפתחים להפוך תהליך זה לאוטומטי ככל האפשר - עד לנקודת הפריסה. Labourey מספק דוגמה:

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

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

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

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

להגיע מכאן

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

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

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

ארגוני פיתוח נוטים לדרישות מגוונות מאוד וספציפיות. אז CloudBees מציעה גם גרסת SaaS כללית המבוססת על מנוי המופעלת על ידי CloudBees וגם גרסת "SaaS פרטית", אשר לקוחות יכולים לפרוס ב- AWS או ב- Azure (או באופן מקומי ב- OpenStack) ולהתאים אותה אישית לפי ליבם.

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

"זה מעניין אם אתה מקבל יותר יעילות של 10 אחוז; אם אתה מוציא 100 מיליון דולר בשנה ב- IT, ובכן נהדר - יש לך 10 מיליון דולר שאתה יכול להוציא במקום אחר", אומר Labourey. "אך היתרון האמיתי הוא כאשר העסק מבין שעל ידי מינוף הכלים הללו ודרך הפעולה הזו הם יכולים להגדיל את המכירות ב -10 אחוזים."