مسلسل ڈلیوری ٹیوٹوریل۔ جینکنز کا استعمال کرتے ہوئے مسلسل ڈلیوری پائپ لائن بنانا



مسلسل ڈلیوری پر یہ بلاگ اس میں شامل ہر ایک مرحلے کی وضاحت کرے گا جیسے جینکنز کو استعمال کرتے ہوئے بینڈ ، ٹیسٹ وغیرہ۔

مسلسل ترسیل:

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

  • مسلسل ترسیل کیا ہے؟
  • سافٹ ویئر ٹیسٹنگ کی اقسام
  • مسلسل انضمام ، فراہمی ، اور تعیناتی کے درمیان فرق
  • مسلسل فراہمی کی کیا ضرورت ہے؟
  • جینکنز اور ٹام کیٹ کا استعمال کرتے ہوئے ہاتھ

آئیے جلدی سے سمجھیں کہ ڈلیوری کس طرح کام کرتی ہے۔





مسلسل ترسیل کیا ہے؟

یہ ایک ایسا عمل ہے جہاں آپ سافٹ ویئر کی تشکیل اس طرح کرتے ہیں کہ اسے کسی بھی وقت پیداوار میں جاری کیا جاسکتا ہے۔ذیل میں ملاحظہ کریں:

مسلسل ترسیل۔ مسلسل فراہمی - ایڈورکا



میں مذکورہ آریگرام کی وضاحت کرتا ہوں:

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

اس سے پہلے کہ میں آگے بڑھوں ، یہ صرف منصفانہ ہوگا میں آپ کو مختلف قسم کی جانچ کی وضاحت کرتا ہوں۔

سافٹ ویئر ٹیسٹنگ کی اقسام:

وسیع پیمانے پر بولنے کی جانچ دو طرح کی ہے۔



  • بلیک باکس ٹیسٹنگ: یہ ایک جانچ کی تکنیک ہے جو نظام کے داخلی میکانزم کو نظر انداز کرتی ہے اور سسٹم کے کسی بھی ان پٹ اور عملدرآمد کے خلاف پیدا ہونے والی پیداوار پر توجہ مرکوز کرتی ہے۔ اسے فنکشنل ٹیسٹنگ بھی کہا جاتا ہے۔ یہ بنیادی طور پر سافٹ ویئر کی توثیق کے لئے استعمال کیا جاتا ہے۔
  • وائٹ باکس ٹیسٹنگ: ایک آزمائشی تکنیک ہے جو کسی سسٹم کے اندرونی طریقہ کار کو مدنظر رکھتی ہے۔ اسے ساختی ٹیسٹنگ اور گلاس باکس ٹیسٹنگ بھی کہا جاتا ہے۔ یہ بنیادی طور پر سافٹ ویئر کی تصدیق کے لئے استعمال ہوتا ہے۔

وائٹ باکس ٹیسٹنگ:

جانچ کی دو قسمیں ہیں ، جو اس زمرے میں آتی ہیں۔

  • یونٹ ٹیسٹنگ: یہ کسی انفرادی اکائی یا متعلقہ یونٹوں کے گروپ کی جانچ ہے۔ پروگرامر کے ذریعہ یہ جانچ کرنے کے لئے اکثر ایسا کیا جاتا ہے کہ وہ جس اکائی کو نافذ کرتا ہے وہ دیئے گئے ان پٹ کے خلاف متوقع پیداوار تیار کرتا ہے۔
  • انضمام کی جانچ: یہ ایک قسم کی آزمائش ہے جس میں اجزاء کا ایک گروپ ہوتا ہےپیداوار پیدا کرنے کے لئے مشترکہ. نیز ، اگر سافٹ ویئر اور ہارڈ ویئر کے اجزاء کا کوئی رشتہ ہے تو سافٹ ویئر اور ہارڈ ویئر کے مابین تعامل کی جانچ کی جاتی ہے۔ یہ وائٹ باکس ٹیسٹنگ اور بلیک باکس ٹیسٹنگ دونوں میں آسکتا ہے۔

بلیک باکس ٹیسٹنگ:

اس زمرے میں آنے والے متعدد ٹیسٹ ہیں۔ میں اس پر توجہ دوں گاکچھ، جو آپ کے لئے جاننا ضروری ہے ، اس بلاگ کو سمجھنے کے ل important:

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

اب میرے لئے مستقل انضمام ، فراہمی اور تعیناتی کے درمیان فرق کی وضاحت کرنے کا صحیح وقت ہے۔

مسلسل انضمام ، فراہمی اور تعیناتی کے درمیان اختلافات:

متنی معلومات کے مقابلے میں تیز اور زیادہ قابل فہم انداز میں بصری مواد ایک فرد کے دماغ تک پہنچ جاتا ہے۔ لہذا میں ایک آریھ کے ساتھ شروع کرنے جا رہا ہوں جو واضح طور پر فرق کی وضاحت کرتا ہے:

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

نزاکت میں سیاق و سباق کے فلٹرز کیا ہیں؟

مسلسل فراہمی میں ، درخواست UAT کے ٹیسٹ سرورز پر مستقل طور پر تعینات کی جاتی ہے۔ یا ، آپ کہہ سکتے ہیں کہ درخواست کسی بھی وقت پیداوار میں جاری کرنے کے لئے تیار ہے۔ لہذا ، واضح طور پر مسلسل فراہمی کے لئے مسلسل انضمام ضروری ہے۔

لگاتار تعی pastن لگاتار فراہمی کا اگلا مرحلہ ہے ، جہاں آپ صرف قابل تعی .ن پیکیج نہیں بنا رہے ہیں ، بلکہ آپ اسے خود کار طریقے سے تعینات کررہے ہیں۔

میں ایک ٹیبل کا استعمال کرتے ہوئے اختلافات کا خلاصہ بیان کرتا ہوں:

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

آسان الفاظ میں ، مسلسل انضمام لگاتار فراہمی اور لگاتار تعیناتی دونوں کا ایک حصہ ہے۔ اور لگاتار تعیناتی لگاتار فراہمی کی طرح ہے ، سوائے اس کے کہ یہ خود بخود ریلیز ہوجائیں۔

جینکنز کو بادل پر استعمال کرتے ہوئے سی آئی / سی ڈی پائپ لائنز بنانے کا طریقہ سیکھیں

لیکن سوال یہ ہے کہ ، کیا مسلسل انضمام کافی ہے؟

ہمیں مسلسل ترسیل کی ضرورت کیوں ہے؟

آئیے ہم اسے ایک مثال سے سمجھتے ہیں۔

ذرا تصور کریں کہ ایک بڑے پروجیکٹ پر 80 ڈویلپر کام کر رہے ہیں۔ وہ خودکار تعمیرات کی سہولت کے ل Contin مستقل انضمام پائپ لائنوں کا استعمال کررہے ہیں۔ ہم جانتے ہیں کہ تعمیر میں یونٹ ٹیسٹنگ بھی شامل ہے۔ ایک دن انہوں نے جدید عمارت کی تعی toن کرنے کا فیصلہ کیا جس نے یونٹ ٹیسٹ کو ایک ٹیسٹ ماحول میں پاس کیا تھا۔

یہ تعی toن کے ل but ایک طویل لیکن کنٹرول نقطہ نظر ہونا چاہئے جو ان کے ماحولیاتی ماہرین نے انجام دیا۔ تاہم ، ایسا لگتا ہے کہ نظام کام نہیں کرتا ہے۔

ناکامی کی واضح وجہ کیا ہوسکتی ہے؟

ٹھیک ہے ، پہلی وجہ جو زیادہ تر لوگ سوچیں گے وہ یہ ہے کہ تشکیل میں کچھ پریشانی ہے۔ زیادہ تر لوگوں کی طرح یہاں تک کہ انھوں نے بھی ایسا ہی سوچا تھا۔انہوں نے ماحولیات کی تشکیل میں کیا غلط ہے اسے تلاش کرنے میں کافی وقت صرف کیا ، لیکن انہیں مسئلہ نہیں مل سکا۔

ایک سمجھنے والے ڈویلپر نے زبردست انداز اختیار کیا:

تب ایک سینئر ڈویلپر نے اپنی ترقیاتی مشین پر درخواست آزمائی۔ یہ وہاں کام نہیں کرتا تھا۔

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

مسئلہ یہ بیان:

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

میں مندرجہ بالا مسائل کو دیکھ کر سیکھے گئے اسباق کا خلاصہ بیان کرتا ہوں:

  • یونٹ ٹیسٹ ہی کسی مسئلے کے حل کے بارے میں کسی ڈویلپر کے نقطہ نظر کی جانچ کرتا ہے۔ ان کے پاس یہ ثابت کرنے کی صرف محدود صلاحیت ہے کہ یہ اطلاق صارف کے نقطہ نظر سے وہی کرتا ہے جو اسے سمجھا جاتا ہے۔ وہ کافی نہیں ہیںحقیقی عملی مسائل کی نشاندہی کریں۔
  • ٹیسٹ کے ماحول پر درخواست کی فراہمی ایک پیچیدہ ، دستی طور پر انتہائی عمل ہے جو کافی حد تک غلطی کا شکار تھا۔اس کا مطلب یہ تھا کہ تعیناتی کی ہر کوشش ایک نیا تجربہ تھا - ایک دستی ، غلطی کا شکار عمل۔

حل - مسلسل ترسیل کی پائپ لائن (خودکار قبولیت ٹیسٹ):

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

بنیادی طور پر ، انہوں نے ایک مستقل فراہمی پائپ لائن بنائی ، تاکہ یہ یقینی بنایا جا سکے کہ ایپلی کیشن بغیر کسی رکاوٹ کے پیداواری ماحول پر متعین کی جا رہی ہے ، اس بات کو یقینی بناتے ہوئے کہ جب درخواست ٹیسٹ سرور پر تعینات ہوتی ہے تو جو پروڈکشن سرور کی نقل ہے۔

کافی حد تک نظریہ ، میں اب آپ کو دکھاؤں گا کہ جینکنز کو استعمال کرتے ہوئے مسلسل ڈلیوری پائپ لائن کیسے بنائی جائے۔

جینکنز کا استعمال کرتے ہوئے مسلسل فراہمی کی پائپ لائن:

یہاں میں جینکنز کو مستقل فراہمی پائپ لائن بنانے کے لئے استعمال کروں گا ، جس میں مندرجہ ذیل کام شامل ہوں گے:

ڈیمو میں شامل اقدامات:

  • گٹ ہب سے کوڈ بازیافت کرنا
  • ماخذ کوڈ مرتب کرنا
  • یونٹ کی جانچ اور JUnit ٹیسٹ کی رپورٹیں تیار کرنا
  • ایپلی کیشن کو WAR فائل میں پیکیج کرنا اور اسے ٹامکیٹ سرور پر لگا دینا

پیشگی شرائط:

  • سینٹوس 7 مشین
  • جینکنز 2.121.1
  • ڈاکر
  • ٹامکیٹ 7

مرحلہ - 1 ماخذ کوڈ مرتب کرنا:

آئیے سب سے پہلے جینکنز میں فری اسٹائل پروجیکٹ بنا کر شروع کریں۔ ذیل میں اسکرین شاٹ پر غور کریں:

اپنے پروجیکٹ کو ایک نام دیں اور فری اسٹائل پروجیکٹ کو منتخب کریں:

جب آپ نیچے جائیں گے تو آپ کو ماخذ کوڈ ذخیرہ شامل کرنے کا آپشن ملے گا ، گٹ کو منتخب کریں اور مخزن URL کو شامل کریں ، اس مخزن میں ایک pom.xML ٹھیک ہے جسے ہم اپنے پروجیکٹ کی تعمیر کے لئے استعمال کریں گے۔ ذیل میں اسکرین شاٹ پر غور کریں:

اب ہم ایک بلڈ ٹرگر شامل کریں گے۔ پول میں ایس سی ایم کا اختیار منتخب کریں ، بنیادی طور پر ، ہم کوڈ میں تبدیلی کے ل every ہر 5 منٹ کے بعد گیٹ ہب ریپوزٹری میں پولنگ کیلئے جینکنز کو تشکیل دیں گے۔ ذیل میں اسکرین شاٹ پر غور کریں:

اس سے پہلے کہ میں آگے بڑھوں ، میں آپ کو ماون بلڈ سائیکل کا ایک چھوٹا تعارف پیش کرتا ہوں۔

ہر ایک بلڈ لائف سائکل کی وضاحت بلڈ مرحلوں کی ایک مختلف فہرست سے ہوتی ہے ، جس میں ایک تعمیر کا مرحلہ زندگی کے دور میں ایک مرحلے کی نمائندگی کرتا ہے۔

تعمیراتی مراحل کی فہرست مندرجہ ذیل ہے۔

  • تصدیق - پراجیکٹ کو درست کرنا صحیح ہے اور تمام ضروری معلومات دستیاب ہیں
  • مرتب کریں - منصوبے کا ماخذ کوڈ مرتب کریں
  • ٹیسٹ - مناسب یونٹ ٹیسٹنگ فریم ورک کا استعمال کرتے ہوئے مرتب کردہ ماخذ کوڈ کی جانچ کریں۔ ان ٹیسٹوں میں کوڈ کو پیک یا تعینات کرنے کی ضرورت نہیں ہونی چاہئے
  • پیکیج - مرتب شدہ کوڈ لیں اور اسے اس کی تقسیم کی شکل میں پیکیج کریں ، جیسے JAR۔
  • تصدیق کریں - معیار کے معیار پر پورا اترنے کو یقینی بنانے کے لئے انضمام کے امتحانات کے نتائج پر کسی بھی طرح کی جانچ پڑتال کریں
  • انسٹال کریں - مقامی ذخیرے میں پیکیج کو انسٹال کریں ، جو مقامی طور پر دوسرے پروجیکٹس میں انحصار کی حیثیت سے استعمال کریں
  • تعی --ن کریں - تعمیر ماحول میں کیا ، حتمی پیکیج کو دوسرے ڈویلپرز اور پروجیکٹس کے ساتھ اشتراک کے لئے دور دراز کے ذخیرے میں نقل کریں۔

سورس کوڈ مرتب کرنے ، یونٹ کی جانچ اور یہاں تک کہ جنگ کی فائل میں درخواست کو پیکج کرنے کے لئے ، میں ذیل میں کمانڈ چلا سکتا ہوں:

mvn صاف پیکیج

آپ اپنی تعمیر نوکری کو بہت سے تعمیراتی مراحل میں توڑ سکتے ہیں۔ اس سے بلڈز کو صاف ، علیحدہ مراحل میں منظم کرنا آسان ہوجاتا ہے۔

تو ہم ماخذ کوڈ مرتب کرکے شروع کریں گے۔ بلڈ ٹیب میں ، انوائس ٹاپ لیول میون اہداف پر کلک کریں اور نیچے کمانڈ ٹائپ کریں:

مرتب کرنا

ذیل میں اسکرین شاٹ پر غور کریں:

یہ گیٹ ہب ذخیر. سے سورس کوڈ کھینچ لے گا اور اسے (ماون کمپائل فیز) مرتب کرے گا۔

پروجیکٹ کو محفوظ کریں اور چلانے پر کلک کریں۔

اب ، نتیجہ دیکھنے کے لئے کنسول آؤٹ پٹ پر کلک کریں۔

مرحلہ - 2 یونٹ ٹیسٹنگ:

اب ہم یونٹ ٹیسٹنگ کے لئے ایک اور فری اسٹائل پروجیکٹ بنائیں گے۔

ماخذ کوڈ مینجمنٹ ٹیب میں وہی ذخیرہ یو آر ایل شامل کریں ، جیسا کہ ہم نے پچھلے کام میں کیا تھا۔

اب ، 'بِیڈ ٹرگر' کے ٹیب میں 'دوسرے منصوبوں کے تعمیر کے بعد تعمیر' پر کلک کریں۔ وہاں پچھلے پروجیکٹ کا نام ٹائپ کریں جہاں ہم سورس کوڈ مرتب کررہے ہیں ، اور آپ مندرجہ ذیل اختیارات میں سے کسی کو منتخب کرسکتے ہیں:

  • محرک صرف اس صورت میں جب تعمیر مستحکم ہو
  • ٹرگر چاہے تعمیر غیر مستحکم ہو
  • ٹرگر یہاں تک کہ اگر عمارت ناکام ہوجاتی ہے

میرے خیال میں مذکورہ بالا اختیارات کافی خوبیوں سے آگاہ ہیں لہذا ، کوئی بھی انتخاب کریں۔ ذیل میں اسکرین شاٹ پر غور کریں:

بلڈ ٹیب میں ، انوائس ٹاپ لیول میون اہداف پر کلک کریں اور نیچے کمانڈ استعمال کریں:

پرکھ

جینکنز بھی آپ کو اپنے ٹیسٹ کے نتائج اور ٹیسٹ کے نتائج کے رجحانات کو ظاہر کرنے میں مدد کرنے کا ایک بہت بڑا کام کرتی ہے۔

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

لہذا ہمیں اگلی چیز کرنے کی ضرورت جینکنز کو اپنے یونٹ ٹیسٹوں پر ٹیب رکھنے کے ل get حاصل کرنا ہے۔

پوسٹ بلٹ ایکشنس سیکشن پر جائیں اور 'شائع کریں یونٹ ٹیسٹ کے نتائج کی رپورٹ شائع کریں' چیک باکس پر نشان لگائیں۔ جب ماوین کسی پروجیکٹ میں یونٹ ٹیسٹ چلاتا ہے تو ، یہ خود بخود XML ٹیسٹ کی رپورٹس ڈائرکٹری میں تیار کرتا ہے جسے نامعلوم افراد کی اطلاع دی جاتی ہے. لہذا 'ٹیسٹ رپورٹ XMLs' فیلڈ میں '** / اہداف / یقینی فائر رپورٹیں / *. xML' درج کریں۔ راستے کے آغاز میں دو ستارے ('**') ترتیب کو کچھ زیادہ مضبوط بنانے کا ایک بہترین عمل ہے: وہ جینکنز کو ہدف ڈائرکٹری تلاش کرنے کی اجازت دیتے ہیں اس سے کوئی فرق نہیں پڑتا ہے کہ ہم نے جینکنز کو کس طرح تشکیل دیا ہے ماخذ کوڈ کو چیک کریں۔

** / ہدف / یقینی فائر رپورٹیں / *. xML

اسے دوبارہ سے محفوظ کریں اور بلٹ اب پر کلک کریں۔

اب ، JUnit رپورٹ کو / var / lib / jenkins / workpace / test / gameof Life-core / اہداف / یقین دہندگی کی رپورٹوں / ٹیسٹ طرز عمل پر لکھا گیا ہے۔

جینکنز ڈیش بورڈ میںآپ ٹیسٹ کے نتائج بھی دیکھ سکتے ہیں:

مرحلہ - 3 ایک WAR فائل بنانا اور ٹومکیٹ سرور پر تعی :ن کرنا:

اب ، اگلا مرحلہ یہ ہے کہ ہماری درخواست کو WAR فائل میں پیکیج کیا جائے اور اسے صارف قبولیت ٹیسٹ کے لئے ٹامکیٹ سرور پر لگایا جائے۔

ایک اور فری اسٹائل پروجیکٹ بنائیں اور ماخذ کوڈ ذخیرہ کرنے والا URL شامل کریں۔

اس کے بعد بلٹ ٹرگر ٹیب میں ، جب دوسرے پروجیکٹس بنائے جائیں گے تب بلڈ کو منتخب کریں ، مندرجہ ذیل اسکرین شاٹ پر غور کریں:

بنیادی طور پر ، ٹیسٹ نوکری کے بعد ، تعی phaseن کا مرحلہ خودبخود شروع ہوگا۔

بلڈ ٹیب میں ، شیل اسکرپٹ منتخب کریں۔ WAR فائل میں ایپلیکیشن کو پیکیج کرنے کے لئے ذیل میں کمانڈ ٹائپ کریں:

mvn پیکیج

اگلا مرحلہ یہ ہے کہ اس جنگ فائل کو ٹام کیکیٹ پر رکھا جائےسرور. 'پوسٹ بلڈ ایکشنز' ٹیب میں کسی کنٹینر میں وار / کان لگائیں۔ یہاں ، جنگ کی فائل کو راستہ دیں اور سیاق و سباق کا راستہ دیں۔ ذیل میں اسکرین شاٹ پر غور کریں:

ٹامکیٹ کی اسناد منتخب کریں اور ، مندرجہ بالا اسکرین شاٹ دیکھیں۔ اس کے علاوہ ، آپ کو اپنے ٹامکیٹ سرور کا URL دینے کی ضرورت ہے۔

جینکنز میں سندیں شامل کرنے کے لئے ، جینکنز ڈیش بورڈ پر موجود اسناد کے آپشن پر کلک کریں۔

سسٹم پر کلک کریں اور عالمی اسناد منتخب کریں۔

تب آپ کو اسناد شامل کرنے کا آپشن مل جائے گا۔ اس پر کلک کریں اور اسناد شامل کریں۔

ٹامکیٹ کی اسناد شامل کریں ، ذیل میں اسکرین شاٹ پر غور کریں۔

اوکے پر کلک کریں۔

اب اپنی پروجیکٹ کی تشکیل میں ، ٹامکاٹ کی سندیں شامل کریں جو آپ نے پچھلے مرحلے میں داخل کی ہیں۔

سییو پر کلک کریں اور پھر بل Buildوب کو منتخب کریں۔

اپنے ٹومکاٹ یو آر ایل پر جائیں ، سیاق و سباق کے ساتھ ، میرے معاملے میں یہ HTTP: // لوکل ہوسٹ: 8081 ہے۔ اب آخر میں سیاق و سباق کو شامل کریں ، ذیل میں اسکرین شاٹ پر غور کریں:

لنک - HTTP: // لوکل ہوسٹ: 8081 / gof

مجھے امید ہے کہ آپ سیاق و سباق کے معنی کو سمجھ گئے ہوں گے۔

اب ایک پائپ لائن منظر بنائیں ، ذیل میں اسکرین شاٹ پر غور کریں:

نیا نظریہ بنانے کے لئے ، پلس آئیکن پر کلک کریں۔

جس طرح سے آپ چاہتے ہیں پائپ لائن کی تشکیل کریں ، ذیل کے اسکرین شاٹ پر غور کریں:

میں نے ابتدائی ملازمت کے انتخاب کے علاوہ کچھ نہیں بدلا۔ تو میری پائپ لائن مرتب سے شروع ہوگی۔ مرتب کی جانچ اور تعیناتی کے بعد ، میں نے دوسری ملازمتوں کو کنفیگر کیا ہے اس کی بنیاد پر۔

آخر میں ، آپ پائپ لائن کو رن پر کلک کرکے جانچ سکتے ہیں۔ ہر پانچ منٹ کے بعد ، اگر سورس کوڈ میں کوئی تبدیلی آتی ہے تو ، پوری پائپ لائن کو عملی جامہ پہنایا جائے گا۔

لہذا ہم صارف درخواست قبولیت ٹیسٹ (UAT) کے ل server جانچ سرور پر اپنی درخواست مستقل طور پر تعینات کرنے کے اہل ہیں۔

مجھے امید ہے کہ آپ کو مسلسل ڈلیوری پر اس پوسٹ کو پڑھ کر مزا آیا ہوگا۔ اگر آپ کو کوئی شبہ ہے تو ، بلا جھجھک انھیں نیچے تبصرہ سیکشن میں ڈالیں اور میں جلد سے جلد ہی جواب کے ساتھ واپس آؤں گا۔

سی آئی / سی ڈی پائپ لائنوں کی تعمیر کے ل You آپ کو مختلف صلاحیتوں میں مہارت حاصل کرنے کی ضرورت ہے اب مطلوبہ ڈی او اوپس ہنر کو ماسٹر کریں