ہم ایک پروجیکٹ لکھ رہے ہیں۔ اسپرنگ بوٹ شامل کریں اور ایک CI عمل مرتب کریں - "A سے Z تک جاوا پروجیکٹ"

جاوا پروجیکٹ بنانے کے سلسلے میں ایک مضمون (دیگر مواد کے لنکس آخر میں ہیں)۔ اس کا مقصد کلیدی ٹیکنالوجیز کا تجزیہ کرنا ہے، نتیجہ ٹیلی گرام بوٹ لکھنا ہے۔ سلام، پیارے قارئین۔ جیسا کہ پچھلے حصے میں بیان کیا گیا ہے ، ہم منصوبے کے مطابق جائیں گے۔ ہم پہلے ہی ایک پروجیکٹ بنا چکے ہیں اور اسے کوڈ سے بھرنے کا وقت آگیا ہے۔ اب تمام مسائل کو علیحدہ کمٹ کے طور پر شامل کیا جائے گا۔ میں یہاں ہر وہ چیز بیان کروں گا جو ضروری ہے۔ اگر میں کچھ یاد کرتا ہوں یا اسے کافی واضح طور پر بیان نہیں کرتا ہوں، تبصرے میں پوچھیں، میں جواب دینے کی کوشش کروں گا۔

ہم JRTB-0M لکھتے ہیں۔

اس کام میں ہمیں مستقبل کے کام کے لیے ایک خالی SpringBoot فریم ورک شامل کرنے کی ضرورت ہے۔ ہم اسے اسی طرح کریں گے جیسا کہ ہم نے SpringBoot + Flyway کے مضمون میں کیا تھا ۔ پروجیکٹ ڈاؤن لوڈ کریں ، اسے IDEA میں کھولیں اور JRTB-0 نامی ایک نئی برانچ بنائیں ۔ میں نے یہاں ایک خیال کے ذریعے ایسا کرنے کا طریقہ بیان کیا ۔ اس سے ہمارے لیے مستقبل میں کام کو ٹریک کرنا آسان ہو جائے گا۔ کیا آپ کو پہلے ہی معلوم تھا کہ اب کوئی ماسٹر برانچ نہیں ہے؟ اب اسے neutrally - main کہا جاتا ہے ۔ تو ہم اس کے عادی ہو جاتے ہیں۔ اگرچہ، سچ پوچھیں تو، ہم ہمیشہ اس کا نام بدل کر ماسٹر رکھ سکتے ہیں۔ ہم Spring Initializr پر جاتے ہیں اور اپنے بوٹ کے لیے اسپرنگ بوٹ فریم ورک بناتے ہیں۔ اس وقت، پیش کردہ بوٹ سپرنٹ کا سب سے کم عمر ورژن 2.3.7 ہے، آئیے اسے لیتے ہیں۔ میں مندرجہ ذیل ترتیبات کو الگ سے بیان کروں گا:

• پروجیکٹ: ماون پروجیکٹ - ہم پہلے ہی یہاں اور یہاں ماون پر تبادلہ خیال کر چکے ہیں ۔ اس لیے میں اضافی طور پر صرف وہی بیان کروں گا جو میں نے پچھلے مضامین میں ظاہر نہیں کیا تھا۔ اگر ایسے "سفید دھبے" ہیں تو یقیناً)
• زبان: Java - یہاں سب کچھ واضح ہے۔ اگر کوئی خواہش ہو تو ہم اس معاملے کو کوٹلن میں دوبارہ لکھ سکتے ہیں۔ میں نے ابھی اپنے آپ کو ایک کتاب کوٹلن ان ایکشن خریدی ہے، ہم مل کر کوٹلن سیکھیں گے))
• اسپرنگ بوٹ: 2.3.7 - ہم کسی بھی مسائل کو ختم کرنے کے لیے پیش کردہ سب سے چھوٹا ورژن لیتے ہیں۔ یہ پہلے سے ہی بوٹ کا مکمل طور پر جدید ورژن ہے۔

پروجیکٹ میٹا ڈیٹا:

• گروپ: com.github.javarushcommunity - یہاں ہم وہ ڈومین منتخب کرتے ہیں جس پر ہمارے گروپ آف ریپوزٹریز کی میزبانی کی گئی ہے۔
• آرٹفیکٹ: javarush-telegrambot - پروجیکٹ کی زیادہ سے زیادہ تفصیل۔
• نام: Javarush TelegramBot - ہم اسے یہاں مکمل لکھیں گے۔
• تفصیل: جاورش کے لیے ٹیلیگرام بوٹ کمیونٹی سے کمیونٹی تک - یہاں پراجیکٹ کی مزید تفصیلی وضاحت ہے۔
• پیکیج کا نام: com.github.javarushcommunity.jrtb - یہاں آپ پہلے ہی پروجیکٹ کے نام کے لیے مخفف استعمال کر سکتے ہیں۔ اب اس پیکج سے پراجیکٹ شروع ہوگا۔ اتنے کیوں؟ تاکہ جب ہم کلاس پاتھ میں دوسرے پروجیکٹس کو شامل کریں تو وہ مختلف پیکجز میں ہوں گے۔ ہر ایک اپنے منفرد انداز میں۔ OOP اصولوں کو برقرار رکھنے کے لیے یہ ضروری ہے۔
• پیکیجنگ: جار ہمارا معیار ہے)
• Java: 11 - ہم ایک قدم آگے ہوں گے۔ مجھے نہیں لگتا کہ میں آٹھویں جاوا کے بعد بدعات کا استعمال کروں گا، لیکن اسے رہنے دو۔ وہ کھانا نہیں مانگتا)... یہ فیصلہ ہمیں مستقبل میں ایک چھوٹا ایسٹر انڈا دے گا)

ہم ابھی کے لیے کوئی انحصار شامل نہیں کریں گے۔ ہمیں اس کام کے لیے اس کی ضرورت نہیں ہے۔ یہ سب بھرنے کے بعد، ہمیں ملتا ہے (یہاں تیار کردہ پروجیکٹ کا لنک ہے): پُر کرنے کے بعد، GENERATE پر کلک کریں اور آرکائیو میں موجود تمام انٹرنلز کو ہمارے پروجیکٹ میں شامل کریں۔ پروجیکٹ میں فائلیں شامل کریں۔ نتیجے کے طور پر، ہمارے پاس ایک درخواست ہے۔ یہ چیک کرنے کے لیے کہ آیا یہ بالکل اسمبل ہے یا نہیں، ٹرمینل پر جائیں اور لکھیں: $mvn clean package اگر آپ کے پاس یہاں سے جیسا ہے تو سب کچھ ٹھیک ہے: پروجیکٹ اسمبل ہو گیا ہے، اور jarnik پہلے سے ہی ٹارگٹ فولڈر میں تیار ہے۔ اس وقت، تفصیل کے اندر کام تیار ہے۔ یہ آسان ہے، ٹھیک ہے؟ اس لیے، ہم عہد کرتے ہیں اور اپنی شاخ کو آگے بڑھاتے ہیں: ہم کمٹ کی تفصیل کے شروع میں اپنے کام کا نام شامل کرتے ہیں، تاکہ بعد میں یہ واضح ہو جائے کہ کس کام کے فریم ورک کے اندر کام کیا گیا تھا۔ Commit and Push پر کلک کریں ... ایک بار پھر ہم جائزہ لیتے ہیں اور چیک کرتے ہیں کہ ہم مقامی ریپوزٹری سے دور دراز تک کیا کرنا چاہتے ہیں اور یہ یقینی بناتے ہوئے کہ سب کچھ ٹھیک ہے، Push پر کلک کریں ۔ ہمارا اگلا قدم کیا ہے؟ تمام قواعد کے مطابق (جو اس مضمون میں پڑھا جا سکتا ہے، GitHub بہاؤ کے بارے میں حصہ میں)، آپ کو مین برانچ کے لیے پل کی درخواست بنانے کی ضرورت ہے اور ٹیم میں سے کسی کے کوڈ کا جائزہ لینے کا انتظار کرنا ہوگا۔ چونکہ میں خود ہوں، میں باضابطہ طور پر پل کی درخواست بناؤں گا اور ہر چیز کا دوبارہ جائزہ لوں گا۔ میں ذخیرے کے صفحے پر جاتا ہوں، اور گیتھب پہلے ہی جانتا ہے کہ ہمارے پاس ایک اضافہ ہے اور پل کی درخواست بنانے کی پیشکش کرتا ہے: محب وطن (c) کے لیے کوئی رکاوٹیں نہیں ہیں - ہم اسے تخلیق کرتے ہیں، جیسا کہ تجویز کیا گیا ہے۔ ہم وہی لیبل سیٹ کرتے ہیں، پروجیکٹ جس کام پر ہم کام کر رہے ہیں، اور تفصیل پُر کریں: Create pull request پر کلک کریں ۔

CI عمل کو ترتیب دینا

ہم تخلیق کردہ پل کی درخواست پر جاتے ہیں: ذیل میں ہم دیکھتے ہیں کہ ہمارے پاس کنٹینیوئس انٹیگریشن کنفیگر نہیں ہے (اس کے بعد - CI)۔ ٹھیک ہے، یہ ترتیب نہیں ہے، تو کیا؟ ہمیں CI کی بالکل ضرورت کیوں ہے؟ ویسے بھی CI کیا ہے؟ یہ تقریباً ان سوالات کی فہرست ہے جو اس وقت ہمیں فکر مند ہونا چاہیے۔ عام طور پر، CI کوڈ کو ایک مشترکہ کوڈ بیس میں ضم کرنے اور اس سے پہلے پروجیکٹ کی تعمیر کو چلانے کا ایک مسلسل عمل ہے۔ نام نہاد تعمیر (انگریزی تعمیر سے)۔ جب بھی ہم کوئی پروجیکٹ بناتے ہیں، ہم اس بات کو یقینی بناتے ہیں کہ پروجیکٹ کو مرتب کیا گیا ہے، اس کے تمام ٹیسٹ کامیابی سے گزر چکے ہیں، اس کے علاوہ پروجیکٹ بنانے کے بعد، آپ ٹیسٹرز سے CI میں آٹو ٹیسٹس شامل کرسکتے ہیں جو اس مخصوص بلڈ پر چلائے جاتے ہیں۔ اس طرح، ہم زیادہ پر اعتماد ہو جاتے ہیں کہ نئی تبدیلیاں ہماری توقع کے مطابق کام کرتی ہیں اور پچھلی فعالیت کو نہیں توڑتی ہیں۔ CI بھی اچھا ہے کیونکہ یہ کوڈ بیس کو اپ ڈیٹ کرنے کے بعد خود بخود شروع ہو جاتا ہے۔ یعنی، ہم نے اپنی تبدیلیوں کو برانچ میں دھکیل دیا اور عمل شروع ہوا - اسمبلی، ٹیسٹ، آٹو ٹیسٹ اور دیگر مراحل۔ اگر ان میں سے کوئی بھی مرحلہ ناکام ہو جاتا ہے تو تعمیر کو ٹوٹا ہوا سمجھا جاتا ہے اور اسے مرکزی شاخ میں ضم نہیں کیا جا سکتا۔ یہ بالکل وہی ہے جو ہم اب کریں گے: ہم GitHub ایکشنز کو شامل کریں گے، جو ہمارے کوڈ کو پش کے بعد چلائے گا۔ GitHub ایکشن ہمارے GitHub فلو میں بالکل فٹ بیٹھتا ہے، لہذا ہم اسے اپنے کام کو خودکار بنانے کے لیے استعمال کریں گے۔ یہ ٹول بہت طاقتور اور بڑا ہے، لیکن فی الحال ہم اسے صرف بلڈ کو چلانے کے لیے استعمال کریں گے اور چیک کریں گے کہ یہ ضرورت کے مطابق اسمبل ہے۔ اسے فعال کرنے کے لیے، مخزن کے صفحہ پر ایکشن بٹن تلاش کریں اور اس کی پیروی کریں: مسلسل انٹیگریشن ورک فلو تلاش کریں جس کی ہمیں ضرورت ہے: اس ورک فلو کو سیٹ اپ پر کلک کریں۔ اگلا، ہمیں ان کے سانچے کو استعمال کرنے کی پیشکش کی جاتی ہے: ہم مکمل طور پر متفق ہیں، آئیے ہر چیز کو تھوڑا سا واضح کرتے ہیں:

# 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. جب مین برانچ میں پل کی درخواست بنائی جاتی ہے۔

ملازمتوں کا سیکشن ان اقدامات کی وضاحت کرتا ہے جو انجام دیے جائیں گے۔ ہمارے پاس صرف ایک قدم ہے - تعمیر. یہ ظاہر کرتا ہے کہ ہمارا پروجیکٹ Ubuntu میں mvn -B package --file pom.xml کمانڈ کے ساتھ شروع کیا جائے گا ۔ یہ بالکل وہی ہے جو ہم نے مقامی طور پر کیا۔ اگر آپ یہاں کچھ تبدیل کرنا چاہتے ہیں، تو براہ مہربانی. میں اس سانچے کو استعمال کروں گا، یہ میرے لیے کافی ہوگا۔ میں Start commit پر کلک کرتا ہوں ، عمل کو ترتیب دینے کے لیے ایک نئی برانچ بنائیں کو منتخب کرتا ہوں اور پھر نئی فائل تجویز کرتا ہوں ۔ لیکن تعمیر کا عمل گر گیا... جیسا کہ آپ دیکھ سکتے ہیں، 14 سیکنڈ کے بعد ناکام ہونا - تعمیر۔ ایسا لگتا ہے کہ کچھ ہوا ہے: آئیے اسمبلی میں جائیں اور تفصیلات دیکھیں: یہ کہتا ہے کہ مجھے ایسی یادداشت نہیں مل سکی۔ کیوں؟ آہ، بالکل، بالکل! کیونکہ ہم نے ماسٹر برانچ میں تبدیلیاں کی ہیں، لیکن ہمارا کام ابھی تک نہیں ہے۔ اور اسی لیے اسے میموری نہیں ملی... اس لیے، اب ہم مندرجہ ذیل کام کرتے ہیں: ہم اس ڈیٹا کو ماسٹر میں ضم کرتے ہیں، پھر ہم مرکزی برانچ کو JRTB-0 میں ضم کرتے ہیں، اور پھر سب کچھ ٹھیک ہونا چاہیے۔ گیتھب ایکشنز کی تبدیلیوں کے ساتھ پل کی درخواست میں، ضم کرنے کی درخواست پر کلک کریں : اور دوبارہ Confirm merge کو دہرائیں ۔ اگلا، Github ہمیں اس شاخ کو حذف کرنے کا اشارہ کرتا ہے جس میں ہم نے کام کیا تھا۔ ہم انکار اور حذف نہیں کرتے ہیں: اگلا، مجھے اسپرنگ بوٹ کی طرف سے پل کی درخواست میں یہ نہیں ملا کہ ویب سائٹ سے مین برانچ سے تبدیلیاں کیسے نکالی جائیں، لہذا ہم اسے IDEA کے ذریعے دستی طور پر کریں گے۔

مرحلہ 1: مقامی ریپوزٹری میں ماسٹر برانچ کو اپ ڈیٹ کریں۔

خیال یہ ہے کہ ماسٹر برانچ میں جائیں، ctrl + t دبائیں اور ماسٹر برانچ کو اپ ڈیٹ کریں:

مرحلہ 2: ماسٹر برانچ سے JRTB-0 برانچ میں تبدیلیاں ضم کریں۔

آئیے JRTB-0 پر جائیں اور اس میں مرکزی کو ضم کریں۔

مرحلہ 3: تبدیلیاں دھکیلیں۔

ctrl + shift + k دبائیں اور پش کی تصدیق کریں۔ اب ہم تعمیر کے گزرنے کا انتظار کر رہے ہیں اور یہ سبز ہو جائے گا!)) لیکن یہ دوبارہ سرخ ہے۔ یہ کیا ہے؟ ہم ایکشن لاگز میں جاتے ہیں اور دیکھتے ہیں کہ جاوا ورژن میں ہماری مطابقت پذیری ختم ہو گئی ہے۔ GitHubActions میں یہ 8 ہے، لیکن ہم 11 استعمال کرتے ہیں: اب دو آپشنز ہیں: یا تو اعمال کو درست کریں، یا ورژن کو آٹھویں تک کم کریں۔ پہلا آپشن، مجھے لگتا ہے، بہتر اور زیادہ درست ہے۔ ہم ایک الگ کمٹ میں تبدیلیاں کر رہے ہیں: ہم Java 8 کے ساتھ نہیں بلکہ Java 11 کے ساتھ کام کریں گے۔ اور اس کے بعد، آخر کار، ہمارے لیے سب کچھ کام کر گیا، اور ہم پروجیکٹ کے لیے اپنا CI عمل ترتیب دینے میں کامیاب ہو گئے۔ اس طرح کی چیزوں کو ابتدائی مرحلے میں ترتیب دینے کی ضرورت ہے، تاکہ آپ کو بعد میں اس کے بارے میں پریشان نہ ہونا پڑے۔ اب آپ دیکھ سکتے ہیں کہ تعمیر گزر چکی ہے اور آپ بغیر کسی خوف کے ضم ہو سکتے ہیں:

مخزن میں شاخوں کے ساتھ کام کو ترتیب دینا

شاخوں کے ساتھ کام کرتے وقت آپ ذخیرہ میں ایسی چیزوں کو قواعد کے طور پر بھی ترتیب دے سکتے ہیں۔ میں اسے بنانا چاہتا ہوں تاکہ مین برانچ کو براہ راست نہ دھکیلا جا سکے، لیکن صرف پل کی درخواستوں کے ذریعے، اور میں اسے بنانا چاہتا ہوں تاکہ اگر تعمیر ناکام ہو جائے تو پل کی درخواست کو ضم کرنا ناممکن ہو (یعنی اگر GitHub ایکشنز ناکام ہو جائیں) کچھ قدم)۔ ایسا کرنے کے لیے، سیٹنگز کا بٹن تلاش کریں اور برانچز کو منتخب کریں : اس وقت برانچز کے لیے کوئی اصول نہیں ہیں، تو آئیے ایڈ رول بٹن کے ذریعے ایک نیا شامل کریں : یہاں بہت سی سیٹنگز ہیں، اور ہر کوئی اپنی مرضی کے مطابق کچھ کر سکتا ہے۔ ضروریات ضم کرنے سے پہلے پل کی درخواست میں بلڈ کو کامیابی کے ساتھ پاس کرنے کے لیے، ضم ہونے سے پہلے پاس کرنے کے لیے اسٹیٹس چیک کی ضرورت کے لیے ایک چیک باکس شامل کریں اور ہمیں مطلوبہ اسٹیٹس منتخب کریں۔ ابھی کے لیے اتنا ہی کافی ہے: پھر آپ اس اسٹیئرنگ وہیل کو اپ ڈیٹ کر کے دیکھ سکتے ہیں کہ آپ اور کیا چاہتے ہیں۔ اس اسٹیئرنگ وہیل کو بنانے کے لیے تخلیق پر کلک کریں ۔ اگلا، اگر ہم اپنی پل کی درخواست پر دوبارہ جاتے ہیں، تو ہم دیکھ سکتے ہیں کہ ہمارے چیک کو اب مطلوبہ نشان زد کر دیا گیا ہے: آئیے اپنے پروجیکٹ کا صفحہ چیک کریں، جو تمام ٹاسک سٹیٹس کو دکھاتا ہے: آپ فوری طور پر دیکھ سکتے ہیں کہ کس کام پر کام کیا جا رہا ہے۔ مزید یہ کہ، کام پہلے ہی ہو چکا ہے، اور کام کوڈ کے جائزے کی حالت میں ہے۔

JRTB-0 کو بند کیا جا رہا ہے۔

اب جب کہ ہم نے پل کی درخواست تیار کی ہے اور اس کے لیے ایک CI بنایا ہے، ہمیں آخری مرحلہ مکمل کرنے کی ضرورت ہے: ٹاسک کو بند کریں، اسے درست حالت میں لے جائیں، بورڈ پر ہمارے پروجیکٹ میں ہونے والی تبدیلیوں کو دیکھیں۔ ہماری پل کی درخواست ماسٹر میں ضم ہونے کے لیے تیار ہے۔ پل کی درخواست میں، ضم کرنے کی درخواست کے بٹن پر کلک کریں : کامیاب انضمام کے بعد، آپ اسے حذف کر سکتے ہیں، اور عام طور پر ایسا کرتے ہیں۔ میں یہ اس لیے نہیں کروں گا کہ آپ کے لیے برانچز/کمیٹ کے درمیان تبدیلیاں دیکھنا آسان ہو جائے۔ جیسے ہی پل کی درخواست کو ضم کیا جاتا ہے، یہ ہمارے پروجیکٹ بورڈ میں خود بخود ہو جاتا ہے: آخری مرحلہ مسئلہ (مسئلہ) کو پل کی درخواست کے لنک کے ساتھ بند کرنا ہے جس میں یہ تھا: یہ مسئلہ خود بخود ہو جاتا ہے۔ بورڈ آغاز ہو گیا، پہلا کام ہو گیا!

نتائج

ایسا لگتا ہے کہ ہم نے پہلے ہی کام کرنا اور کوڈ لکھنا شروع کر دیا ہے، لیکن ابھی بھی سیٹنگز کی ضرورت ہے۔ ہاں، اس میں وقت لگتا ہے، لیکن جب پروجیکٹ بڑا اور پیچیدہ ہو جائے گا تو یہ سو گنا ادا کرے گا اور آپ کو اس بات کی گارنٹی درکار ہے کہ آپ صرف ایک عہد سے ہر چیز کو نہیں توڑیں گے۔ پل کی درخواست جہاں یہ سب ہوتا ہے یہاں دستیاب ہے ۔ شاید، جب آپ پڑھتے ہیں، یہ پہلے سے ہی بند ہو جائے گا. یہ خوفناک نہیں ہے: تمام ضروری معلومات لنک کے ذریعے محفوظ کی جائیں گی۔ پڑھنے کے لیے آپ سب کا شکریہ، جلد ملتے ہیں۔ مزید مزید!

سیریز کے تمام مواد کی فہرست اس مضمون کے شروع میں ہے۔