حصہ 1: ویب/اینڈرائیڈ
نوٹ: یہ مضمون اصل مضمون کا روسی میں ترجمہ ہے۔ تاہم، تمام عکاسی، لنکس، اقتباسات اور اصطلاحات کو اصل زبان میں محفوظ کیا جاتا ہے تاکہ روسی زبان میں ترجمہ ہونے پر معنی کی تحریف سے بچا جا سکے۔ میری خواہش ہے کہ آپ پڑھائی میں خوش رہیں!
فی الحال، DevOps کی خصوصیت IT انڈسٹری میں سب سے زیادہ مانگ میں سے ایک ہے۔ اگر آپ نوکری کی تلاش کی مقبول سائٹیں کھولتے ہیں اور تنخواہ کے لحاظ سے فلٹر کرتے ہیں، تو آپ دیکھیں گے کہ DevOps سے متعلقہ جابز فہرست میں سب سے اوپر ہیں۔ تاہم، یہ سمجھنا ضروری ہے کہ یہ بنیادی طور پر 'سینئر' پوزیشن سے مراد ہے، جس کا مطلب ہے کہ امیدوار کے پاس اعلیٰ سطح کی مہارت، ٹیکنالوجی اور آلات کا علم ہے۔ یہ پیداوار کے بلاتعطل آپریشن سے وابستہ اعلیٰ ذمہ داری کے ساتھ بھی آتا ہے۔ تاہم، ہم بھولنے لگے کہ DevOps کیا ہے۔ شروع میں یہ کوئی مخصوص شخص یا شعبہ نہیں تھا۔ اگر ہم اس اصطلاح کی تعریفیں تلاش کریں تو ہمیں بہت سے خوبصورت اور درست اسم ملیں گے، جیسے طریقہ کار، طرز عمل، ثقافتی فلسفہ، تصورات کا گروپ وغیرہ۔
میری تخصص ایک ٹیسٹ آٹومیشن انجینئر (QA آٹومیشن انجینئر) ہے، لیکن میں سمجھتا ہوں کہ اسے صرف آٹو ٹیسٹ لکھنے یا ٹیسٹ فریم ورک آرکیٹیکچر تیار کرنے سے منسلک نہیں ہونا چاہیے۔ 2020 میں، آٹومیشن انفراسٹرکچر کا علم بھی ضروری ہے۔ یہ آپ کو خود کار طریقے سے خود کار طریقے سے ترتیب دینے کی اجازت دیتا ہے، ٹیسٹ چلانے سے لے کر تمام اسٹیک ہولڈرز کو آپ کے اہداف کے مطابق نتائج فراہم کرنے تک۔ نتیجے کے طور پر، کام کرنے کے لیے DevOps کی مہارتیں ضروری ہیں۔ اور یہ سب اچھا ہے، لیکن، بدقسمتی سے، ایک مسئلہ ہے (spoiler: یہ مضمون اس مسئلے کو آسان بنانے کی کوشش کرتا ہے۔)۔ بات یہ ہے کہ DevOps مشکل ہے۔ اور یہ واضح ہے، کیونکہ کمپنیاں کسی ایسی چیز کے لیے بہت زیادہ ادائیگی نہیں کریں گی جو کرنا آسان ہے... DevOps کی دنیا میں، بڑی تعداد میں ٹولز، شرائط اور مشقیں ہیں جن میں مہارت حاصل کرنے کی ضرورت ہے۔ کیریئر کے آغاز میں یہ خاص طور پر مشکل ہوتا ہے اور اس کا انحصار جمع شدہ تکنیکی تجربے پر ہوتا ہے۔
ماخذ:
یہاں ہم ممکنہ طور پر تعارفی حصہ ختم کریں گے اور اس مضمون کے مقصد پر توجہ مرکوز کریں گے۔
یہ مضمون کس بارے میں ہے؟
اس آرٹیکل میں، میں ٹیسٹ آٹومیشن انفراسٹرکچر بنانے کے اپنے تجربے کا اشتراک کرنے جا رہا ہوں۔ انٹرنیٹ پر مختلف ٹولز اور ان کے استعمال کے بارے میں معلومات کے بہت سے ذرائع موجود ہیں، لیکن میں ان کو خالصتاً آٹومیشن کے تناظر میں دیکھنا چاہوں گا۔ مجھے یقین ہے کہ بہت سے آٹومیشن انجینئر اس صورتحال سے واقف ہیں جب آپ کے علاوہ کوئی بھی ترقی یافتہ ٹیسٹ نہیں چلاتا یا ان کو برقرار رکھنے کی پرواہ نہیں کرتا۔ نتیجے کے طور پر، ٹیسٹ پرانے ہو جاتے ہیں اور آپ کو ان کو اپ ڈیٹ کرنے میں وقت گزارنا پڑتا ہے۔ ایک بار پھر، کیریئر کے آغاز میں، یہ کافی مشکل کام ہو سکتا ہے: دانشمندی سے یہ فیصلہ کرنا کہ کون سے ٹولز دیے گئے مسئلے کو ختم کرنے میں مدد کریں، انہیں کیسے منتخب، ترتیب اور برقرار رکھا جائے۔ کچھ ٹیسٹرز مدد کے لیے DevOps (انسانوں) سے رجوع کرتے ہیں اور آئیے ایماندار بنیں، یہ طریقہ کارگر ہے۔ بہت سے معاملات میں یہ واحد آپشن ہو سکتا ہے کیونکہ ہمارے پاس تمام انحصارات میں مرئیت نہیں ہے۔ لیکن جیسا کہ ہم جانتے ہیں، DevOps بہت مصروف لوگ ہیں، کیونکہ انہیں تنظیم/ٹیم کے لحاظ سے کمپنی کے پورے انفراسٹرکچر، تعیناتی، نگرانی، مائیکرو سروسز اور اسی طرح کے دیگر کاموں کے بارے میں سوچنا پڑتا ہے۔ جیسا کہ عام طور پر ہوتا ہے، آٹومیشن ترجیح نہیں ہے۔ ایسے میں ہمیں شروع سے آخر تک اپنی طرف سے ہر ممکن کوشش کرنی چاہیے۔ یہ انحصار کو کم کرے گا، کام کے بہاؤ کو تیز کرے گا، ہماری مہارتوں کو بہتر بنائے گا اور ہمیں کیا ہو رہا ہے اس کی بڑی تصویر دیکھنے کی اجازت دے گا۔
مضمون سب سے زیادہ مقبول اور مقبول ٹولز پیش کرتا ہے اور یہ بتاتا ہے کہ قدم بہ قدم آٹومیشن انفراسٹرکچر بنانے کے لیے ان کا استعمال کیسے کیا جائے۔ ہر گروپ کی نمائندگی ایسے ٹولز کے ذریعے کی جاتی ہے جن کا ذاتی تجربہ کے ذریعے تجربہ کیا گیا ہے۔ لیکن اس کا مطلب یہ نہیں ہے کہ آپ کو ایک ہی چیز استعمال کرنی ہوگی۔ اوزار خود اہم نہیں ہیں، وہ ظاہر ہوتے ہیں اور متروک ہوجاتے ہیں۔ ہمارا انجینئرنگ کا کام بنیادی اصولوں کو سمجھنا ہے: ہمیں ٹولز کے اس گروپ کی ضرورت کیوں ہے اور ہم ان کی مدد سے کام کے کون سے مسائل حل کر سکتے ہیں۔ اس لیے ہر سیکشن کے آخر میں میں اسی طرح کے ٹولز کے لنکس چھوڑتا ہوں جو آپ کی تنظیم میں استعمال ہو سکتے ہیں۔
اس مضمون میں کیا نہیں ہے۔
میں ایک بار پھر دہراتا ہوں کہ مضمون مخصوص ٹولز کے بارے میں نہیں ہے، اس لیے مخصوص کمانڈز کی دستاویزات اور تفصیل سے کوڈ کا کوئی اندراج نہیں ہوگا۔ لیکن ہر حصے کے آخر میں تفصیلی مطالعہ کے لیے لنکس چھوڑتا ہوں۔
یہ کیا جاتا ہے کیونکہ:
- یہ مواد مختلف ذرائع سے تلاش کرنا بہت آسان ہے (دستاویزات، کتابیں، ویڈیو کورسز)؛
- اگر ہم گہرائی میں جانا شروع کریں تو ہمیں اس مضمون کے 10، 20، 30 حصے لکھنے ہوں گے (جبکہ منصوبے 2-3 ہیں)؛
- میں صرف آپ کا وقت ضائع نہیں کرنا چاہتا کیونکہ آپ انہی مقاصد کو حاصل کرنے کے لیے دوسرے ٹولز استعمال کرنا چاہتے ہیں۔
پریکٹس
میں واقعی یہ چاہوں گا کہ یہ مواد ہر قاری کے لیے مفید ہو، نہ کہ صرف پڑھا اور بھول جائے۔ کسی بھی مطالعہ میں، مشق ایک بہت اہم جز ہے۔ اس کے لیے میں نے تیاری کر رکھی ہے۔. اس بات کو یقینی بنانے کے لیے آپ کے لیے ہوم ورک بھی انتظار کر رہا ہے کہ آپ ان کمانڈز کی لائنوں کی نقل نہ کریں جن پر آپ عمل کر رہے ہیں۔
منصوبہ
مرحلہ
ٹیکنالوجی
آلات
1
مقامی چل رہا ہے (ویب / اینڈرائیڈ ڈیمو ٹیسٹ تیار کریں اور اسے مقامی طور پر چلائیں)
Node.js، Selenium، Appium
2
ورژن کنٹرول سسٹم
جاؤ
3
کنٹینرائزیشن
ڈوکر، سیلینیم گرڈ، سیلینائڈ (ویب، اینڈرائیڈ)
4
CI/CD
Gitlab CI
5
کلاؤڈ پلیٹ فارم
گوگل کلاؤڈ پلیٹ فارم
6
آرکیسٹریشن
Kubernetes
7
بنیادی ڈھانچہ بطور کوڈ (IaC)
ٹیرافارم، جوابدہ
ہر سیکشن کی ساخت
بیانیہ کو واضح رکھنے کے لیے ہر حصے کو درج ذیل خاکہ کے مطابق بیان کیا گیا ہے۔
- ٹیکنالوجی کی مختصر وضاحت،
- آٹومیشن انفراسٹرکچر کی قدر،
- بنیادی ڈھانچے کی موجودہ حالت کی مثال،
- مطالعہ کے لنکس،
- اسی طرح کے اوزار.
1. مقامی طور پر ٹیسٹ چلائیں۔
ٹیکنالوجی کی مختصر تفصیل
یہ مقامی طور پر ڈیمو ٹیسٹ چلانے اور ان کے پاس ہونے کی تصدیق کرنے کے لیے صرف ایک تیاری کا مرحلہ ہے۔ عملی حصہ میں، Node.js استعمال کیا جاتا ہے، لیکن پروگرامنگ زبان اور پلیٹ فارم بھی اہم نہیں ہیں اور آپ ان کو استعمال کرسکتے ہیں جو آپ کی کمپنی میں استعمال ہوتے ہیں۔
تاہم، آٹومیشن ٹولز کے طور پر، میں ویب پلیٹ فارمز کے لیے Selenium WebDriver اور Android پلیٹ فارم کے لیے Appium کو بالترتیب استعمال کرنے کی تجویز کرتا ہوں، کیونکہ اگلے مراحل میں ہم Docker امیجز استعمال کریں گے جو خاص طور پر ان ٹولز کے ساتھ کام کرنے کے لیے تیار کی گئی ہیں۔ مزید برآں، ملازمت کی ضروریات کا حوالہ دیتے ہوئے، ان آلات کی مارکیٹ میں سب سے زیادہ مانگ ہے۔
جیسا کہ آپ نے دیکھا ہوگا، ہم صرف ویب اور اینڈرائیڈ ٹیسٹ پر غور کرتے ہیں۔ بدقسمتی سے، iOS ایک بالکل مختلف کہانی ہے (شکریہ ایپل)۔ میں آئندہ حصوں میں IOS سے متعلقہ حل اور طریقوں کو ظاہر کرنے کا ارادہ رکھتا ہوں۔
آٹومیشن انفراسٹرکچر کی قدر
بنیادی ڈھانچے کے نقطہ نظر سے، مقامی طور پر چلانے سے کوئی قدر نہیں ملتی۔ آپ صرف یہ چیک کرتے ہیں کہ ٹیسٹ مقامی مشین پر مقامی براؤزرز اور سمیلیٹرز میں چلتے ہیں۔ لیکن کسی بھی صورت میں، یہ ایک ضروری نقطہ آغاز ہے۔
بنیادی ڈھانچے کی موجودہ حالت کی مثال
دریافت کرنے کے لیے لنکس
ملتے جلتے اوزار
- سیلینیم/ایپیم ٹیسٹ کے ساتھ مل کر آپ کو کوئی بھی پروگرامنگ زبان پسند ہے۔
- کوئی ٹیسٹ؛
- کوئی بھی ٹیسٹ رنر۔
2. ورژن کنٹرول سسٹم (گٹ)
ٹیکنالوجی کی مختصر تفصیل
یہ کسی کے لیے بڑا انکشاف نہیں ہوگا اگر میں یہ کہوں کہ ورژن کنٹرول ایک ٹیم میں اور انفرادی طور پر ترقی کا ایک انتہائی اہم حصہ ہے۔ مختلف ذرائع کی بنیاد پر، یہ کہنا محفوظ ہے کہ گٹ سب سے زیادہ مقبول نمائندہ ہے۔ ایک ورژن کنٹرول سسٹم بہت سے فوائد فراہم کرتا ہے، جیسے کوڈ کا اشتراک، ورژن کو ذخیرہ کرنا، پچھلی شاخوں کو بحال کرنا، پروجیکٹ کی تاریخ کی نگرانی، اور بیک اپ۔ ہم ہر ایک نکتے پر تفصیل سے بات نہیں کریں گے، کیونکہ مجھے یقین ہے کہ آپ اس سے بہت واقف ہیں اور اسے اپنے روزمرہ کے کاموں میں استعمال کرتے ہیں۔ لیکن اگر اچانک نہیں، تو میں اس مضمون کو پڑھنے کو روکنے اور جلد از جلد اس خلا کو پر کرنے کا مشورہ دیتا ہوں۔
آٹومیشن انفراسٹرکچر کی قدر
اور یہاں آپ ایک معقول سوال پوچھ سکتے ہیں: "وہ ہمیں گٹ کے بارے میں کیوں بتا رہا ہے؟ ہر کوئی اسے جانتا ہے اور اسے ترقیاتی کوڈ اور آٹو ٹیسٹ کوڈ دونوں کے لیے استعمال کرتا ہے۔ آپ بالکل ٹھیک کہہ رہے ہوں گے، لیکن اس مضمون میں ہم انفراسٹرکچر کے بارے میں بات کر رہے ہیں اور یہ سیکشن سیکشن 7 کے پیش نظارہ کے طور پر کام کرتا ہے: "انفراسٹرکچر بطور کوڈ (IaC)"۔ ہمارے لیے، اس کا مطلب یہ ہے کہ ٹیسٹنگ سمیت پورے انفراسٹرکچر کو کوڈ کی شکل میں بیان کیا گیا ہے، اس لیے ہم اس پر ورژننگ سسٹم بھی لاگو کر سکتے ہیں اور ترقی اور آٹومیشن کوڈ کی طرح فوائد حاصل کر سکتے ہیں۔
ہم IaC کو مزید تفصیل سے مرحلہ 7 میں دیکھیں گے، لیکن اب بھی آپ Git کو مقامی طور پر مقامی ذخیرہ بنا کر استعمال کرنا شروع کر سکتے ہیں۔ جب ہم انفراسٹرکچر میں ریموٹ ریپوزٹری شامل کریں گے تو بڑی تصویر کو وسعت دی جائے گی۔
بنیادی ڈھانچے کی موجودہ حالت کی مثال
دریافت کرنے کے لیے لنکس
ملتے جلتے اوزار
3. کنٹینرائزیشن (ڈوکر)
ٹیکنالوجی کی مختصر تفصیل
یہ ظاہر کرنے کے لیے کہ کنٹینرائزیشن نے کھیل کے اصولوں کو کس طرح تبدیل کر دیا ہے، آئیے کچھ عشروں پر پیچھے چلتے ہیں۔ اس وقت، لوگوں نے ایپلی کیشنز چلانے کے لیے سرور مشینیں خریدی اور استعمال کیں۔ لیکن زیادہ تر معاملات میں، مطلوبہ ابتدائی وسائل پہلے سے معلوم نہیں تھے۔ نتیجے کے طور پر، کمپنیوں نے مہنگے، طاقتور سرورز کی خریداری پر پیسہ خرچ کیا، لیکن اس میں سے کچھ صلاحیت کو مکمل طور پر استعمال نہیں کیا گیا۔
ارتقاء کا اگلا مرحلہ ورچوئل مشین (VMs) تھا، جس نے غیر استعمال شدہ وسائل پر پیسہ ضائع کرنے کا مسئلہ حل کیا۔ اس ٹیکنالوجی نے مکمل طور پر الگ تھلگ جگہ مختص کرتے ہوئے ایک ہی سرور کے اندر ایپلی کیشنز کو ایک دوسرے سے آزادانہ طور پر چلانا ممکن بنایا۔ لیکن، بدقسمتی سے، کسی بھی ٹیکنالوجی میں اس کی خرابیاں ہیں. VM چلانے کے لیے ایک مکمل آپریٹنگ سسٹم کی ضرورت ہوتی ہے، جو CPU، RAM، اسٹوریج استعمال کرتا ہے اور، OS پر منحصر ہے، لائسنس کے اخراجات کو مدنظر رکھنا ضروری ہے۔ یہ عوامل لوڈنگ کی رفتار کو متاثر کرتے ہیں اور پورٹیبلٹی کو مشکل بناتے ہیں۔
اور اب ہم کنٹینرائزیشن کی طرف آتے ہیں۔ ایک بار پھر، یہ ٹیکنالوجی پچھلا مسئلہ حل کرتی ہے، کیونکہ کنٹینرز ایک مکمل OS استعمال نہیں کرتے، جو وسائل کی ایک بڑی مقدار کو آزاد کرتا ہے اور پورٹیبلٹی کے لیے ایک تیز اور لچکدار حل فراہم کرتا ہے۔
بلاشبہ، کنٹینرائزیشن ٹیکنالوجی کوئی نئی بات نہیں ہے اور اسے پہلی بار 70 کی دہائی کے آخر میں متعارف کرایا گیا تھا۔ ان دنوں بہت سی تحقیق، ترقی اور کوششیں ہوئیں۔ لیکن یہ ڈوکر ہی تھا جس نے اس ٹیکنالوجی کو اپنایا اور اسے عوام تک آسانی سے قابل رسائی بنایا۔ آج کل، جب ہم کنٹینرز کے بارے میں بات کرتے ہیں، تو زیادہ تر معاملات میں ہمارا مطلب ڈوکر ہوتا ہے۔ جب ہم ڈوکر کنٹینرز کے بارے میں بات کرتے ہیں تو ہمارا مطلب ہے لینکس کنٹینرز۔ ہم کنٹینرز کو چلانے کے لیے ونڈوز اور میک او ایس سسٹم استعمال کر سکتے ہیں، لیکن یہ سمجھنا ضروری ہے کہ اس صورت میں ایک اضافی پرت ظاہر ہوتی ہے۔ مثال کے طور پر، Mac پر Docker خاموشی سے ہلکے وزن والے Linux VM کے اندر کنٹینرز چلاتا ہے۔ ہم اس موضوع پر واپس جائیں گے جب ہم کنٹینرز کے اندر اینڈرائیڈ ایمولیٹر چلانے کے بارے میں بات کریں گے، اس لیے یہاں ایک بہت اہم بات ہے جس پر مزید تفصیل سے بات کرنے کی ضرورت ہے۔
آٹومیشن انفراسٹرکچر کی قدر
ہمیں پتہ چلا کہ کنٹینرائزیشن اور ڈوکر ٹھنڈے ہیں۔ آئیے اسے آٹومیشن کے تناظر میں دیکھتے ہیں، کیونکہ ہر ٹول یا ٹیکنالوجی کو کسی مسئلے کو حل کرنے کی ضرورت ہوتی ہے۔ آئیے UI ٹیسٹ کے تناظر میں ٹیسٹ آٹومیشن کے واضح مسائل کا خاکہ پیش کرتے ہیں:
- سیلینیم اور خاص طور پر ایپیم کو انسٹال کرتے وقت انحصار کی ایک بڑی تعداد؛
- براؤزرز، سمیلیٹروں اور ڈرائیوروں کے ورژن کے درمیان مطابقت کے مسائل؛
- براؤزرز/سمیلیٹرز کے لیے الگ تھلگ جگہ کی کمی، جو کہ متوازی چلانے کے لیے خاص طور پر اہم ہے۔
- اگر آپ کو ایک ہی وقت میں 10، 50، 100 یا حتیٰ کہ 1000 براؤزر چلانے کی ضرورت ہو تو اس کا نظم و نسق کرنا مشکل ہے۔
لیکن چونکہ سیلینیم سب سے زیادہ مقبول آٹومیشن ٹول ہے اور ڈوکر کنٹینرائزیشن کا سب سے مشہور ٹول ہے، اس لیے اس میں کوئی تعجب کی بات نہیں ہونی چاہیے کہ کسی نے مذکورہ بالا مسائل کو حل کرنے کے لیے ایک طاقتور ٹول بنانے کے لیے ان کو یکجا کرنے کی کوشش کی ہو۔ آئیے اس طرح کے حل پر مزید تفصیل سے غور کریں۔
ڈوکر میں سیلینیم گرڈ
یہ ٹول سیلینیم کی دنیا میں ایک سے زیادہ مشینوں پر ایک سے زیادہ براؤزر چلانے اور انہیں مرکزی مرکز سے منظم کرنے کے لیے سب سے زیادہ مقبول ہے۔ شروع کرنے کے لیے، آپ کو کم از کم 2 حصوں کو رجسٹر کرنے کی ضرورت ہے: حب اور نوڈ۔ حب ایک مرکزی نوڈ ہے جو ٹیسٹوں سے تمام درخواستیں وصول کرتا ہے اور انہیں مناسب نوڈس میں تقسیم کرتا ہے۔ ہر نوڈ کے لیے ہم ایک مخصوص کنفیگریشن تشکیل دے سکتے ہیں، مثال کے طور پر، مطلوبہ براؤزر اور اس کا ورژن بتا کر۔ تاہم، ہمیں اب بھی ہم آہنگ براؤزر ڈرائیوروں کا خود خیال رکھنا ہوگا اور انہیں مطلوبہ نوڈس پر انسٹال کرنا ہوگا۔ اس وجہ سے، سیلینیم گرڈ کو اس کی خالص شکل میں استعمال نہیں کیا جاتا ہے، سوائے اس وقت کے جب ہمیں ایسے براؤزر کے ساتھ کام کرنے کی ضرورت ہو جو لینکس OS پر انسٹال نہیں ہو سکتے۔ دیگر تمام معاملات کے لیے، ایک نمایاں طور پر لچکدار اور درست حل یہ ہوگا کہ سیلینیم گرڈ ہب اور نوڈس کو چلانے کے لیے ڈوکر امیجز کا استعمال کیا جائے۔ یہ نقطہ نظر نوڈ مینجمنٹ کو بہت آسان بناتا ہے، کیونکہ ہم پہلے سے نصب براؤزرز اور ڈرائیوروں کے ہم آہنگ ورژن کے ساتھ اپنی ضرورت کی تصویر منتخب کر سکتے ہیں۔
استحکام کے بارے میں منفی جائزوں کے باوجود، خاص طور پر جب نوڈس کی ایک بڑی تعداد کو متوازی طور پر چلاتے ہیں، سیلینیم گرڈ اب بھی متوازی طور پر سیلینیم ٹیسٹ چلانے کے لیے سب سے مقبول ٹول ہے۔ یہ نوٹ کرنا ضروری ہے کہ اس ٹول کی مختلف اصلاحات اور ترمیمات اوپن سورس میں مسلسل ظاہر ہو رہی ہیں، جو مختلف رکاوٹوں کا مقابلہ کرتی ہیں۔
ویب کے لئے Selenoid
یہ ٹول سیلینیم کی دنیا میں ایک پیش رفت ہے کیونکہ یہ باکس سے باہر کام کرتا ہے اور اس نے بہت سے آٹومیشن انجینئرز کی زندگی کو بہت آسان بنا دیا ہے۔ سب سے پہلے، یہ سیلینیم گرڈ کی ایک اور ترمیم نہیں ہے۔ اس کے بجائے، ڈویلپرز نے گولانگ میں سیلینیم ہب کا ایک بالکل نیا ورژن بنایا، جس نے مختلف براؤزرز کے لیے ہلکی پھلکی ڈاکر تصاویر کے ساتھ مل کر، ٹیسٹ آٹومیشن کی ترقی کو تحریک دی۔ مزید برآں، سیلینیم گرڈ کے معاملے میں، ہمیں تمام مطلوبہ براؤزرز اور ان کے ورژنز کا پہلے سے تعین کرنا چاہیے، جو صرف ایک براؤزر کے ساتھ کام کرتے وقت کوئی مسئلہ نہیں ہے۔ لیکن جب ایک سے زیادہ معاون براؤزرز کی بات آتی ہے تو، Selenoid اپنی 'براؤزر آن ڈیمانڈ' خصوصیت کی بدولت نمبر ایک حل ہے۔ ہم سے صرف اتنا ضروری ہے کہ براؤزرز کے ساتھ ضروری تصاویر پہلے سے ڈاؤن لوڈ کریں اور کنفیگریشن فائل کو اپ ڈیٹ کریں جس کے ساتھ Selenoid بات چیت کرتا ہے۔ Selenoid کو ٹیسٹوں سے درخواست موصول ہونے کے بعد، یہ خود بخود مطلوبہ براؤزر کے ساتھ مطلوبہ کنٹینر لانچ کر دے گا۔ ٹیسٹ مکمل ہونے پر، Selenoid کنٹینر کو ریٹائر کر دے گا، اس طرح مستقبل کی درخواستوں کے لیے وسائل کو خالی کر دے گا۔ یہ نقطہ نظر 'نوڈ ڈیگریڈیشن' کے معروف مسئلے کو مکمل طور پر ختم کرتا ہے جس کا ہم اکثر سیلینیم گرڈ میں سامنا کرتے ہیں۔
لیکن، افسوس، Selenoid اب بھی چاندی کی گولی نہیں ہے۔ ہمیں 'براؤزر آن ڈیمانڈ' فیچر ملا، لیکن 'ریسورسز آن ڈیمانڈ' فیچر ابھی تک دستیاب نہیں ہے۔ Selenoid استعمال کرنے کے لیے، ہمیں اسے فزیکل ہارڈویئر یا VM پر لگانا چاہیے، جس کا مطلب ہے کہ ہمیں پہلے سے معلوم ہونا چاہیے کہ کتنے وسائل مختص کرنے کی ضرورت ہے۔ میرا اندازہ ہے کہ یہ چھوٹے پروجیکٹس کے لیے کوئی مسئلہ نہیں ہے جو 10، 20 یا یہاں تک کہ 30 براؤزر متوازی طور پر چلاتے ہیں۔ لیکن اگر ہمیں 100، 500، 1000 یا اس سے زیادہ کی ضرورت ہو تو کیا ہوگا؟ ہر وقت بہت سارے وسائل کو برقرار رکھنے اور ان کی ادائیگی کا کوئی مطلب نہیں ہے۔ اس آرٹیکل کے سیکشن 5 اور 6 میں، ہم ان حلوں پر تبادلہ خیال کریں گے جو آپ کو اسکیل کرنے کی اجازت دیتے ہیں، اس طرح کمپنی کے اخراجات میں نمایاں کمی آتی ہے۔
اینڈرائیڈ کے لیے Selenoid
ویب آٹومیشن ٹول کے طور پر Selenoid کی کامیابی کے بعد، لوگ اینڈرائیڈ کے لیے کچھ ایسا ہی چاہتے تھے۔ اور یہ ہوا - Selenoid کو اینڈرائیڈ سپورٹ کے ساتھ جاری کیا گیا۔ اعلیٰ سطحی صارف کے نقطہ نظر سے، آپریشن کا اصول ویب آٹومیشن کی طرح ہے۔ فرق صرف یہ ہے کہ براؤزر کنٹینرز کے بجائے، Selenoid Android ایمولیٹر کنٹینرز چلاتا ہے۔ میری رائے میں، یہ فی الحال متوازی طور پر اینڈرائیڈ ٹیسٹ چلانے کا سب سے طاقتور مفت ٹول ہے۔
میں واقعی میں اس ٹول کے منفی پہلوؤں کے بارے میں بات نہیں کرنا چاہوں گا، کیونکہ مجھے واقعی یہ پسند ہے۔ لیکن پھر بھی، وہی نقصانات ہیں جو ویب آٹومیشن پر لاگو ہوتے ہیں اور اسکیلنگ سے منسلک ہوتے ہیں۔ اس کے علاوہ، ہمیں ایک اور حد کے بارے میں بات کرنے کی ضرورت ہے جو کہ اگر ہم پہلی بار اس ٹول کو ترتیب دے رہے ہیں تو حیران کن ہو سکتا ہے۔ اینڈرائیڈ امیجز کو چلانے کے لیے، ہمیں نیسٹڈ ورچوئلائزیشن سپورٹ کے ساتھ ایک فزیکل مشین یا VM کی ضرورت ہے۔ رہنمائی کے طریقہ کار میں، میں یہ ظاہر کرتا ہوں کہ اسے لینکس VM پر کیسے فعال کیا جائے۔ تاہم، اگر آپ ایک macOS صارف ہیں اور مقامی طور پر Selenoid کو تعینات کرنا چاہتے ہیں، تو یہ اینڈرائیڈ ٹیسٹ چلانا ممکن نہیں ہوگا۔ لیکن آپ ہمیشہ مقامی طور پر 'نیسٹڈ ورچوئلائزیشن' کے ساتھ لینکس VM چلا سکتے ہیں اور اندر Selenoid کو تعینات کر سکتے ہیں۔
بنیادی ڈھانچے کی موجودہ حالت کی مثال
اس مضمون کے تناظر میں، ہم بنیادی ڈھانچے کو واضح کرنے کے لیے 2 ٹولز کا اضافہ کریں گے۔ یہ ویب ٹیسٹوں کے لیے سیلینیم گرڈ اور اینڈرائیڈ ٹیسٹ کے لیے سیلینائڈ ہیں۔ GitHub ٹیوٹوریل میں، میں آپ کو یہ بھی دکھاؤں گا کہ ویب ٹیسٹ چلانے کے لیے Selenoid کا استعمال کیسے کریں۔
دریافت کرنے کے لیے لنکس
ملتے جلتے اوزار
- کنٹینرائزیشن کے دیگر ٹولز ہیں، لیکن ڈوکر سب سے زیادہ مقبول ہے۔ اگر آپ کچھ اور آزمانا چاہتے ہیں تو ذہن میں رکھیں کہ سیلینیم ٹیسٹوں کو متوازی طور پر چلانے کے لیے ہم نے جن ٹولز کا احاطہ کیا ہے وہ باکس سے باہر کام نہیں کریں گے۔
- جیسا کہ پہلے ہی کہا گیا ہے، سیلینیم گرڈ کی بہت سی ترمیمات ہیں، مثال کے طور پر،.
4.CI/CD
ٹیکنالوجی کی مختصر تفصیل
مسلسل انضمام کی مشق ترقی میں کافی مقبول ہے اور ورژن کنٹرول سسٹم کے برابر ہے۔ اس کے باوجود میں محسوس کرتا ہوں کہ اصطلاحات میں ابہام ہے۔ اس پیراگراف میں میں اپنے نقطہ نظر سے اس ٹیکنالوجی کی 3 ترمیمات بیان کرنا چاہوں گا۔ انٹرنیٹ پر آپ کو مختلف تشریحات کے ساتھ بہت سے مضامین ملیں گے، اور اگر آپ کی رائے مختلف ہو تو یہ بالکل عام بات ہے۔ سب سے اہم بات یہ ہے کہ آپ اپنے ساتھیوں کے ساتھ ایک ہی صفحے پر ہیں۔
لہذا، 3 شرائط ہیں: CI - مسلسل انضمام، CD - مسلسل ترسیل اور دوبارہ CD - مسلسل تعیناتی۔ (ذیل میں میں یہ اصطلاحات انگریزی میں استعمال کروں گا۔)۔ ہر ترمیم آپ کے ترقیاتی پائپ لائن میں کئی اضافی اقدامات کا اضافہ کرتی ہے۔ لیکن لفظ مسلسل (مسلسل) سب سے اہم چیز ہے۔ اس تناظر میں، ہمارا مطلب کچھ ایسا ہے جو شروع سے آخر تک ہوتا ہے، بغیر کسی رکاوٹ یا دستی مداخلت کے۔ آئیے اس تناظر میں CI & CD اور CD کو دیکھتے ہیں۔
- مسلسل انضمام یہ ارتقاء کا ابتدائی مرحلہ ہے۔ سرور پر نیا کوڈ جمع کروانے کے بعد، ہمیں فوری تاثرات موصول ہونے کی توقع ہے کہ ہماری تبدیلیاں ٹھیک ہیں۔ عام طور پر، CI میں جامد کوڈ تجزیہ ٹولز اور یونٹ/اندرونی API ٹیسٹ چلانا شامل ہے۔ یہ ہمیں اپنے کوڈ کے بارے میں چند سیکنڈ/منٹ میں معلومات حاصل کرنے کی اجازت دیتا ہے۔
- مسلسل ترسیل ایک زیادہ جدید مرحلہ ہے جہاں ہم انضمام/UI ٹیسٹ چلاتے ہیں۔ تاہم، اس مرحلے پر ہمیں اتنی جلدی نتائج نہیں ملتے جتنے CI کے ساتھ۔ سب سے پہلے، اس قسم کے ٹیسٹ کو مکمل ہونے میں زیادہ وقت لگتا ہے۔ دوم، لانچ کرنے سے پہلے، ہمیں اپنی تبدیلیوں کو ٹیسٹ/اسٹیجنگ ماحول میں تعینات کرنا چاہیے۔ مزید برآں، اگر ہم موبائل کی ترقی کے بارے میں بات کر رہے ہیں، تو ہماری ایپلیکیشن کی تعمیر کے لیے ایک اضافی قدم ظاہر ہوتا ہے۔
- لگاتار تعیناتی فرض کرتا ہے کہ ہم خود بخود پیداوار میں اپنی تبدیلیاں جاری کر دیتے ہیں اگر تمام قبولیت ٹیسٹ پچھلے مراحل میں پاس ہو چکے ہوں۔ اس کے علاوہ، ریلیز کے مرحلے کے بعد، آپ مختلف مراحل کو ترتیب دے سکتے ہیں، جیسے پروڈکشن پر دھواں ٹیسٹ چلانا اور دلچسپی کے میٹرکس کو جمع کرنا۔ مسلسل تعیناتی صرف خودکار ٹیسٹ کے ذریعے اچھی کوریج کے ساتھ ہی ممکن ہے۔ اگر جانچ سمیت کسی بھی دستی مداخلت کی ضرورت ہے، تو یہ اب نہیں ہے۔ مسلسل (مسلسل)۔ پھر ہم کہہ سکتے ہیں کہ ہماری پائپ لائن صرف مسلسل ترسیل کی مشق کے مطابق ہے۔
آٹومیشن انفراسٹرکچر کی قدر
اس سیکشن میں، مجھے یہ واضح کرنا چاہیے کہ جب ہم اینڈ ٹو اینڈ اینڈ UI ٹیسٹ کے بارے میں بات کرتے ہیں، تو اس کا مطلب ہے کہ ہمیں اپنی تبدیلیاں اور متعلقہ خدمات کو جانچ کے ماحول میں تعینات کرنا چاہیے۔ مسلسل انضمام - اس کام کے لیے عمل لاگو نہیں ہوتا ہے اور ہمیں کم از کم مسلسل ڈیلیور کے طریقوں کو لاگو کرنے کا خیال رکھنا چاہیے۔ اگر ہم انہیں پروڈکشن میں چلانے جا رہے ہیں تو UI ٹیسٹ کے تناظر میں مسلسل تعیناتی بھی معنی رکھتی ہے۔
اور اس سے پہلے کہ ہم فن تعمیر کی تبدیلی کی مثال کو دیکھیں، میں GitLab CI کے بارے میں کچھ الفاظ کہنا چاہتا ہوں۔ دوسرے CI/CD ٹولز کے برعکس، GitLab ایک ریموٹ ریپوزٹری اور بہت سی دیگر اضافی خصوصیات فراہم کرتا ہے۔ اس طرح، GitLab CI سے زیادہ ہے۔ اس میں سورس کوڈ مینجمنٹ، ایگیل مینجمنٹ، CI/CD پائپ لائنز، لاگنگ ٹولز اور میٹرکس کو باکس سے باہر جمع کرنا شامل ہے۔ GitLab فن تعمیر Gitlab CI/CD اور GitLab رنر پر مشتمل ہے۔ یہاں سرکاری ویب سائٹ سے ایک مختصر تفصیل ہے:
Gitlab CI/CD ایک API کے ساتھ ایک ویب ایپلیکیشن ہے جو اپنی حالت کو ڈیٹا بیس میں محفوظ کرتی ہے، پروجیکٹس/بلڈز کا انتظام کرتی ہے اور یوزر انٹرفیس فراہم کرتی ہے۔ گٹ لیب رنر ایک ایسی ایپلی کیشن ہے جو تعمیرات پر عمل کرتی ہے۔ اسے الگ سے تعینات کیا جا سکتا ہے اور API کے ذریعے GitLab CI/CD کے ساتھ کام کرتا ہے۔ ٹیسٹ چلانے کے لیے آپ کو Gitlab مثال اور رنر دونوں کی ضرورت ہے۔
بنیادی ڈھانچے کی موجودہ حالت کی مثال
دریافت کرنے کے لیے لنکس
ملتے جلتے اوزار
- اور کئی دوسرے
5. کلاؤڈ پلیٹ فارم
ٹیکنالوجی کی مختصر تفصیل
اس سیکشن میں ہم ایک مقبول رجحان کے بارے میں بات کریں گے جسے 'پبلک کلاؤڈز' کہا جاتا ہے۔ اوپر بیان کردہ ورچوئلائزیشن اور کنٹینرائزیشن ٹیکنالوجیز کے بے پناہ فوائد کے باوجود، ہمیں اب بھی کمپیوٹنگ وسائل کی ضرورت ہے۔ کمپنیاں مہنگے سرورز خریدتی ہیں یا ڈیٹا سینٹرز کرایہ پر لیتی ہیں، لیکن اس معاملے میں ہمیں کتنے وسائل درکار ہوں گے، کیا ہم انہیں 24/7 اور کن مقاصد کے لیے استعمال کریں گے، اس کا حساب (کبھی کبھی غیر حقیقی) کرنا ضروری ہے۔ مثال کے طور پر، پیداوار کے لیے XNUMX/XNUMX چلانے والے سرور کی ضرورت ہوتی ہے، لیکن کیا ہمیں کام کے اوقات سے باہر جانچ کے لیے اسی طرح کے وسائل کی ضرورت ہے؟ یہ اس بات پر بھی منحصر ہے کہ کس قسم کی جانچ کی جا رہی ہے۔ ایک مثال بوجھ/ تناؤ کے ٹیسٹ ہوں گے جنہیں ہم اگلے دن نتائج حاصل کرنے کے لیے غیر کام کے اوقات میں چلانے کا ارادہ رکھتے ہیں۔ لیکن یقینی طور پر XNUMX/XNUMX سرور کی دستیابی آخری سے آخر تک خودکار ٹیسٹوں کے لیے ضروری نہیں ہے اور خاص طور پر دستی جانچ کے ماحول کے لیے نہیں۔ اس طرح کے حالات کے لیے، یہ اچھا ہو گا کہ ضرورت کے مطابق زیادہ سے زیادہ وسائل حاصل کر لیں، ان کا استعمال کریں، اور جب ان کی مزید ضرورت نہ ہو تو ادائیگی بند کر دیں۔ مزید یہ کہ، چند ماؤس کلکس کرکے یا چند اسکرپٹس چلا کر انہیں فوری طور پر حاصل کرنا بہت اچھا ہوگا۔ عوامی بادلوں کو اس کے لیے استعمال کیا جاتا ہے۔ آئیے تعریف کو دیکھتے ہیں:
"عوامی کلاؤڈ کی تعریف عوامی انٹرنیٹ پر تھرڈ پارٹی فراہم کنندگان کی طرف سے پیش کی جانے والی کمپیوٹنگ خدمات کے طور پر کی گئی ہے، جو انہیں ہر اس شخص کے لیے دستیاب کرتی ہے جو انہیں استعمال کرنا یا خریدنا چاہتا ہے۔ وہ مفت ہو سکتے ہیں یا آن ڈیمانڈ بیچے جا سکتے ہیں، جس سے صارفین کو صرف CPU سائیکل، اسٹوریج، یا بینڈوڈتھ کے لیے فی استعمال ادائیگی کرنے کی اجازت ملتی ہے۔"
ایک رائے ہے کہ عوامی بادل مہنگے ہیں. لیکن ان کا کلیدی خیال کمپنی کے اخراجات کو کم کرنا ہے۔ جیسا کہ پہلے ذکر کیا گیا ہے، عوامی بادل آپ کو طلب کے مطابق وسائل حاصل کرنے اور صرف اس وقت تک ادائیگی کرنے کی اجازت دیتے ہیں جب آپ انہیں استعمال کرتے ہیں۔ اس کے علاوہ، بعض اوقات ہم بھول جاتے ہیں کہ ملازمین کو تنخواہیں ملتی ہیں، اور ماہرین بھی ایک مہنگا ذریعہ ہیں۔ اس بات کو ذہن میں رکھنا ضروری ہے کہ عوامی بادل بنیادی ڈھانچے کی مدد کو بہت آسان بناتے ہیں، جس سے انجینئرز کو زیادہ اہم کاموں پر توجہ مرکوز کرنے کی اجازت ملتی ہے۔
آٹومیشن انفراسٹرکچر کی قدر
آخر سے آخر تک UI ٹیسٹوں کے لیے ہمیں کن مخصوص وسائل کی ضرورت ہے؟ بنیادی طور پر یہ ورچوئل مشینیں یا کلسٹرز ہیں (ہم اگلے حصے میں Kubernetes کے بارے میں بات کریں گے) براؤزرز اور ایمولیٹر چلانے کے لیے۔ جتنے زیادہ براؤزر اور ایمولیٹر ہم بیک وقت چلانا چاہتے ہیں، اتنے ہی زیادہ CPU اور میموری کی ضرورت ہوگی اور ہمیں اس کے لیے اتنی ہی زیادہ رقم ادا کرنی ہوگی۔ اس طرح، ٹیسٹ آٹومیشن کے تناظر میں عوامی بادل ہمیں براؤزرز/ایمولیٹروں کی ایک بڑی تعداد (100, 200, 1000...) چلانے کی اجازت دیتے ہیں، جتنی جلدی ممکن ہو ٹیسٹ کے نتائج حاصل کریں اور اس طرح کے انتہائی وسائل کے لیے ادائیگی بند کر دیں۔ طاقت
سب سے زیادہ مقبول کلاؤڈ فراہم کنندگان Amazon Web Services (AWS)، Microsoft Azure، Google Cloud Platform (GCP) ہیں۔ کیسے کریں گائیڈ GCP کو استعمال کرنے کے طریقے کی مثالیں فراہم کرتا ہے، لیکن عام طور پر اس سے کوئی فرق نہیں پڑتا کہ آپ آٹومیشن کے کاموں کے لیے کیا استعمال کرتے ہیں۔ وہ سب تقریباً ایک جیسی فعالیت فراہم کرتے ہیں۔ عام طور پر، فراہم کنندہ کو منتخب کرنے کے لیے، انتظامیہ کمپنی کے مجموعی بنیادی ڈھانچے اور کاروباری ضروریات پر توجہ مرکوز کرتی ہے، جو اس مضمون کے دائرہ کار سے باہر ہے۔ آٹومیشن انجینئرز کے لیے، کلاؤڈ فراہم کنندگان کے استعمال کا موازنہ کلاؤڈ پلیٹ فارمز کے استعمال کے ساتھ کرنا زیادہ دلچسپ ہوگا، خاص طور پر ٹیسٹنگ کے مقاصد کے لیے، جیسے Sauce Labs، BrowserStack، BitBar، وغیرہ۔ تو آئیے بھی کرتے ہیں! میری رائے میں، Sauce Labs سب سے مشہور کلاؤڈ ٹیسٹنگ فارم ہے، اسی لیے میں نے اسے موازنہ کے لیے استعمال کیا۔
آٹومیشن مقاصد کے لیے جی سی پی بمقابلہ سوس لیبز:
آئیے تصور کریں کہ ہمیں بیک وقت 8 ویب ٹیسٹ اور 8 اینڈرائیڈ ٹیسٹ چلانے کی ضرورت ہے۔ اس کے لیے ہم GCP استعمال کریں گے اور Selenoid کے ساتھ 2 ورچوئل مشینیں چلائیں گے۔ پہلے ایک پر ہم براؤزر کے ساتھ 8 کنٹینرز اٹھائیں گے۔ دوسرے پر ایمولیٹرز کے ساتھ 8 کنٹینرز ہیں۔ آئیے قیمتوں پر ایک نظر ڈالتے ہیں:
کروم کے ساتھ ایک کنٹینر چلانے کے لیے، ہمیں ضرورت ہے۔ n1-معیاری-1 گاڑی. اینڈرائیڈ کے معاملے میں ایسا ہوگا۔ n1-معیاری-4 ایک ایمولیٹر کے لیے۔ درحقیقت، ایک زیادہ لچکدار اور سستا طریقہ یہ ہے کہ CPU/میموری کے لیے صارف کی مخصوص اقدار کا تعین کیا جائے، لیکن اس وقت یہ ساس لیبز کے ساتھ موازنہ کے لیے اہم نہیں ہے۔
اور یہاں سوس لیبز استعمال کرنے کے ٹیرف ہیں:
مجھے یقین ہے کہ آپ نے پہلے ہی فرق محسوس کر لیا ہے، لیکن میں پھر بھی اپنے کام کے حساب کتاب کے ساتھ ایک ٹیبل فراہم کروں گا:
مطلوبہ وسائل
مونٹلی
کام کے اوقات(8am - 8pm)
کام کے اوقات+ قبل از وقت
GCP برائے ویب
n1-معیاری-1 x 8 = n1-معیاری-8
$194.18
23 دن * 12 گھنٹے * 0.38 = $104.88
23 دن * 12 گھنٹے * 0.08 = $22.08
ویب کے لیے ساس لیبز
ورچوئل کلاؤڈ 8 متوازی ٹیسٹ
$1.559
-
-
جی سی پی برائے اینڈرائیڈ
n1-معیاری-4 x 8: n1-معیاری-16
$776.72
23 دن * 12 گھنٹے * 1.52 = $419.52
23 دن * 12 گھنٹے * 0.32 = $88.32
اینڈرائیڈ کے لیے سوس لیبز
اصلی ڈیوائس کلاؤڈ 8 متوازی ٹیسٹ
$1.999
-
-
جیسا کہ آپ دیکھ سکتے ہیں، لاگت میں فرق بہت زیادہ ہے، خاص طور پر اگر آپ صرف بارہ گھنٹے کے کام کے دورانیے میں ٹیسٹ چلاتے ہیں۔ لیکن اگر آپ پیشگی مشینیں استعمال کرتے ہیں تو آپ اخراجات کو مزید کم کر سکتے ہیں۔ یہ کیا ہے؟
ایک پیشگی VM ایک مثال ہے جسے آپ عام مثالوں سے کہیں زیادہ قیمت پر بنا اور چلا سکتے ہیں۔ تاہم، Compute Engine ان مثالوں کو ختم کر سکتا ہے (preempt) اگر اسے دوسرے کاموں کے لیے ان وسائل تک رسائی کی ضرورت ہو۔ پیشگی مثالیں کمپیوٹ انجن کی گنجائش سے زیادہ ہیں، لہذا ان کی دستیابی استعمال کے ساتھ مختلف ہوتی ہے۔
اگر آپ کی ایپس غلطی کو برداشت کرنے والی ہیں اور ممکنہ مثالوں کی پیشگوئیوں کو برداشت کر سکتی ہیں، تو پیشگی مثالیں آپ کے Compute Engine کے اخراجات کو نمایاں طور پر کم کر سکتی ہیں۔ مثال کے طور پر، بیچ پروسیسنگ کی ملازمتیں پہلے سے قابل تقلید مثالوں پر چل سکتی ہیں۔ اگر ان میں سے کچھ مثالیں پروسیسنگ کے دوران ختم ہوجاتی ہیں، تو کام سست ہوجاتا ہے لیکن مکمل طور پر بند نہیں ہوتا ہے۔ پیشگی مثالیں آپ کے بیچ پروسیسنگ کے کاموں کو آپ کی موجودہ مثالوں پر اضافی کام کا بوجھ ڈالے بغیر اور اضافی عام مثالوں کی پوری قیمت ادا کرنے کی ضرورت کے بغیر مکمل کرتی ہیں۔
اور یہ اب بھی ختم نہیں ہوا! حقیقت میں، مجھے یقین ہے کہ کوئی بھی بغیر وقفے کے 12 گھنٹے تک ٹیسٹ نہیں چلاتا۔ اور اگر ایسا ہے، تو آپ ورچوئل مشینوں کو خود بخود شروع اور روک سکتے ہیں جب ان کی ضرورت نہ ہو۔ اصل استعمال کا وقت 6 گھنٹے فی دن تک کم کیا جا سکتا ہے۔ پھر ہمارے کام کے تناظر میں ادائیگی 11 براؤزرز کے لیے کم ہو کر $8 ہو جائے گی۔ کیا یہ شاندار نہیں ہے؟ لیکن قبل از وقت مشینوں کے ساتھ ہمیں محتاط رہنا چاہیے اور رکاوٹوں اور عدم استحکام کے لیے تیار رہنا چاہیے، حالانکہ ان حالات کو سافٹ ویئر میں فراہم کیا جا سکتا ہے اور ان سے نمٹا جا سکتا ہے۔ یہ اس کے قابل ہے!
لیکن میں کسی بھی طرح سے یہ نہیں کہہ رہا ہوں کہ 'کبھی بھی کلاؤڈ ٹیسٹ فارم استعمال نہ کریں'۔ ان کے کئی فائدے ہیں۔ سب سے پہلے، یہ صرف ایک ورچوئل مشین نہیں ہے، بلکہ ایک مکمل ٹیسٹ آٹومیشن حل ہے جس میں باکس سے باہر فعالیت کا ایک سیٹ ہے: ریموٹ رسائی، لاگز، اسکرین شاٹس، ویڈیو ریکارڈنگ، مختلف براؤزرز اور جسمانی موبائل آلات۔ بہت سے حالات میں، یہ ایک ضروری وضع دار متبادل ہو سکتا ہے۔ ٹیسٹنگ پلیٹ فارم خاص طور پر IOS آٹومیشن کے لیے مفید ہیں، جب عوامی بادل صرف Linux/Windows سسٹم پیش کر سکتے ہیں۔ لیکن ہم اگلے مضامین میں iOS کے بارے میں بات کریں گے۔ میں ہمیشہ صورتحال کو دیکھنے اور کاموں سے شروع کرنے کی سفارش کرتا ہوں: کچھ معاملات میں عوامی بادلوں کو استعمال کرنا سستا اور زیادہ موثر ہے، اور دوسروں میں ٹیسٹ پلیٹ فارم یقینی طور پر خرچ کی گئی رقم کے قابل ہیں۔
بنیادی ڈھانچے کی موجودہ حالت کی مثال
دریافت کرنے کے لیے لنکس
اسی طرح کے اوزار:
6. آرکیسٹریشن
ٹیکنالوجی کی مختصر تفصیل
میرے پاس اچھی خبر ہے – ہم مضمون کے تقریباً اختتام پر ہیں! اس وقت، ہمارا آٹومیشن انفراسٹرکچر ویب اور اینڈرائیڈ ٹیسٹس پر مشتمل ہے، جسے ہم گٹ لیب CI کے ذریعے متوازی طور پر چلاتے ہیں، Docker سے چلنے والے ٹولز کا استعمال کرتے ہوئے: Selenium grid اور Selenoid۔ مزید برآں، ہم براؤزرز اور ایمولیٹرز والے کنٹینرز کی میزبانی کے لیے GCP کے ذریعے تخلیق کردہ ورچوئل مشینوں کا استعمال کرتے ہیں۔ اخراجات کو کم کرنے کے لیے، ہم ان ورچوئل مشینوں کو صرف ڈیمانڈ پر شروع کرتے ہیں اور جب ٹیسٹنگ نہیں ہو رہی ہوتی ہے تو انہیں روک دیتے ہیں۔ کیا کوئی اور چیز ہے جو ہمارے انفراسٹرکچر کو بہتر کر سکتی ہے؟ جواب ہے ہاں! Kubernetes (K8s) سے ملو!
سب سے پہلے، آئیے دیکھتے ہیں کہ الفاظ آرکیسٹریشن، کلسٹر، اور کبرنیٹس کا ایک دوسرے سے کیا تعلق ہے۔ اعلی سطح پر، آرکیسٹریشن وہ نظام ہے جو ایپلی کیشنز کو تعینات اور منظم کرتا ہے۔ ٹیسٹ آٹومیشن کے لیے، اس طرح کے کنٹینرائزڈ ایپلی کیشنز سیلینیم گرڈ اور سیلینائڈ ہیں۔ Docker اور K8s ایک دوسرے کی تکمیل کرتے ہیں۔ پہلا اطلاق کی تعیناتی کے لیے استعمال ہوتا ہے، دوسرا آرکیسٹریشن کے لیے۔ بدلے میں، K8s ایک کلسٹر ہے۔ کلسٹر کا کام VMs کو نوڈس کے طور پر استعمال کرنا ہے، جو آپ کو ایک سرور (کلسٹر) کے اندر مختلف فنکشنلٹی، پروگرامز اور سروسز انسٹال کرنے کی اجازت دیتا ہے۔ اگر کوئی نوڈس ناکام ہوجاتا ہے، تو دوسرے نوڈس اٹھا لیں گے، جو ہماری درخواست کے بلاتعطل آپریشن کو یقینی بناتا ہے۔ اس کے علاوہ، K8s میں اسکیلنگ سے متعلق اہم فعالیت ہے، جس کی بدولت ہم خود بخود زیادہ سے زیادہ وسائل کو بوجھ اور مقرر کردہ حدود کی بنیاد پر حاصل کر لیتے ہیں۔
سچ میں، دستی طور پر شروع سے Kubernetes کو تعینات کرنا کوئی معمولی کام نہیں ہے۔ میں مشہور طریقہ "Kubernetes The Hard Way" کی رہنمائی کا ایک لنک چھوڑوں گا اور اگر آپ دلچسپی رکھتے ہیں، تو آپ اس پر عمل کر سکتے ہیں۔ لیکن، خوش قسمتی سے، متبادل طریقے اور اوزار موجود ہیں. سب سے آسان طریقہ یہ ہے کہ GCP میں Google Kubernetes Engine (GKE) استعمال کریں، جو آپ کو چند کلکس میں ایک ریڈی میڈ کلسٹر حاصل کرنے کی اجازت دے گا۔ میں سیکھنا شروع کرنے کے لیے اس نقطہ نظر کو استعمال کرنے کی تجویز کرتا ہوں، کیونکہ یہ آپ کو اپنے کاموں کے لیے K8s کا استعمال سیکھنے پر توجہ مرکوز کرنے کی اجازت دے گا بجائے اس کے کہ اندرونی اجزاء کو ایک ساتھ کیسے مربوط کیا جائے۔
آٹومیشن انفراسٹرکچر کی قدر
آئیے چند اہم خصوصیات پر ایک نظر ڈالتے ہیں جو K8s فراہم کرتا ہے:
- ایپلیکیشن کی تعیناتی: VMs کے بجائے ملٹی نوڈس کلسٹر کا استعمال؛
- متحرک اسکیلنگ: وسائل کی لاگت کو کم کرتا ہے جو صرف مطالبہ پر استعمال ہوتے ہیں۔
- خود شفا یابی: پھلیوں کی خودکار بحالی (جس کے نتیجے میں کنٹینرز بھی بحال ہو جاتے ہیں)؛
- ڈاؤن ٹائم کے بغیر اپ ڈیٹس کا رول آؤٹ اور تبدیلیوں کا رول بیک: ٹولز، براؤزرز اور ایمولیٹرز کو اپ ڈیٹ کرنے سے موجودہ صارفین کے کام میں خلل نہیں پڑتا
لیکن K8s اب بھی چاندی کی گولی نہیں ہے۔ ہم جن ٹولز پر غور کر رہے ہیں ان کے تناظر میں تمام فوائد اور حدود کو سمجھنے کے لیے (سیلینیم گرڈ، سیلینائڈ)، ہم K8s کی ساخت پر مختصراً بات کریں گے۔ کلسٹر میں دو قسم کے نوڈس ہوتے ہیں: ماسٹر نوڈس اور ورکرز نوڈس۔ ماسٹر نوڈس انتظام، تعیناتی اور نظام الاوقات کے فیصلوں کے ذمہ دار ہیں۔ ورکرز نوڈس وہ جگہ ہیں جہاں ایپلیکیشنز شروع کی جاتی ہیں۔ نوڈس میں کنٹینر رن ٹائم ماحول بھی ہوتا ہے۔ ہمارے معاملے میں، یہ Docker ہے، جو کنٹینر سے متعلق کارروائیوں کے لیے ذمہ دار ہے۔ لیکن متبادل حل بھی ہیں، مثال کے طور پر. یہ سمجھنا ضروری ہے کہ اسکیلنگ یا خود شفا یابی کا اطلاق براہ راست کنٹینرز پر نہیں ہوتا ہے۔ یہ پوڈز کی تعداد میں اضافہ/کم کرکے لاگو کیا جاتا ہے، جس کے نتیجے میں کنٹینرز ہوتے ہیں (عام طور پر فی پوڈ ایک کنٹینر، لیکن کام کے لحاظ سے اور بھی ہوسکتا ہے)۔ اعلی درجے کا درجہ بندی ورکر نوڈس پر مشتمل ہوتا ہے، جس کے اندر پوڈ ہوتے ہیں، جن کے اندر کنٹینر کھڑے ہوتے ہیں۔
اسکیلنگ کی خصوصیت کلیدی ہے اور اسے کلسٹر نوڈ پول کے اندر دونوں نوڈس اور نوڈ کے اندر پوڈز پر لاگو کیا جا سکتا ہے۔ اسکیلنگ کی 2 قسمیں ہیں جو نوڈس اور پوڈ دونوں پر لاگو ہوتی ہیں۔ پہلی قسم افقی ہے - پیمانہ نوڈس/پڈز کی تعداد میں اضافہ کرکے ہوتا ہے۔ یہ قسم زیادہ افضل ہے۔ دوسری قسم، اس کے مطابق، عمودی ہے. اسکیلنگ نوڈس/پڈس کے سائز میں اضافہ کرکے کی جاتی ہے، نہ کہ ان کی تعداد۔
اب آئیے مندرجہ بالا شرائط کے تناظر میں اپنے ٹولز کو دیکھتے ہیں۔
سیلینیم گرڈ
جیسا کہ پہلے ذکر کیا گیا ہے، سیلینیم گرڈ ایک بہت مقبول ٹول ہے، اور یہ کوئی تعجب کی بات نہیں ہے کہ اسے کنٹینرائز کیا گیا ہے۔ لہذا، یہ کوئی تعجب کی بات نہیں ہے کہ سیلینیم گرڈ کو K8s میں تعینات کیا جا سکتا ہے۔ ایسا کرنے کے طریقہ کی ایک مثال سرکاری K8s ذخیرہ میں مل سکتی ہے۔ ہمیشہ کی طرح، میں سیکشن کے آخر میں لنکس منسلک کرتا ہوں۔ اس کے علاوہ، کیسے کرنا ہے گائیڈ دکھاتا ہے کہ اسے Terraform میں کیسے کرنا ہے۔ براؤزر کنٹینرز پر مشتمل پوڈز کی تعداد کو پیمانہ کرنے کے بارے میں بھی ہدایات موجود ہیں۔ لیکن K8s کے تناظر میں خودکار اسکیلنگ کا فنکشن اب بھی مکمل طور پر واضح کام نہیں ہے۔ جب میں نے پڑھنا شروع کیا تو مجھے کوئی عملی رہنمائی یا سفارش نہیں ملی۔ DevOps ٹیم کے تعاون سے کئی مطالعات اور تجربات کے بعد، ہم نے ایک پوڈ کے اندر ضروری براؤزرز کے ساتھ کنٹینرز اٹھانے کا طریقہ منتخب کیا، جو ایک ورکر نوڈ کے اندر واقع ہے۔ یہ طریقہ ہمیں نوڈس کی تعداد میں اضافہ کرکے افقی اسکیلنگ کی حکمت عملی کو لاگو کرنے کی اجازت دیتا ہے۔ مجھے امید ہے کہ یہ مستقبل میں بدل جائے گا اور ہم بہتر طریقوں اور تیار حلوں کی زیادہ سے زیادہ وضاحتیں دیکھیں گے، خاص طور پر بدلے ہوئے اندرونی فن تعمیر کے ساتھ سیلینیم گرڈ 4 کے اجراء کے بعد۔
Selenoid:
K8s میں Selenoid کی تعیناتی اس وقت سب سے بڑی مایوسی ہے۔ وہ ہم آہنگ نہیں ہیں۔ نظریہ میں، ہم ایک پوڈ کے اندر ایک Selenoid کنٹینر اٹھا سکتے ہیں، لیکن جب Selenoid براؤزرز کے ساتھ کنٹینرز کو لانچ کرنا شروع کر دیتا ہے، تب بھی وہ اسی پوڈ کے اندر ہوں گے۔ اس سے اسکیلنگ ناممکن ہو جاتی ہے اور اس کے نتیجے میں، کلسٹر کے اندر Selenoid کا کام ورچوئل مشین کے اندر کام سے مختلف نہیں ہوگا۔ کہانی کا خاتمہ.
مون:
Selenoid کے ساتھ کام کرتے وقت اس رکاوٹ کو جانتے ہوئے، ڈویلپرز نے Moon نامی ایک زیادہ طاقتور ٹول جاری کیا۔ یہ ٹول اصل میں Kubernetes کے ساتھ کام کرنے کے لیے ڈیزائن کیا گیا تھا اور اس کے نتیجے میں، آٹو اسکیلنگ فیچر کو استعمال کیا جا سکتا ہے اور کیا جانا چاہیے۔ مزید یہ کہ میں یہ کہوں گا کہ اس وقت ایسا ہے۔ صرف سیلینیم کی دنیا میں ایک ٹول، جس میں مقامی K8s کلسٹر سپورٹ باکس سے باہر ہے (اب دستیاب نہیں، اگلا ٹول دیکھیں )۔ چاند کی اہم خصوصیات جو یہ مدد فراہم کرتی ہیں وہ ہیں:
مکمل طور پر بے وطن۔ Selenoid اس وقت چلنے والے براؤزر سیشنز کے بارے میں میموری کی معلومات کو اسٹور کرتا ہے۔ اگر کسی وجہ سے اس کا عمل کریش ہو جاتا ہے — تو چلنے والے تمام سیشن ضائع ہو جاتے ہیں۔ اس کے برعکس چاند کی کوئی اندرونی حالت نہیں ہے اور اسے ڈیٹا سینٹرز میں نقل کیا جا سکتا ہے۔ براؤزر سیشنز زندہ رہتے ہیں یہاں تک کہ اگر ایک یا زیادہ نقلیں نیچے چلی جائیں۔
لہذا، چاند ایک بہترین حل ہے، لیکن ایک مسئلہ ہے: یہ مفت نہیں ہے۔ قیمت سیشن کی تعداد پر منحصر ہے. آپ مفت میں صرف 0-4 سیشن چلا سکتے ہیں، جو خاص طور پر مفید نہیں ہے۔ لیکن، پانچویں سیشن سے شروع ہو کر، آپ کو ہر ایک کے لیے $5 ادا کرنا ہوں گے۔ صورتحال کمپنی کے لحاظ سے مختلف ہوسکتی ہے، لیکن ہمارے معاملے میں، چاند کا استعمال بے معنی ہے۔ جیسا کہ میں نے اوپر بیان کیا ہے، ہم ڈیمانڈ پر سیلینیم گرڈ کے ساتھ VM چلا سکتے ہیں یا کلسٹر میں نوڈس کی تعداد بڑھا سکتے ہیں۔ تقریباً ایک پائپ لائن کے لیے، ہم 500 براؤزر لانچ کرتے ہیں اور ٹیسٹ مکمل ہونے کے بعد تمام وسائل کو روک دیتے ہیں۔ اگر ہم Moon استعمال کرتے ہیں، تو ہمیں اضافی 500 x 5 = $2500 فی مہینہ ادا کرنا پڑے گا، چاہے ہم کتنی ہی بار ٹیسٹ چلائیں۔ ایک بار پھر، میں یہ نہیں کہہ رہا ہوں کہ چاند کا استعمال نہ کریں۔ آپ کے کاموں کے لیے، یہ ایک ناگزیر حل ہو سکتا ہے، مثال کے طور پر، اگر آپ کی تنظیم میں بہت سے پروجیکٹ/ٹیم ہیں اور آپ کو سب کے لیے ایک بہت بڑا مشترکہ کلسٹر درکار ہے۔ ہمیشہ کی طرح، میں آخر میں ایک لنک چھوڑتا ہوں اور آپ کے کام کے تناظر میں تمام ضروری حسابات کرنے کی سفارش کرتا ہوں۔
کالیسٹو: (توجہ! یہ اصل مضمون میں نہیں ہے اور صرف روسی ترجمہ میں موجود ہے۔)
جیسا کہ میں نے کہا، سیلینیم ایک بہت مقبول ٹول ہے، اور آئی ٹی فیلڈ بہت تیزی سے ترقی کر رہا ہے۔ جب میں ترجمے پر کام کر رہا تھا، ویب پر کالسٹو نامی ایک نیا امید افزا ٹول نمودار ہوا (ہیلو سائپرس اور دیگر سیلینیم قاتل)۔ یہ مقامی طور پر K8s کے ساتھ کام کرتا ہے اور آپ کو نوڈس میں تقسیم کردہ پوڈز میں Selenoid کنٹینرز چلانے کی اجازت دیتا ہے۔ آٹو اسکیلنگ سمیت ہر چیز باکس کے باہر کام کرتی ہے۔ لاجواب، لیکن ٹیسٹ کرنے کی ضرورت ہے۔ میں پہلے ہی اس ٹول کو تعینات کرنے اور کئی تجربات چلانے میں کامیاب ہو چکا ہوں۔ لیکن یہ نتیجہ اخذ کرنا بہت جلد ہے، طویل فاصلے پر نتائج حاصل کرنے کے بعد، شاید میں مستقبل کے مضامین میں ایک جائزہ کروں گا۔ فی الحال میں آزاد تحقیق کے لیے صرف لنکس چھوڑ رہا ہوں۔
بنیادی ڈھانچے کی موجودہ حالت کی مثال
دریافت کرنے کے لیے لنکس
ملتے جلتے اوزار
7. بنیادی ڈھانچہ بطور کوڈ (IaC)
ٹیکنالوجی کی مختصر تفصیل
اور اب ہم آخری حصے کی طرف آتے ہیں۔ عام طور پر، یہ ٹیکنالوجی اور متعلقہ کام آٹومیشن انجینئرز کی ذمہ داری نہیں ہیں۔ اور اس کی وجوہات ہیں۔ سب سے پہلے، بہت سی تنظیموں میں، بنیادی ڈھانچے کے مسائل ڈیو اوپس ڈیپارٹمنٹ کے کنٹرول میں ہیں اور ترقیاتی ٹیمیں واقعی اس بات کی پرواہ نہیں کرتی ہیں کہ پائپ لائن کس چیز سے کام کرتی ہے اور اس سے جڑی ہر چیز کو کس طرح سپورٹ کرنے کی ضرورت ہے۔ دوسری بات، آئیے ایماندار بنیں، انفراسٹرکچر بطور کوڈ (IaC) کی پریکٹس اب بھی بہت سی کمپنیوں میں نہیں اپنائی گئی ہے۔ لیکن یہ یقینی طور پر ایک مقبول رجحان بن گیا ہے اور اس سے منسلک عمل، نقطہ نظر اور آلات میں شامل ہونے کی کوشش کرنا ضروری ہے۔ یا کم از کم تازہ ترین رہیں۔
آئیے اس نقطہ نظر کو استعمال کرنے کی ترغیب کے ساتھ شروع کریں۔ ہم پہلے ہی بات کر چکے ہیں کہ GitlabCI میں ٹیسٹ چلانے کے لیے، ہمیں Gitlab Runer کو چلانے کے لیے کم سے کم وسائل کی ضرورت ہوگی۔ اور براؤزرز/ایمولیٹرز کے ساتھ کنٹینرز چلانے کے لیے، ہمیں ایک VM یا کلسٹر کو محفوظ کرنے کی ضرورت ہے۔ وسائل کی جانچ کے علاوہ، ہمیں ترقی، اسٹیجنگ، پروڈکشن کے ماحول کو سپورٹ کرنے کے لیے قابل قدر صلاحیت کی ضرورت ہے، جس میں ڈیٹا بیس، خودکار نظام الاوقات، نیٹ ورک کنفیگریشن، لوڈ بیلنسرز، صارف کے حقوق وغیرہ بھی شامل ہیں۔ اہم مسئلہ اس سب کی حمایت کے لیے درکار کوشش ہے۔ تبدیلیاں کرنے اور اپ ڈیٹس کو رول آؤٹ کرنے کے کئی طریقے ہیں۔ مثال کے طور پر، GCP کے تناظر میں، ہم براؤزر میں UI کنسول استعمال کر سکتے ہیں اور بٹن پر کلک کر کے تمام اعمال انجام دے سکتے ہیں۔ ایک متبادل یہ ہوگا کہ کلاؤڈ اداروں کے ساتھ تعامل کے لیے API کالز کا استعمال کریں، یا مطلوبہ ہیرا پھیری کو انجام دینے کے لیے gcloud کمانڈ لائن یوٹیلیٹی کا استعمال کریں۔ لیکن مختلف اداروں اور بنیادی ڈھانچے کے عناصر کی ایک بڑی تعداد کے ساتھ، تمام کارروائیوں کو دستی طور پر انجام دینا مشکل یا ناممکن ہو جاتا ہے۔ مزید یہ کہ یہ تمام دستی اعمال بے قابو ہیں۔ ہم عملدرآمد سے پہلے انہیں جائزہ کے لیے جمع نہیں کر سکتے، ایک ورژن کنٹرول سسٹم استعمال کر سکتے ہیں، اور فوری طور پر ان تبدیلیوں کو واپس نہیں لے سکتے جن کی وجہ سے واقعہ پیش آیا۔ اس طرح کے مسائل کو حل کرنے کے لیے، انجینئرز نے خودکار باش/شیل اسکرپٹس بنائے اور بنائے، جو کہ پچھلے طریقوں سے زیادہ بہتر نہیں ہیں، کیونکہ انہیں طریقہ کار کے انداز میں جلدی سے پڑھنا، سمجھنا، برقرار رکھنا اور اس میں ترمیم کرنا اتنا آسان نہیں ہے۔
اس مضمون اور رہنمائی کے طریقے میں، میں IaC مشق سے متعلق 2 ٹولز استعمال کرتا ہوں۔ یہ Terraform اور Ansible ہیں۔ کچھ لوگوں کا خیال ہے کہ ان کا ایک ہی وقت میں استعمال کرنا کوئی معنی نہیں رکھتا، کیونکہ ان کی فعالیت ایک جیسی ہے اور وہ قابل تبادلہ ہیں۔ لیکن حقیقت یہ ہے کہ ابتدائی طور پر انہیں بالکل مختلف کام سونپے جاتے ہیں۔ اور حقیقت یہ ہے کہ ان ٹولز کو ایک دوسرے کی تکمیل کرنی چاہیے اس کی تصدیق HashiCorp اور RedHat کی نمائندگی کرنے والے ڈویلپرز کی مشترکہ پیشکش میں ہوئی۔ تصوراتی فرق یہ ہے کہ Terraform خود سرورز کو منظم کرنے کے لیے ایک پروویژننگ ٹول ہے۔ جبکہ Ansible ایک کنفیگریشن مینجمنٹ ٹول ہے جس کا کام ان سرورز پر سافٹ ویئر کو انسٹال کرنا، کنفیگر کرنا اور ان کا انتظام کرنا ہے۔
ان ٹولز کی ایک اور اہم امتیازی خصوصیت کوڈنگ کا انداز ہے۔ bash اور Ansible کے برعکس، Terraform ایک بیانیہ انداز کا استعمال کرتا ہے جس پر عمل درآمد کے نتیجے میں حاصل ہونے والی مطلوبہ آخری حالت کی وضاحت ہوتی ہے۔ مثال کے طور پر، اگر ہم 10 VMs بنانے جا رہے ہیں اور تبدیلیاں Terraform کے ذریعے لاگو کریں گے، تو ہمیں 10 VM ملیں گے۔ اگر ہم اسکرپٹ کو دوبارہ چلاتے ہیں، تو کچھ نہیں ہوگا کیونکہ ہمارے پاس پہلے سے ہی 10 VM ہیں، اور Terraform اس کے بارے میں جانتا ہے کیونکہ یہ بنیادی ڈھانچے کی موجودہ حالت کو اسٹیٹ فائل میں اسٹور کرتا ہے۔ لیکن Ansible ایک طریقہ کار کا استعمال کرتا ہے اور، اگر آپ اسے 10 VMs بنانے کے لیے کہتے ہیں، تو پہلی لانچ پر ہمیں Terraform کی طرح 10 VM ملیں گے۔ لیکن دوبارہ شروع کرنے کے بعد ہمارے پاس پہلے سے ہی 20 VM ہوں گے۔ یہ اہم فرق ہے۔ طریقہ کار کے انداز میں، ہم موجودہ حالت کو ذخیرہ نہیں کرتے ہیں اور صرف ان اقدامات کی ترتیب کو بیان کرتے ہیں جنہیں انجام دینا ضروری ہے۔ بے شک، ہم مختلف حالات کو سنبھال سکتے ہیں، وسائل کے وجود اور موجودہ حالت کے لیے کئی چیک شامل کر سکتے ہیں، لیکن اس منطق کو کنٹرول کرنے میں اپنا وقت ضائع کرنے اور کوشش کرنے کا کوئی فائدہ نہیں۔ اس کے علاوہ، اس سے غلطیاں کرنے کا خطرہ بڑھ جاتا ہے۔
مندرجہ بالا سب کا خلاصہ کرتے ہوئے، ہم یہ نتیجہ اخذ کر سکتے ہیں کہ Terraform اور اعلانیہ اشارے سرورز کی فراہمی کے لیے زیادہ موزوں ٹول ہیں۔ لیکن بہتر ہے کہ کنفیگریشن مینجمنٹ کا کام جوابدہ کو سونپ دیا جائے۔ اس سے ہٹ کر، آئیے آٹومیشن کے تناظر میں استعمال کے معاملات کو دیکھیں۔
آٹومیشن انفراسٹرکچر کی قدر
یہاں سمجھنے کی واحد اہم بات یہ ہے کہ ٹیسٹ آٹومیشن انفراسٹرکچر کو کمپنی کے پورے انفراسٹرکچر کا حصہ سمجھا جانا چاہیے۔ اس کا مطلب ہے کہ تمام IaC طریقوں کو پوری تنظیم کے وسائل پر عالمی سطح پر لاگو کیا جانا چاہئے۔ اس کا ذمہ دار کون ہے یہ آپ کے عمل پر منحصر ہے۔ DevOps ٹیم ان مسائل میں زیادہ تجربہ کار ہے، وہ جو کچھ ہو رہا ہے اس کی پوری تصویر دیکھتے ہیں۔ تاہم، QA انجینئرز آٹومیشن اور پائپ لائن کے ڈھانچے کی تعمیر کے عمل میں زیادہ شامل ہوتے ہیں، جو انہیں تمام مطلوبہ تبدیلیوں اور بہتری کے مواقع کو بہتر طور پر دیکھنے کی اجازت دیتا ہے۔ متوقع نتیجہ حاصل کرنے کے لیے بہترین آپشن ہے مل کر کام کرنا، علم اور خیالات کا تبادلہ کرنا۔
یہاں ٹیسٹ آٹومیشن کے تناظر میں Terraform اور Ansible کے استعمال کی چند مثالیں ہیں اور جن ٹولز پر ہم نے پہلے بات کی تھی:
1. Terraform کا استعمال کرتے ہوئے VMs اور کلسٹرز کی ضروری خصوصیات اور پیرامیٹرز کی وضاحت کریں۔
2. Ansible کا استعمال کرتے ہوئے، جانچ کے لیے ضروری ٹولز انسٹال کریں: docker، Selenoid، Selenium Grid اور براؤزرز/ایمولیٹرز کے مطلوبہ ورژن ڈاؤن لوڈ کریں۔
3. Terraform کا استعمال کرتے ہوئے، VM کی خصوصیات بیان کریں جس میں GitLab Runner لانچ کیا جائے گا۔
4. جوابی، سیٹ سیٹنگز اور کنفیگریشنز کا استعمال کرتے ہوئے GitLab Runner اور اس کے ساتھ ضروری ٹولز انسٹال کریں۔
بنیادی ڈھانچے کی موجودہ حالت کی مثال
دریافت کرنے کے لیے لنکس:
ملتے جلتے اوزار
آئیے اس کا خلاصہ کریں!
مرحلہ
ٹیکنالوجی
آلات
آٹومیشن انفراسٹرکچر کی قدر
1
مقامی چل رہا ہے
Node.js، Selenium، Appium
- ویب اور موبائل کے لیے سب سے مشہور ٹولز
- بہت سی زبانوں اور پلیٹ فارمز کو سپورٹ کرتا ہے (بشمول Node.js)
2
ورژن کنٹرول سسٹم
جاؤ
- ترقیاتی کوڈ کے ساتھ ملتے جلتے فوائد
3
کنٹینرائزیشن
ڈوکر، سیلینیم گرڈ، سیلینائڈ (ویب، اینڈرائیڈ)
- متوازی طور پر ٹیسٹ چل رہے ہیں۔
- الگ تھلگ ماحول
- سادہ، لچکدار ورژن اپ گریڈ
- غیر استعمال شدہ وسائل کو متحرک طور پر روکنا
- سیٹ اپ کرنا آسان ہے
4
CI/CD
Gitlab CI
- پائپ لائن کے حصے کی جانچ کرتا ہے۔
- فوری تاثرات
- پوری کمپنی/ٹیم کے لیے مرئیت
5
کلاؤڈ پلیٹ فارم
گوگل کلاؤڈ پلیٹ فارم
- طلب کے مطابق وسائل (ہم صرف ضرورت کے وقت ادائیگی کرتے ہیں)
- انتظام اور اپ ڈیٹ کرنے میں آسان
- تمام وسائل کی مرئیت اور کنٹرول
6
آرکیسٹریشن
Kubernetes
پوڈ کے اندر براؤزر/ایمولیٹر والے کنٹینرز کے تناظر میں:
- اسکیلنگ/آٹو اسکیلنگ
- خود علاج
- اپ ڈیٹس اور رول بیکس بغیر کسی رکاوٹ کے
7
بنیادی ڈھانچہ بطور کوڈ (IaC)
ٹیرافارم، جوابدہ
- ترقی کے بنیادی ڈھانچے کے ساتھ ملتے جلتے فوائد
- کوڈ ورژننگ کے تمام فوائد
- تبدیلیاں کرنے اور برقرار رکھنے میں آسان
- مکمل طور پر خودکار
دماغ کے نقشے کے خاکے: بنیادی ڈھانچے کا ارتقاء
مرحلہ 1: مقامی
مرحلہ 2: VCS
مرحلہ 3: کنٹینرائزیشن
مرحلہ 4: CI/CD
مرحلہ 5: کلاؤڈ پلیٹ فارم
مرحلہ 6: آرکیسٹریشن
مرحلہ 7: IaC
اس کے بعد کیا ہے؟
تو، یہ مضمون کا اختتام ہے. لیکن آخر میں، میں آپ کے ساتھ کچھ معاہدے قائم کرنا چاہوں گا۔
تمہاری طرف سے
جیسا کہ میں نے شروع میں کہا، میں چاہوں گا کہ مضمون عملی طور پر مفید ہو اور حاصل کردہ علم کو حقیقی کام میں لاگو کرنے میں آپ کی مدد کرے۔ میں دوبارہ شامل کرتا ہوں۔.
لیکن اس کے بعد بھی، مت روکیں، پریکٹس کریں، متعلقہ لنکس اور کتابوں کا مطالعہ کریں، معلوم کریں کہ یہ آپ کی کمپنی میں کیسے کام کرتا ہے، ایسی جگہیں تلاش کریں جو بہتر ہو سکیں اور اس میں حصہ لیں۔ اچھی قسمت!
میری طرف سے
عنوان سے آپ دیکھ سکتے ہیں کہ یہ صرف پہلا حصہ تھا۔ اس حقیقت کے باوجود کہ یہ کافی بڑا نکلا، یہاں اہم موضوعات کا احاطہ نہیں کیا گیا ہے۔ دوسرے حصے میں، میں IOS کے تناظر میں آٹومیشن انفراسٹرکچر کو دیکھنے کا ارادہ رکھتا ہوں۔ صرف macOS سسٹمز پر iOS سمیلیٹر چلانے پر ایپل کی پابندیوں کی وجہ سے، ہمارے حل کی حد محدود ہے۔ مثال کے طور پر، ہم سمیلیٹر چلانے کے لیے Docker یا ورچوئل مشینوں کو چلانے کے لیے پبلک کلاؤڈز استعمال کرنے سے قاصر ہیں۔ لیکن اس کا مطلب یہ نہیں ہے کہ کوئی اور متبادل نہیں ہے۔ میں آپ کو جدید حل اور جدید ٹولز کے ساتھ اپ ٹو ڈیٹ رکھنے کی کوشش کروں گا!
اس کے علاوہ، میں نے نگرانی سے متعلق کافی بڑے موضوعات کا ذکر نہیں کیا ہے۔ حصہ 3 میں، میں بنیادی ڈھانچے کی نگرانی کے سب سے مشہور ٹولز اور کون سے ڈیٹا اور میٹرکس پر غور کرنے جا رہا ہوں۔
اور آخر میں. مستقبل میں، میں ٹیسٹ انفراسٹرکچر اور مقبول ٹولز کی تعمیر پر ایک ویڈیو کورس جاری کرنے کا ارادہ رکھتا ہوں۔ فی الحال، انٹرنیٹ پر DevOps پر کافی کچھ کورسز اور لیکچرز ہیں، لیکن تمام مواد ترقی کے تناظر میں پیش کیے گئے ہیں، نہ کہ ٹیسٹ آٹومیشن کے۔ اس مسئلے پر، مجھے واقعی اس بارے میں رائے کی ضرورت ہے کہ آیا ایسا کورس ٹیسٹرز اور آٹومیشن انجینئرز کی کمیونٹی کے لیے دلچسپ اور قیمتی ہو گا۔ پہلے سے شکریہ!
ماخذ: www.habr.com