אנחנו כותבים פרויקט. הוסף את SpringBoot והגדר תהליך CI - "פרויקט ג'אווה מא' עד ת'"

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

אנו כותבים JRTB-0M

במשימה זו עלינו להוסיף מסגרת SpringBoot ריקה לעבודה עתידית. נעשה זאת באותו אופן כמו שעשינו במאמר על SpringBoot + Flyway . הורד את הפרויקט , פתח אותו ב-IDEA וצור סניף חדש בשם JRTB-0 . תיארתי כיצד לעשות זאת באמצעות רעיון כאן . זה יקל עלינו לעקוב אחר עבודות בעתיד. האם כבר ידעתם שאין יותר סניף מאסטר ? עכשיו זה נקרא neutrally- main . אז אנחנו מתרגלים לזה. אם כי, למען האמת, אנחנו תמיד יכולים לשנות את שמו בחזרה למאסטר. אנחנו הולכים ל- Spring Initializr ויוצרים מסגרת SpringBoot עבור הבוט שלנו. כרגע, הגרסה הצעירה ביותר של ספרינט המגפיים המוצעת היא 2.3.7, בוא ניקח את זה. אתאר בנפרד את ההגדרות הבאות:

• Project: Maven Project - כבר דנו ב-Maven כאן וכאן . לכן, אני אתאר בנוסף רק את מה שלא חשפתי במאמרים קודמים. אם יש "כתמים לבנים" כאלה כמובן)
• שפה: ג'אווה - הכל ברור כאן. אם יש רצון, נוכל לשכתב עניין זה בקוטלין. זה עתה קניתי לעצמי ספר קוטלין בפעולה, נלמד את קוטלין ביחד))
• Spring Boot: 2.3.7 - אנו לוקחים את הגרסה הקטנה ביותר המוצעת כדי למנוע בעיות. זו כבר גרסה מודרנית לחלוטין של המגף.

מטא נתונים של הפרויקט:

• קבוצה: com.github.javarushcommunity - כאן אנו בוחרים את הדומיין בו מתארחת קבוצת המאגרים שלנו.
• חפץ: javarush-telegrambot - תיאור מקסימלי של הפרויקט.
• שם: Javarush TelegramBot - נכתוב את זה במלואו כאן.
• תיאור: בוט טלגרם עבור Javarush מקהילה לקהילה - הנה תיאור מפורט יותר של הפרויקט.
• שם החבילה: com.github.javarushcommunity.jrtb - כאן כבר ניתן להשתמש בקיצור לשם הפרויקט. כעת הפרויקט יתחיל בחבילה זו. למה כל כך הרבה? כך שכאשר נוסיף פרויקטים אחרים ל-classpath, הם יהיו בחבילות שונות. כל אחד בדרכו הייחודית. זה חשוב כדי לשמור על עקרונות OOP.
• אריזה: צנצנת היא הסטנדרט שלנו)
• Java: 11 - אנחנו נהיה צעד אחד קדימה. אני לא חושב שאשתמש בחידושים אחרי ה-Java השמיני, אבל תן לזה להיות. הוא לא מבקש אוכל)... ההחלטה הזו תיתן לנו ביצת פסחא קטנה בעתיד)

לא נוסיף שום תלות לעת עתה. אנחנו לא צריכים את זה בשביל המשימה הזו. לאחר שמילאנו את כל זה, אנו מקבלים (הנה קישור לפרויקט שנוצר): לאחר מילוי, לחץ על GENERATE והוסף את כל הפנימיות בארכיון לפרויקט שלנו. הוסף קבצים לפרויקט. כתוצאה מכך, יש לנו אפליקציה. כדי לבדוק אם הוא מורכב בכלל, כנסו לטרמינל וכתבו: $ mvn clean package אם יש לכם אותו כמו מכאן, הכל בסדר: הפרויקט מורכב, וה-jarnik כבר מוכן בתיקיית היעד. בשלב זה, המשימה בתיאור מוכנה. זה פשוט, נכון? לכן, אנו מתחייבים ודוחפים לסניף שלנו: אנו מוסיפים את שם המשימה שלנו בתחילת תיאור ההתחייבות, כדי שבהמשך יתברר במסגרת איזו משימה נעשתה העבודה. לחץ על Commit ו-Push ... שוב אנו בודקים ובודקים מה בדיוק אנו רוצים לדחוף מהמאגר המקומי למרוחק, ולוודא שהכל בסדר, לחץ על Push . מה הצעד הבא שלנו? לפי כל הכללים (שניתן לקרוא במאמר זה , בחלק על זרימת GitHub), צריך ליצור בקשת pull עבור הסניף הראשי ולחכות שמישהו מהצוות יבדוק את הקוד. מכיוון שאני לבד, אצור רשמית בקשת משיכה ואבדוק הכל שוב. אני עובר לדף המאגר, ו-Github כבר יודע שיש לנו תוספת ומציע ליצור בקשת משיכה: אין מכשולים לפטריוטים (ג) - אנחנו יוצרים אותה, כפי שהוצע. אנו מגדירים את אותה תווית, פרוייקט כמו במשימה עליה אנו עובדים וממלאים את התיאור: לחץ על Create pull request .

הגדרת תהליך CI

אנו עוברים לבקשת המשיכה שנוצרה: להלן אנו רואים שאין לנו Continuous Integration מוגדר (להלן - CI). ובכן, זה לא מוגדר, אז מה? למה אנחנו צריכים CI בכלל? מה זה בכלל CI? זו בערך רשימת השאלות שצריכות להדאיג אותנו ברגע זה. באופן כללי, CI הוא תהליך מתמשך של מיזוג קוד לבסיס קוד משותף והפעלת בנייה של הפרויקט לפני כן. מה שנקרא build (מאנגלית build). בכל פעם שאנו בונים פרויקט, אנו מוודאים שהפרויקט נערך, כל הבדיקות שלו עברו בהצלחה, בנוסף לאחר בניית הפרויקט, ניתן להוסיף בדיקות אוטומטיות של בודקים ל-CI המופעלות על ה-build הספציפי הזה. כך, אנו נעשים בטוחים יותר שהשינויים החדשים עובדים כפי שאנו מצפים ואינם שוברים את הפונקציונליות הקודמת. CI טוב גם מכיוון שהוא מתחיל אוטומטית לאחר עדכון בסיס הקוד. כלומר, דחפנו את השינויים שלנו לסניף והתחיל התהליך – הרכבה, בדיקות, בדיקות אוטומטיות ועוד שלבים. אם אחד מהשלבים הללו נכשל, ה-build נחשב שבור ולא ניתן למזג אותו לתוך הסניף הראשי. זה בדיוק מה שנעשה עכשיו: נוסיף את GitHub Actions, שיריץ את הקוד שלנו לאחר הדחיפה. פעולות GitHub משתלבות בצורה מושלמת בזרימת GitHub שלנו, אז נשתמש בה כדי להפוך את העבודה שלנו לאוטומטית. הכלי הזה חזק וגדול מאוד, אבל בינתיים נשתמש בו רק כדי להפעיל את ה-build ולבדוק שהוא מורכב לפי הצורך. כדי להפעיל אותו, מצא את כפתור הפעולות בדף המאגר ופעל לפיו: מצא את זרימת העבודה הרציפה של השילוב שאנו צריכים: לחץ על הגדר זרימת עבודה זו. לאחר מכן, מציעים לנו להשתמש בתבנית שלהם: אנחנו מסכימים לחלוטין, בואו נבהיר קצת את הכל:

# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven

name: Java CI with Maven

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build with Maven
      run: mvn -B package --file pom.xml

זה מציין שפעולת GitHub נקראת בשני מקרים:

1. כאשר מתבצעת דחיפה לסניף הראשי.
2. כאשר נוצרת בקשת משיכה בסניף הראשי.

סעיף העבודות מתאר את השלבים שיבוצעו. יש לנו רק שלב אחד - לבנות. זה מראה שהפרויקט שלנו יושק באובונטו עם הפקודה mvn -B package --file pom.xml . זה בדיוק מה שעשינו במקום. אם אתה רוצה לשנות משהו כאן, בבקשה. אני אשתמש בתבנית הזו, זה יספיק לי. אני לוחץ על התחל להתחייב , בוחר בצור ענף חדש כדי להגדיר את התהליך ולאחר מכן הצעת קובץ חדש . אבל תהליך הבנייה נפל... כפי שאתה יכול לראות, כשלון לאחר 14 שניות - בנייה. זה נראה כאילו משהו קרה: בוא נלך לאסיפה ונסתכל על הפרטים: כתוב שלא הצלחתי למצוא זיכרון כזה. למה? אההה, בדיוק, בדיוק! כי יצרנו שינויים בסניף המאסטר, אבל המשימה שלנו עדיין לא שם. ובגלל זה הוא לא מצא את הזיכרון... לכן, עכשיו אנחנו עושים את הדברים הבאים: אנחנו ממזגים את הנתונים האלה לתוך המאסטר, ואז אנחנו ממזגים את הענף הראשי לתוך JRTB-0, ואז הכל צריך ללכת בסדר. בבקשת משיכה עם שינויים בפעולות github, לחץ על מיזוג בקשת משיכה : וחזור על אשר מיזוג . לאחר מכן, Github מבקשת מאיתנו למחוק את הסניף שבו עבדנו. אנחנו לא מסרבים ומוחקים: בשלב הבא, לא מצאתי בבקשת המשיכה מ-SpringBoot איך לשלוף שינויים מהסניף הראשי מהאתר, אז נעשה זאת ידנית דרך IDEA.

שלב 1: עדכן סניף ראשי למאגר מקומי.

הרעיון הוא ללכת לסניף המאסטר, ללחוץ על ctrl + t ולעדכן את ענף המאסטר:

שלב 2: מיזוג שינויים מהענף הראשי לענף JRTB-0.

בוא נלך ל-JRTB-0 ונמזג את הראשי לתוכו.

שלב 3: דחוף שינויים.

הקש ctrl + shift + k ואשר את הדחיפה. עכשיו אנחנו מחכים שהבנייה תעבור והיא תהיה ירוקה!)) אבל זה שוב אדום. מה זה? אנחנו נכנסים ליומני הפעולות ורואים שיש לנו לא מסונכרן בגרסאות ה-Java. ב-GitHubActions זה 8, אבל אנחנו משתמשים ב-11: עכשיו יש שתי אפשרויות: או לתקן את הפעולות, או להוריד את הגרסה לשמינית. האפשרות הראשונה, כך נראה לי, טובה ונכונה יותר. אנו מבצעים שינויים בהתחייבות נפרדת: לא נעבוד עם Java 8, אלא עם Java 11. ואחרי זה, סוף סוף, הכל הסתדר לנו, והצלחנו להגדיר את תהליך ה-CI שלנו לפרויקט. דברים כאלה צריכים להיות מוגדרים בשלב הראשוני, כדי שלא תצטרכו לדאוג לגבי זה אחר כך. עכשיו אתה יכול לראות שהבנייה עברה ותוכל להתמזג ללא חשש:

הקמת עבודה עם סניפים במאגר

אתה יכול גם להגדיר דברים כאלה במאגר בתור כללים בעבודה עם ענפים. אני רוצה לעשות את זה כך שלא ניתן לדחוף את הסניף הראשי ישירות, אלא רק דרך בקשות משיכה, ואני רוצה לעשות את זה כך שאי אפשר למזג בקשת משיכה אם ה-build נכשל (כלומר, אם GitHub Actions נכשלו ב- איזה צעד). כדי לעשות זאת, מצא את כפתור ההגדרות ובחר סניפים : כרגע אין חוקים לסניפים, אז בואו נוסיף אחד חדש דרך כפתור הוסף כלל : יש כאן הרבה הגדרות, וכל אחד יכול לעשות משהו שיתאים לו צרכי. על מנת שה-build יעבור בהצלחה ב-pull request לפני המיזוג, הוסף תיבת סימון ל-Require status checks to over before merging ובחר את הסטטוס שאנחנו צריכים - build. זה מספיק לעת עתה: אז אתה יכול לעדכן את ההגה הזה ולראות מה עוד אתה רוצה. לחץ על צור כדי ליצור הגה זה. לאחר מכן, אם נלך שוב לבקשת המשיכה שלנו, נוכל לראות שעכשיו הסימון שלנו מסומן כנדרש: בוא נבדוק את דף הפרויקט שלנו, המציג את כל סטטוסי המשימות: אתה יכול מיד לראות על איזו משימה עובדים. יתרה מכך, העבודה כבר בוצעה, והמשימה נמצאת בסטטוס סקירת קוד.

סגירת JRTB-0

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

מסקנות

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

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