מדריך מסירה רציפה - בניית צינור אספקה ​​רציף באמצעות ג'נקינס

אספקה ​​רציפה:

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

• מהי אספקה ​​רציפה?
• סוגי בדיקות תוכנה
• ההבדל בין אינטגרציה רציפה, מסירה ופריסה
• מה הצורך במסירה רציפה?
• שימוש בפועל ב- Jenkins ו- Tomcat

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

מהי אספקה ​​רציפה?

זהו תהליך שבו אתה בונה תוכנה בצורה כזו שתוכל להשתחרר לייצור בכל עת.שקול את התרשים להלן:

תן לי להסביר את התרשים לעיל:

• סקריפטים לבנות אוטומטיים יאתרו שינויים בניהול קוד המקור (SCM) כמו Git.
• לאחר גילוי השינוי, קוד המקור ייפרס לשרת בנייה ייעודי כדי לוודא שהבנייה אינה נכשלת וכל שיעורי הבדיקה ומבחני האינטגרציה פועלים בסדר.
• לאחר מכן, יישום ה- build נפרס על שרתי הבדיקה (שרתי ייצור מראש) לבדיקת קבלת משתמשים (UAT).
• לבסוף, היישום נפרס באופן ידני על שרתי הייצור לצורך שחרורו.

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

סוגי בדיקות תוכנה:

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

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

בדיקת Whitebox:

ישנם שני סוגים של בדיקות הנמצאים בקטגוריה זו.

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

בדיקת Blackbox:

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

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

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

ההבדלים בין שילוב מתמשך, מסירה ופריסה:

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

באינטגרציה רציפה, כל התחייבות קוד נבנית ונבדקת, אך אינה במצב שחרורו. כלומר יישום ה- build אינו נפרס אוטומטית על שרתי הבדיקה על מנת לאמת אותו באמצעות סוגים שונים של בדיקות Blackbox כמו - UAT (User Acceptance Testing).

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

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

תן לי לסכם את ההבדלים באמצעות טבלה:

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

למד כיצד ליצור צינורות CI / CD באמצעות Jenkins On Cloud

אך השאלה היא האם די בשילוב מתמשך.

מדוע אנו זקוקים למסירה רציפה?

הבה נבין זאת בדוגמה.

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

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

מה יכולה להיות הסיבה הברורה לכישלון?

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

מפתח אחד תפיסתי נקט בגישה חכמה:

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

מה זה indexof ב- javascript

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

הצהרת בעיה:

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

תן לי לסכם את הלקחים שנלמדו על ידי הסתכלות על הבעיות שלעיל:

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

פתרון - צינור אספקה ​​רציף (בדיקת קבלה אוטומטית):

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

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

די לתיאוריה, כעת אראה לך כיצד ליצור צינור אספקה ​​רציפה באמצעות ג'נקינס.

צינור אספקה ​​רציף באמצעות ג'נקינס:

כאן אשתמש בג'נקינס כדי ליצור צינור אספקה ​​רציף, שיכלול את המשימות הבאות:

השלבים המעורבים בהדגמה:

• אחזור הקוד מ- GitHub
• קומפילציה של קוד המקור
• בדיקת יחידות והפקת דוחות הבדיקה של JUnit
• אריזת היישום לקובץ WAR ופריסתו בשרת Tomcat

דרישות קדם:

• מכונת CentOS 7
• ג'נקינס 2.121.1
• דוקר
• טומקט 7

שלב 1 - עריכת קוד המקור:

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

תן שם לפרויקט שלך ובחר פרויקט פריסטייל:

כאשר תגלול מטה תמצא אפשרות להוסיף מאגר קוד מקור, בחר git והוסף את כתובת ה- URL של המאגר, באותו מאגר יש קנס pom.xml בו נשתמש לבניית הפרויקט שלנו. שקול את צילום המסך שלהלן:

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

לפני שאמשיך, תן לי לתת לך הקדמה קטנה למחזור בניית Maven.

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

להלן רשימת שלבי הבנייה:

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

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

חבילה נקייה mvn

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

אז נתחיל בלחבר את קוד המקור. בלשונית ה- build, לחץ על הפעל מטרות maven ברמה העליונה והקלד את הפקודה הבאה:

לְלַקֵט

שקול את צילום המסך שלהלן:

זה ימשוך את קוד המקור ממאגר GitHub וגם ירכיב אותו (Maven Compile Phase).

לחץ על שמור והפעל את הפרויקט.

כעת לחץ על פלט המסוף כדי לראות את התוצאה.

שלב 2 - בדיקת יחידות:

כעת ניצור פרויקט פריסטייל נוסף נוסף לבדיקת יחידות.

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

כעת, בלשונית 'Buid Trigger' לחץ על 'build לאחר בניית פרויקטים אחרים'. שם הקלד את שם הפרויקט הקודם בו אנו מכינים את קוד המקור, ותוכל לבחור באחת מהאפשרויות הבאות:

• מפעילים רק אם הבנייה יציבה
• מפעילים גם אם המבנה אינו יציב
• מפעילים גם אם המבנה נכשל

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

בכרטיסיה Build, לחץ על הפעל מטרות maven ברמה העליונה והשתמש בפקודה הבאה:

מִבְחָן

ג'נקינס גם עושה עבודה נהדרת לעזור לך להציג את תוצאות הבדיקה שלך ואת מגמות תוצאות הבדיקה.

התקן בפועל לדיווח על בדיקות בעולם ג'אווה הוא פורמט XML המשמש את JUnit. פורמט זה משמש גם כלי בדיקת Java רבים אחרים, כגון TestNG, Spock ו- Easyb. ג'נקינס מבין את הפורמט הזה, כך שאם ה- build שלך מייצר תוצאות בדיקת XML של JUnit, ג'נקינס יכול ליצור דוחות בדיקה גרפיים ונתונים סטטיסטיים על תוצאות הבדיקה לאורך זמן, וגם לאפשר לך להציג את הפרטים של כשלים בבדיקה. ג'נקינס עוקב אחר משך הזמן שלביצוע הבדיקות שלך, הן ברחבי העולם והן לפי בדיקה - זה יכול להיות שימושי אם אתה צריך לאתר בעיות ביצועים.

אז הדבר הבא שעלינו לעשות הוא לגרום לג'נקינס לעקוב אחר בדיקות היחידות שלנו.

עבור למקטע פעולות לאחר הבנייה וסמן את תיבת הסימון 'פרסם דוח תוצאות בדיקת JUnit'. כאשר Maven מריץ בדיקות יחידה בפרויקט, הוא מייצר באופן אוטומטי את דוחות הבדיקה XML בספרייה הנקראת דוחות בטוח. אז הזן '** / target / surefire-reports / *. Xml' בשדה 'XMLs של דוח בדיקה'. שתי הכוכביות בתחילת הנתיב ('**') הן שיטות עבודה מומלצות בכדי להפוך את התצורה לקצת יותר חזקה: הם מאפשרים לג'נקינס למצוא את ספריית היעד ולא משנה איך הגדרנו את ג'נקינס לבדוק את קוד המקור.

** / יעד / דוחות בטוחה / *. xml

שוב שמור אותו ולחץ על בנה עכשיו.

כעת, דוח JUnit נכתב ל- / var / lib / jenkins / סביבת עבודה / test / gameoflife-core / target / surefire-reports / TEST-behavior.

בלוח המחוונים של ג'נקינסאתה יכול גם להבחין בתוצאות הבדיקה:

ג'נקינס לעומת בובה לעומת שף

שלב 3 - יצירת קובץ מלחמה ופריסה בשרת Tomcat:

כעת, השלב הבא הוא לארוז את היישום שלנו בקובץ WAR ולפרוס אותו בשרת Tomcat לבדיקת קבלת משתמשים.

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

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

בעיקרון, לאחר עבודת הבדיקה, שלב הפריסה יתחיל אוטומטית.

בכרטיסיה build, בחר script shell. הקלד את הפקודה שלמטה כדי לארוז את היישום בקובץ WAR:

חבילת mvn

השלב הבא הוא לפרוס קובץ WAR זה ל- Tomcatשרת. בכרטיסייה 'פעולות לאחר בנייה' בחר לפרוס מלחמה / אוזן למיכל. כאן, תן את הנתיב לקובץ המלחמה ותן את נתיב ההקשר. שקול את צילום המסך שלהלן:

בחר את אישורי Tomcat והבחין בצילום המסך שלמעלה. כמו כן, עליך למסור את כתובת ה- URL של שרת Tomcat שלך.

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

לחץ על מערכת ובחר אישורים גלובליים.

ואז תמצא אפשרות להוסיף את האישורים. לחץ עליו והוסף אישורים.

הוסף את אישורי Tomcat, שקול את צילום המסך שלהלן.

לחץ על אישור.

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

לחץ על שמור ואז בחר בנה עכשיו.

עבור אל כתובת האתר של tomcat שלך, עם נתיב ההקשר, במקרה שלי זה http: // localhost: 8081. כעת הוסף את נתיב ההקשר בסופו של דבר, שקול את צילום המסך להלן:

קישור - http: // localhost: 8081 / gof

אני מקווה שהבנת את המשמעות של דרך ההקשר.

כעת צור תצוגת צינור, שקול את צילום המסך שלהלן:

לחץ על סמל הפלוס כדי ליצור תצוגה חדשה.

הגדר את הצינור כמו שאתה רוצה, שקול את צילום המסך שלהלן:

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

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

מה זה סוג הליהוק בג'אווה

לכן אנו מסוגלים לפרוס את היישום ברציפות בשרת הבדיקה לצורך בדיקת קבלת משתמשים (UAT).

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

על מנת לבנות צינורות CI / CD עליך לשלוט במגוון רחב של מיומנויות לשלוט במיומנויות ה- DevOps הנדרשות כעת