מה זה ג'נקינס? הסביר שרת ה- CI

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

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

ג'נקינס - ההדסון במקור - היה תגובה ישירה למגבלה זו.

הדסון וג'נקינס

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

קדימה מהירה לשנת 2011, ומחלוקת בין אורקל (שרכשה את סאן) לבין קהילת קוד הפתוח העצמאית של הדסון הובילה למזלג עם שינוי שם, ג'נקינס. בשנת 2014 Kagaguchi הפך ל- CTO של CloudBees, המציעה מוצרי אספקה ​​רציפים מבוססי Jenkins.

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

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

בינואר 2020 קוואגוצ'י הודיע ​​שהוא עובר לסטארט-אפ החדש שלו, Launchable. הוא גם אמר כי הוא ייסוג רשמית מג'נקינס, אם כי יישאר בוועדת הפיקוח הטכנית של הקרן למסירה רציפה, ויעביר את תפקידו ב- CloudBees ליועץ.

סרטון קשור: כיצד לספק קוד מהר יותר עם CI / CD

אוטומציה של ג'נקינס

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

איך ג'נקינס עובד

ג'נקינס מופץ כארכיון WAR וכחבילות מתקין עבור מערכות ההפעלה הגדולות, כחבילת Homebrew, כתמונת Docker וכקוד מקור. קוד המקור הוא בעיקר Java, עם כמה קבצי Groovy, Ruby ו- Antlr.

אתה יכול להריץ את ה- Jenkins WAR העצמאי או כסרוולט בשרת יישומי Java כגון Tomcat. בשני המקרים, הוא מייצר ממשק משתמש באינטרנט ומקבל שיחות ל- REST API שלו.

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

תוספים של ג'נקינס

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

לאחר שבחרת את קבוצת התוספים הראשונית שלך, לחץ על כפתור ההתקנה וג'נקינס יוסיף אותם.

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

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

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

צינורות ג'נקינס

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

כפי שאתה יכול לראות, מקורות סניפים עבור צינור מסוג זה בהתקנת Jenkins הבסיסית שלי יכולים להיות מאגרי Git או Subversion, כולל GitHub. אם אתה צריך סוגים אחרים של מאגרים או שירותי מאגר מקוון שונים, זה רק עניין של להוסיף את התוספים המתאימים ולהפעיל מחדש את Jenkins. ניסיתי, אך לא יכולתי לחשוב על מערכת לניהול קוד המקור (SCM) שעדיין לא מופיע תוסף Jenkins.

צינורות של ג'נקינס יכולים להיות הצהרתיים או כתובים. הצהיר צינור, את פשוט של השני, משתמש גרוב-תואם-תחביר ואם אתה רוצה, אתה יכול להתחיל את הקובץ עם #!groovyלהצביע עורך הקוד שלך בכיוון הנכון. צינור הצהרתי מתחיל עם pipelineבלוק, מגדיר agent, ומגדיר stagesהכוללים הפעלה steps, כמו בדוגמה השלושה שלבים שלהלן.

צנרת {

    סוכן כלשהו

    שלבים {

        שלב ('בנה') {

            צעדים {

                הד 'בניין ..'

            }

        }

        שלב ('מבחן') {

            צעדים {

                הד 'בדיקה ..'

            }

        }

        שלב ('פריסה') {

            צעדים {

                מהדהד 'פריסה ....'

            }

        }

    }

}

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

סוכן {

    העגינה {

        תמונה 'maven: 3-alpine'

        תווית 'התווית שהגדרתי'

        args '-v / tmp: / tmp'

    }

}

stagesמכילים רצף של הנחיה בימתית אחת או יותר. בדוגמה לעיל, שלושת השלבים הם Build, Test ו- Deploy.

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

צנרת {

    סוכן כלשהו

    שלבים {

        שלב ('בנה') {

            צעדים {

                sh 'make'

                ארכיב חפצי חפץ: '** / target / *. jar', טביעת אצבע: נכון

            }

        }

    }

}

כאן אנו קוראים makeממעטפת ואז מעבירים לארכיון את כל קבצי ה- JAR המיוצרים בארכיון ג'נקינס.

postסעיף המגדיר פעולות שיופעלו בסוף הריצה צינור או הבמה. אתה יכול להשתמש במספר אבני פוסט-תנאי בתוך הקטע פוסט: always, changed, failure, success, unstable, ו aborted.

לדוגמה, קובץ ה- Jenkinsfile שלמטה מריץ תמיד את JUnit לאחר שלב הבדיקה, אך שולח דוא"ל רק אם הצינור נכשל.

צנרת {

    סוכן כלשהו

    שלבים {

        שלב ('מבחן') {

            צעדים {

                ש 'תעשה צ'ק'

            }

        }

    }

    הודעה {

        תמיד {

            junit '** / target / *. xml'

        }

        כישלון {

            דואר לכתובת: [email protected], נושא: 'הצינור נכשל :('

        }

    }

}

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

לשם השוואה, שני Jenkinsfiles הבאים שווים לחלוטין.

צינור הצהרתי

צנרת {

    סוכן {צופן 'צומת: 6.3'}

    שלבים {

        שלב ('לבנות') {

            צעדים {

                sh 'npm - גרסה'

            }

        }

    }

צינור תסריט

צומת ('docker') {

    קופה scm

    שלב ('בנה') {

        docker.image ('node: 6.3'). בתוך {

            sh 'npm - גרסה'

        }

    }

}

האוקיאנוס הכחול, ממשק המשתמש של ג'נקינס

אם תרצה את ממשק המשתמש החדש ביותר והגדול ביותר של ג'נקינס, תוכל להשתמש בפלאגין Blue Ocean, המספק חוויית משתמש גרפית. אתה יכול להוסיף את התוסף Blue Ocean להתקנת Jenkins הקיימת שלך או להריץ מיכל Jenkins / Blue Ocean Docker. עם התקנת Blue Ocean, בתפריט הראשי של Jenkins יהיה סמל נוסף:

אתה יכול לפתוח את האוקיאנוס הכחול ישירות אם תרצה בכך. זה בתיקיה / כחול בשרת Jenkins. יצירת צינורות באוקיאנוס הכחול היא קצת יותר גרפית מאשר בג'נקינס רגיל:

ג'נקינס דוקר

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

כאן אני מריץ תמונה של Blue Ocean Docker, שהגיעה עם כמה תוספי שירות Git מותקנים יותר מרשימת ברירת המחדל של ספקי SCM:

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

ניתן גם להתקרב לסניפים (למעלה) ופעילויות (למטה):  

-

למה להשתמש בג'נקינס?

התוסף של צינור ה- Jenkins בו השתמשנו תומך במקרה שימוש כללי באינטגרציה רציפה / מסירה רציפה (CICD), שהוא כנראה השימוש הנפוץ ביותר עבור ג'נקינס. ישנם שיקולים מיוחדים למקרי שימוש אחרים.

פרויקטים של Java היו הקיום המקורי של ג'נקינס. כבר ראינו שג'נקינס תומך בבנייה עם מייבן; זה עובד גם עם Ant, Gradle, JUnit, Nexus ו- Artifactory.

אנדרואיד מפעילה מעין ג'אווה, אך מציגה את סוגיית אופן הבדיקה במגוון הרחב של מכשירי אנדרואיד. הפלאגין של אמולטור האנדרואיד מאפשר לך לבנות ולבדוק כמה שיותר מכשירים מדומים כפי שאתה רוצה להגדיר. הפלאגין של Google Play Publisher מאפשר לך לשלוח builds לערוץ אלפא ב- Google Play לצורך שחרורו או בדיקות נוספות במכשירים בפועל.

הראיתי דוגמאות שבהן ציינו מיכל דוקר כסוכן הצינור ובו ניהלנו את ג'נקינס ו- Blue Ocean במיכל דוקר. מכולות Docker שימושיות מאוד בסביבת Jenkins לשיפור מהירות, מדרגיות ועקביות.

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

ג'נקינס תומך בשפות רבות אחרות מלבד Java. עבור C / C ++, ישנם תוספים כדי ללכוד שגיאות ואזהרות מהקונסולה, ליצור סקריפטים לבנות עם CMake, להריץ בדיקות יחידה ולבצע ניתוח קוד סטטי. לג'נקינס מספר אינטגרציות עם כלי PHP.

אמנם אין צורך לבנות קוד Python (אלא אם כן אתה משתמש ב- Cython, למשל או יוצר גלגל Python להתקנה), אך שימושי שג'נקינס משתלב בכלי בדיקה ודיווח של Python, כגון Nose2 ו- Pytest ואיכות הקוד כלים כמו פילינט. באופן דומה, ג'נקינס משתלב בכלי רובי כגון רייק, מלפפון, בלם, ו- CI :: כתב.

ג'נקינס ל- CI / CD

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