ما در حال نوشتن یک پروژه هستیم. SpringBoot را اضافه کنید و یک فرآیند CI راه اندازی کنید - "پروژه جاوا از A تا Z"

مقاله ای از مجموعه ای در مورد ایجاد یک پروژه جاوا (لینک به سایر مواد در پایان است). هدف آن تجزیه و تحلیل فناوری های کلیدی است که نتیجه آن نوشتن یک ربات تلگرام است. با سلام خدمت خوانندگان عزیز. همانطور که در قسمت قبل توضیح داده شد ، طبق برنامه پیش خواهیم رفت. ما قبلاً یک پروژه ایجاد کرده ایم و زمان آن رسیده که آن را با کد پر کنیم. اکنون همه مسائل به عنوان commit های جداگانه اضافه خواهند شد. من هر آنچه را که لازم است در اینجا شرح خواهم داد. اگر چیزی را از دست دادم یا آن را به اندازه کافی واضح توصیف نکردم، در نظرات بپرسید، سعی می کنم پاسخ دهم.

ما JRTB-0M می نویسیم

در این کار باید یک چارچوب خالی SpringBoot برای کارهای آینده اضافه کنیم. ما این کار را به همان روشی که در مقاله درباره SpringBoot + Flyway انجام دادیم انجام خواهیم داد . پروژه را دانلود کنید ، آن را در IDEA باز کنید و یک شاخه جدید به نام JRTB-0 ایجاد کنید . من نحوه انجام این کار را از طریق یک ایده در اینجا شرح دادم . این امر ردیابی کار را در آینده برای ما آسان تر می کند. آیا قبلاً می دانستید که دیگر شعبه اصلی وجود ندارد ؟ اکنون آن را خنثی - اصلی می نامند . پس عادت می کنیم. اگرچه، صادقانه بگوییم، همیشه می‌توانیم آن را به master تغییر نام دهیم. ما به Spring Initializr می رویم و یک چارچوب SpringBoot برای ربات خود ایجاد می کنیم. در حال حاضر، جوانترین نسخه بوت اسپرینت ارائه شده 2.3.7 است، بیایید آن را بگیریم. تنظیمات زیر را جداگانه توضیح خواهم داد:

• پروژه: پروژه Maven - قبلاً در اینجا و اینجا درباره Maven بحث کرده ایم . بنابراین، من فقط مواردی را که در مقالات قبلی فاش نکردم، توضیح خواهم داد. البته اگر چنین "لکه های سفید" وجود داشته باشد)
• زبان: جاوا - اینجا همه چیز واضح است. در صورت تمایل می توانیم این موضوع را در کاتلین بازنویسی کنیم. من به تازگی برای خودم یک کتاب کاتلین در عمل خریدم، ما با هم کاتلین را یاد خواهیم گرفت))
• Spring Boot: 2.3.7 - ما کوچکترین نسخه ارائه شده را برای از بین بردن هرگونه مشکل می گیریم. این در حال حاضر یک نسخه کاملاً مدرن از بوت است.

فراداده پروژه:

• گروه: com.github.javarushcommunity - در اینجا دامنه ای را انتخاب می کنیم که گروه مخازن ما روی آن میزبانی می شود.
• مصنوع: javarush-telegrambot - حداکثر توضیحات پروژه.
• نام: Javarush TelegramBot - آن را به طور کامل در اینجا می نویسیم.
• توضیحات: ربات تلگرام برای جاروش از جامعه ای به انجمن دیگر - در اینجا توضیحات دقیق تری از پروژه ارائه شده است.
• نام بسته: com.github.javarushcommunity.jrtb - در اینجا می توانید از یک مخفف برای نام پروژه استفاده کنید. اکنون پروژه با این بسته شروع می شود. چرا اینقدر زیاد؟ به طوری که وقتی پروژه های دیگر را به classpath اضافه می کنیم در پکیج های مختلف قرار بگیرند. هر کدام به روش منحصر به فرد خود. این برای حفظ اصول OOP مهم است.
• بسته بندی: شیشه استاندارد ما است)
• جاوا: 11 - ما یک قدم جلوتر خواهیم بود. فکر نمی‌کنم بعد از جاوا هشتم از نوآوری‌ها استفاده کنم، اما بگذارید باشد. او غذا نمی خواهد)... این تصمیم در آینده یک تخم مرغ کوچک عید پاک به ما می دهد)

فعلاً هیچ وابستگی اضافه نمی کنیم. ما برای این کار به این نیاز نداریم. پس از پر کردن همه اینها، دریافت می کنیم (اینجا پیوندی به پروژه تولید شده است): پس از پر کردن، روی GENERATE کلیک کنید و تمام موارد داخلی موجود در بایگانی را به پروژه خود اضافه کنید. فایل ها را به پروژه اضافه کنید. در نتیجه ما یک برنامه کاربردی داریم. برای بررسی اینکه آیا اصلاً اسمبل شده است یا خیر، به ترمینال بروید و بنویسید: $ mvn clean package اگر همان بسته از اینجا را دارید، همه چیز اوکی است: پروژه مونتاژ شده است و jarnik از قبل در پوشه هدف آماده است. در این مرحله، وظیفه در توضیحات آماده است. ساده است، درست است؟ بنابراین، ما متعهد می شویم و به شاخه خود فشار می دهیم: نام وظیفه خود را در ابتدای توضیحات commit اضافه می کنیم تا بعداً مشخص شود که کار در چارچوب چه کاری انجام شده است. روی Commit and Push کلیک کنید ... یک بار دیگر بررسی می‌کنیم و بررسی می‌کنیم که دقیقاً چه چیزی را می‌خواهیم از مخزن محلی به مخزن راه دور فشار دهیم و با اطمینان از اینکه همه چیز درست است، روی Push کلیک کنید . قدم بعدی ما چیست؟ با توجه به تمام قوانین (که در این مقاله در قسمت مربوط به جریان GitHub قابل مطالعه است)، باید یک درخواست کشش برای شاخه اصلی ایجاد کنید و منتظر باشید تا فردی از تیم کد را بررسی کند. از آنجایی که من تنها هستم، به طور رسمی یک درخواست کشش ایجاد می کنم و همه چیز را دوباره بررسی می کنم. من به صفحه مخزن می روم، و Github از قبل می داند که ما یک افزونه و پیشنهاد برای ایجاد یک درخواست کشش داریم: هیچ مانعی برای میهن پرستان وجود ندارد (ج) - ما آن را همانطور که پیشنهاد شد ایجاد می کنیم. ما همان برچسب را تنظیم می کنیم، پروژه را مانند کاری که روی آن کار می کنیم، انجام می دهیم و توضیحات را تکمیل می کنیم: روی ایجاد درخواست کشش کلیک کنید .

راه اندازی فرآیند CI

ما به درخواست کشش ایجاد شده می رویم: در زیر می بینیم که Continuous Integration پیکربندی نشده است (از این پس - CI). خوب، پیکربندی نشده است، پس چی؟ اصلاً چرا به CI نیاز داریم؟ به هر حال CI چیست؟ این تقریباً فهرست سؤالاتی است که در این لحظه باید ما را نگران کند. به طور کلی، CI یک فرآیند پیوسته از ادغام کد در یک پایه کد مشترک و اجرای یک بیلد از پروژه قبل از آن است. به اصطلاح بیلد (از انگلیسی build). هر بار که پروژه ای را می سازیم، مطمئن می شویم که پروژه کامپایل شده است، تمام تست های آن با موفقیت پشت سر گذاشته شده است، به علاوه پس از ساخت پروژه، می توانید تست های خودکار را از تسترها به CI اضافه کنید که روی این بیلد خاص اجرا می شوند. به این ترتیب، ما بیشتر مطمئن می شویم که تغییرات جدید همانطور که انتظار داریم عمل می کنند و عملکرد قبلی را از بین نمی برند. CI همچنین خوب است زیرا پس از به روز رسانی پایه کد به طور خودکار شروع می شود. یعنی، ما تغییرات خود را وارد شعبه کردیم و فرآیند شروع شد - مونتاژ، آزمایش، تست خودکار و مراحل دیگر. اگر هر یک از این مراحل شکست بخورد، ساخت شکسته در نظر گرفته می شود و نمی توان آن را در شاخه اصلی ادغام کرد. این دقیقاً همان کاری است که اکنون انجام خواهیم داد: اقدامات GitHub را اضافه می کنیم که کد ما را پس از فشار اجرا می کند. GitHub Actions کاملاً با جریان GitHub ما مطابقت دارد، بنابراین ما از آن برای خودکارسازی کار خود استفاده خواهیم کرد. این ابزار بسیار قدرتمند و بزرگ است، اما در حال حاضر فقط از آن برای اجرای ساخت و بررسی مونتاژ آن در صورت نیاز استفاده می کنیم. برای فعال کردن آن، دکمه Actions را در صفحه مخزن پیدا کنید و آن را دنبال کنید: گردش کار Continuous Integration را که نیاز داریم پیدا کنید: روی Set up this workflow کلیک کنید. در مرحله بعد، به ما پیشنهاد می شود از الگوی آنها استفاده کنیم: ما کاملاً موافقیم، بگذارید همه چیز را کمی روشن کنیم:

# 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. هنگامی که یک درخواست کشش در شاخه اصلی ایجاد می شود.

در بخش jobs مراحلی که انجام خواهند شد توضیح داده شده است. ما فقط یک مرحله داریم - ساخت. این نشان می دهد که پروژه ما در اوبونتو با دستور mvn -B package --file pom.xml راه اندازی خواهد شد . این دقیقا همان کاری است که ما به صورت محلی انجام دادیم. اگر می خواهید چیزی را در اینجا تغییر دهید، لطفا. من از این قالب استفاده خواهم کرد، برای من کافی خواهد بود. من روی Start commit کلیک می کنم ، ایجاد یک شاخه جدید را برای پیکربندی فرآیند و سپس Propose new file را انتخاب می کنم . اما روند ساخت سقوط کرد... همانطور که می بینید Failing after 14s - build. به نظر می رسد اتفاقی افتاده است: بیایید به مجلس برویم و به جزئیات نگاه کنیم: می گوید که من نتوانستم چنین خاطره ای پیدا کنم. چرا؟ آهان، دقیقا، دقیقا! چون ما تغییراتی را در شاخه اصلی ایجاد کردیم اما هنوز تکلیف ما آنجا نیست. و به همین دلیل است که او حافظه را پیدا نکرد ... بنابراین، اکنون کارهای زیر را انجام می دهیم: این داده ها را در master ادغام می کنیم، سپس شاخه اصلی را در JRTB-0 ادغام می کنیم، و سپس همه چیز باید خوب پیش برود. در یک درخواست کشش با تغییرات اقدامات github، روی Merge pull request کلیک کنید : و تکرار ادغام را تکرار کنید . در مرحله بعد، Github از ما می خواهد که شاخه ای را که در آن کار می کردیم حذف کنیم. ما رد و حذف نمی کنیم: در مرحله بعد، من در درخواست pull از SpringBoot نحوه برداشتن تغییرات از شاخه اصلی وب سایت را پیدا نکردم، بنابراین ما آن را به صورت دستی از طریق IDEA انجام خواهیم داد.

مرحله 1: شاخه اصلی را به مخزن محلی به روز کنید.

ایده این است که به شاخه اصلی بروید، ctrl + t را فشار دهید و شاخه اصلی را به روز کنید:

مرحله 2: ادغام تغییرات از شاخه اصلی به شاخه JRTB-0.

بیایید به JRTB-0 برویم و اصلی را در آن ادغام کنیم.

مرحله 3: تغییرات را فشار دهید.

ctrl + shift + k را فشار دهید و فشار را تأیید کنید. الان منتظریم بیلد بگذره و سبز بشه!)) ولی بازم قرمزه. چیست؟ وارد لاگ‌های عملیات می‌شویم و می‌بینیم که در نسخه‌های جاوا هماهنگ نیستیم. در GitHubActions 8 است، اما ما از 11 استفاده می کنیم: اکنون دو گزینه وجود دارد: یا اقدامات را تصحیح کنید، یا نسخه را به هشتم کاهش دهید. به نظر من گزینه اول بهتر و صحیح تر است. ما در حال ایجاد تغییرات در یک commit جداگانه هستیم: ما نه با جاوا 8، بلکه با جاوا 11 کار خواهیم کرد. و پس از آن، در نهایت، همه چیز برای ما درست شد، و ما توانستیم فرآیند CI خود را برای پروژه راه اندازی کنیم. چنین چیزهایی باید در مرحله اولیه تنظیم شوند تا بعداً نگران آن نباشید. اکنون می توانید ببینید که ساختن گذشته است و می توانید بدون ترس ادغام شوید:

راه اندازی کار با شاخه ها در مخزن

شما همچنین می توانید چنین مواردی را در مخزن به عنوان قوانین هنگام کار با شاخه ها پیکربندی کنید. من می‌خواهم آن را طوری بسازم که شاخه اصلی را نتوان مستقیماً فشار داد، اما فقط از طریق درخواست‌های کشش، و می‌خواهم آن را طوری بسازم که در صورت شکست ساخت (یعنی اگر GitHub Actions در آن شکست خورد، ادغام یک درخواست pull غیرممکن باشد. چند مرحله). برای انجام این کار، دکمه تنظیمات را پیدا کنید و شعبه ها را انتخاب کنید : در حال حاضر هیچ قانونی برای شاخه ها وجود ندارد، بنابراین بیایید یک قانون جدید را از طریق دکمه افزودن قانون اضافه کنیم : تنظیمات زیادی در اینجا وجود دارد و هرکسی می تواند کاری انجام دهد که مطابق با خودش باشد. نیاز دارد. برای اینکه ساختن در درخواست کشش قبل از ادغام با موفقیت عبور کند، یک چک باکس به Require status checks to pass before ادغام اضافه کنید و وضعیت مورد نیاز خود را انتخاب کنید - build. فعلا همین کافی است: سپس می توانید این فرمان را به روز کنید و ببینید چه چیز دیگری می خواهید. برای ایجاد این فرمان روی Create کلیک کنید . در مرحله بعد، اگر دوباره به درخواست کشش خود برویم، می‌بینیم که اکنون چک ما مورد نیاز است: اجازه دهید صفحه پروژه خود را بررسی کنیم، که تمام وضعیت‌های وظیفه را نشان می‌دهد: بلافاصله می‌توانید ببینید که روی چه کاری در حال کار است. علاوه بر این، کار قبلاً انجام شده است و کار در وضعیت بررسی کد است.

بستن JRTB-0

اکنون که یک درخواست کشش آماده کرده‌ایم و برای آن یک CI ایجاد کرده‌ایم، باید آخرین مرحله را تکمیل کنیم: کار را ببندیم، آن را به وضعیت صحیح منتقل کنیم، به تغییرات پروژه خود در برد نگاه کنیم. درخواست کشش ما برای ادغام در Master آماده است. در درخواست کشش، روی دکمه Merge pull request کلیک کنید : پس از ادغام موفقیت آمیز، می توانید آن را حذف کنید و معمولاً این کار را انجام می دهید. من این کار را انجام نمی دهم تا مشاهده تغییرات بین شاخه ها/تعهدات را برای شما آسانتر کنم. به محض اینکه یک درخواست کشش ادغام شد، به طور خودکار در تابلوی پروژه ما انجام می شود: آخرین مرحله این است که مسئله (مشکل) را با پیوندی به درخواست کشش که در آن بود، ببندیم: این مسئله به طور خودکار در قسمت انجام می شود. هیئت مدیره آغاز ساخته شده است، اولین کار انجام شده است!

نتیجه گیری

به نظر می رسد که ما قبلاً کار و نوشتن کد را شروع کرده ایم، اما تنظیمات هنوز مورد نیاز است. بله، زمان می‌برد، اما وقتی پروژه بزرگ‌تر و پیچیده‌تر شود و شما به تضمین‌هایی نیاز دارید که فقط با یک تعهد همه چیز را از بین نبرید، صد برابر نتیجه خواهد داد. درخواست کشش در جایی که همه این اتفاق می افتد در اینجا موجود است . شاید وقتی می خوانید از قبل بسته شده باشد. ترسناک نیست: تمام اطلاعات لازم از طریق پیوند ذخیره می شود. از همه شما برای خواندن متشکرم، به زودی شما را می بینم. علاوه بر این!

فهرستی از تمام مواد این مجموعه در ابتدای این مقاله است.