RIT 2019 میں، ہمارے ساتھی الیگزینڈر کوروٹکوف نے بنایا CIAN میں ترقی کے آٹومیشن کے بارے میں: زندگی اور کام کو آسان بنانے کے لیے، ہم اپنا انٹیگرو پلیٹ فارم استعمال کرتے ہیں۔ یہ کاموں کے لائف سائیکل کو ٹریک کرتا ہے، روٹین آپریشنز کے ڈویلپرز کو فارغ کرتا ہے اور پیداوار میں کیڑے کی تعداد کو نمایاں طور پر کم کرتا ہے۔ اس پوسٹ میں، ہم الیگزینڈر کی رپورٹ کی تکمیل کریں گے اور آپ کو بتائیں گے کہ ہم اپنے پلیٹ فارم کے ذریعے اوپن سورس پروڈکٹس کو یکجا کرنے کے لیے سادہ اسکرپٹ سے کیسے گئے اور ہماری الگ آٹومیشن ٹیم کیا کرتی ہے۔
زیرو لیول
"زیرو لیول جیسی کوئی چیز نہیں ہے، میں ایسی کوئی چیز نہیں جانتا"
فلم "کنگ فو پانڈا" سے ماسٹر شیفو
CIAN میں آٹومیشن کمپنی کے قائم ہونے کے 14 سال بعد شروع ہوئی۔ اس وقت ترقیاتی ٹیم میں 35 افراد تھے۔ یقین کرنا مشکل ہے، ٹھیک ہے؟ بلاشبہ، آٹومیشن کسی نہ کسی شکل میں موجود تھی، لیکن مسلسل انضمام اور کوڈ کی ترسیل کے لیے ایک الگ سمت 2015 میں شکل اختیار کرنا شروع ہوئی۔
اس وقت، ہمارے پاس Python، C# اور PHP کا ایک بہت بڑا monolith تھا، جو Linux/Windows سرورز پر تعینات تھا۔ اس عفریت کو تعینات کرنے کے لیے، ہمارے پاس اسکرپٹ کا ایک سیٹ تھا جسے ہم دستی طور پر چلاتے تھے۔ یک سنگی کی اسمبلی بھی تھی، جو شاخوں کو ضم کرنے، نقائص کو درست کرنے، اور "تعمیر میں مختلف کاموں کے ساتھ" دوبارہ تعمیر کرتے وقت تنازعات کی وجہ سے تکلیف اور تکلیف لاتی تھی۔ ایک آسان عمل اس طرح نظر آیا:
ہم اس سے خوش نہیں تھے، اور ہم دوبارہ قابل، خودکار اور قابل انتظام تعمیر اور تعیناتی کا عمل بنانا چاہتے تھے۔ اس کے لیے، ہمیں ایک CI/CD سسٹم کی ضرورت تھی، اور ہم نے Teamcity کے مفت ورژن اور Jenkins کے مفت ورژن کے درمیان انتخاب کیا، کیونکہ ہم نے ان کے ساتھ کام کیا اور دونوں ہی افعال کے سیٹ کے لحاظ سے ہمارے لیے موزوں تھے۔ ہم نے ٹیم سٹی کو ایک حالیہ پروڈکٹ کے طور پر منتخب کیا۔ اس وقت، ہم نے ابھی تک مائیکرو سروس فن تعمیر کا استعمال نہیں کیا تھا اور ہمیں بڑی تعداد میں کاموں اور منصوبوں کی توقع نہیں تھی۔
ہمیں اپنے نظام کا خیال آتا ہے۔
ٹیم سٹی کے نفاذ نے دستی کام کا صرف ایک حصہ ہٹا دیا: جو باقی رہ گیا ہے وہ ہے پل کی درخواستوں کی تخلیق، جیرا میں حیثیت کے لحاظ سے مسائل کا فروغ، اور رہائی کے لیے مسائل کا انتخاب۔ ٹیم سٹی سسٹم مزید اس سے نمٹ نہیں سکتا۔ مزید آٹومیشن کا راستہ منتخب کرنا ضروری تھا۔ ہم نے Teamcity میں اسکرپٹ کے ساتھ کام کرنے یا فریق ثالث آٹومیشن سسٹمز پر سوئچ کرنے کے اختیارات پر غور کیا۔ لیکن آخر میں ہم نے فیصلہ کیا کہ ہمیں زیادہ سے زیادہ لچک کی ضرورت ہے، جو صرف ہمارا اپنا حل فراہم کر سکتا ہے۔ اس طرح اندرونی آٹومیشن سسٹم کا پہلا ورژن جس کا نام Integro ہے۔
Teamcity تعمیر اور تعیناتی کے عمل کو شروع کرنے کی سطح پر آٹومیشن سے نمٹتی ہے، جبکہ Integro نے ترقیاتی عمل کی اعلیٰ سطح کی آٹومیشن پر توجہ مرکوز کی۔ بٹ بکٹ میں متعلقہ سورس کوڈ کی پروسیسنگ کے ساتھ جیرا میں مسائل کے ساتھ کام کو جوڑنا ضروری تھا۔ اس مرحلے پر، انٹیگرو نے مختلف اقسام کے کاموں کے ساتھ کام کرنے کے لیے اپنا ورک فلو بنانا شروع کیا۔
کاروباری عمل میں آٹومیشن میں اضافے کی وجہ سے، ٹیم سٹی میں پروجیکٹس اور رنز کی تعداد میں اضافہ ہوا ہے۔ لہذا ایک نیا مسئلہ آیا: ایک مفت ٹیم سٹی مثال کافی نہیں تھی (3 ایجنٹ اور 100 پروجیکٹس)، ہم نے ایک اور مثال (3 مزید ایجنٹ اور 100 پروجیکٹس) شامل کیں، پھر ایک اور۔ نتیجے کے طور پر، ہم نے کئی کلسٹرز کے نظام کو ختم کیا، جس کا انتظام کرنا مشکل تھا:
جب چوتھی مثال کا سوال پیدا ہوا، تو ہم نے محسوس کیا کہ ہم اس طرح زندہ نہیں رہ سکتے، کیونکہ 4 مثالوں کو سپورٹ کرنے کے کل اخراجات اب کسی حد کے اندر نہیں رہے۔ سوال پیڈ ٹیم سٹی خریدنے یا مفت جینکنز کو منتخب کرنے کے بارے میں پیدا ہوا۔ ہم نے مثالوں اور آٹومیشن کے منصوبوں پر حساب لگایا اور فیصلہ کیا کہ ہم جینکنز پر رہیں گے۔ چند ہفتوں کے بعد، ہم نے جینکنز کو تبدیل کیا اور ٹیم سٹی کے متعدد واقعات کو برقرار رکھنے سے وابستہ کچھ سر درد کو ختم کیا۔ لہذا، ہم انٹیگرو کو تیار کرنے اور اپنے لیے جینکنز کو حسب ضرورت بنانے پر توجہ مرکوز کرنے کے قابل تھے۔
بنیادی آٹومیشن کی ترقی کے ساتھ (پُل درخواستوں کی خودکار تخلیق، کوڈ کوریج کی جمع اور اشاعت اور دیگر چیک کی صورت میں)، جہاں تک ممکن ہو دستی ریلیز کو ترک کرنے اور یہ کام روبوٹس کو دینے کی شدید خواہش ہے۔ اس کے علاوہ، کمپنی نے کمپنی کے اندر مائیکرو سروسز کی طرف جانا شروع کر دیا، جس کے لیے بار بار ریلیز کی ضرورت تھی، اور ایک دوسرے سے الگ۔ اس طرح ہم دھیرے دھیرے اپنی مائیکرو سروسز کی خودکار ریلیز کی طرف آئے (ہم فی الحال عمل کی پیچیدگی کی وجہ سے یک سنگی کو دستی طور پر جاری کر رہے ہیں)۔ لیکن، جیسا کہ عام طور پر ہوتا ہے، ایک نئی پیچیدگی پیدا ہوئی۔
ہم خودکار جانچ کرتے ہیں۔
ریلیز کے آٹومیشن کی وجہ سے، ترقی کے عمل میں تیزی آئی ہے، جزوی طور پر کچھ جانچ کے مراحل کو چھوڑنے کی وجہ سے۔ اور اس کی وجہ سے معیار کا عارضی نقصان ہوا۔ یہ معمولی لگتا ہے، لیکن ریلیز کی تیز رفتار کے ساتھ، مصنوعات کی ترقی کے طریقہ کار کو تبدیل کرنا ضروری تھا. ٹیسٹنگ کے آٹومیشن کے بارے میں سوچنا ضروری تھا، ذاتی ذمہ داری (یہاں ہم "سر میں خیال کو قبول کرنے" کے بارے میں بات کر رہے ہیں، نہ کہ مالیاتی جرمانے کے بارے میں) جاری کردہ کوڈ اور اس میں کیڑے کے لئے، اور ساتھ ہی فیصلہ خودکار تعیناتی کے ذریعے ٹاسک کو جاری/نہ چھوڑنا۔
معیار کے مسائل کو ختم کرتے ہوئے، ہم دو اہم فیصلوں پر پہنچے: ہم نے کینری ٹیسٹنگ شروع کی اور غلطی کے پس منظر کی خود کار طریقے سے نگرانی متعارف کرائی جس میں اس کی زیادتی پر خودکار جواب دیا گیا۔ پہلے حل نے کوڈ کو پروڈکشن میں مکمل طور پر جاری ہونے سے پہلے واضح غلطیوں کو تلاش کرنا ممکن بنایا، دوسرے نے پروڈکشن میں مسائل کے جواب کے وقت کو کم کردیا۔ غلطیاں ضرور ہوتی ہیں، لیکن ہم اپنا زیادہ تر وقت اور کوشش ان کو درست کرنے میں نہیں بلکہ ان کو کم کرنے میں صرف کرتے ہیں۔
آٹومیشن ٹیم
ہمارے پاس فی الحال 130 ڈویلپرز کا عملہ ہے، اور ہم جاری رکھے ہوئے ہیں۔ . مسلسل انضمام اور کوڈ ڈیلیوری ٹیم (جسے بعد میں ڈیپلائی اینڈ انٹیگریشن یا ڈی آئی ٹیم کہا جاتا ہے) 7 افراد پر مشتمل ہے اور 2 سمتوں میں کام کرتی ہے: انٹیگرو آٹومیشن پلیٹ فارم اور ڈی او اوپس کی ترقی۔
DevOps CIAN سائٹ کے دیو/بیٹا ماحول کے لیے ذمہ دار ہے، انٹیگرو ماحول، ڈویلپرز کو مسائل کو حل کرنے میں مدد کرتا ہے اور ماحول کو پیمانہ کرنے کے لیے نئے طریقے تیار کرتا ہے۔ انٹیگرو ڈیولپمنٹ ڈائریکشن انٹیگرو خود اور متعلقہ خدمات دونوں سے متعلق ہے، مثال کے طور پر، جینکنز، جیرا، کنفلوئنس کے لیے پلگ ان، اور ترقیاتی ٹیموں کے لیے معاون یوٹیلیٹیز اور ایپلیکیشنز بھی تیار کرتی ہے۔
DI ٹیم پلیٹ فارم ٹیم کے ساتھ مل کر کام کرتی ہے، جو اندرونی طور پر فن تعمیر، لائبریریوں اور ترقی کے طریقوں کو تیار کرتی ہے۔ ایک ہی وقت میں، CIAN کے اندر کوئی بھی ڈویلپر آٹومیشن میں حصہ ڈال سکتا ہے، مثال کے طور پر، ٹیم کی ضروریات کے مطابق مائیکرو آٹومیشن بنا سکتا ہے یا آٹومیشن کو مزید بہتر بنانے کے طریقے کے بارے میں کوئی ٹھنڈا خیال شیئر کر سکتا ہے۔
CIAN میں آٹومیشن کی پرت کیک
آٹومیشن میں شامل تمام سسٹمز کو کئی پرتوں میں تقسیم کیا جا سکتا ہے:
- بیرونی نظام (جیرا، بٹ بکٹ، وغیرہ)۔ ترقیاتی ٹیمیں ان کے ساتھ کام کرتی ہیں۔
- انٹیگرو پلیٹ فارم۔ اکثر، ڈویلپر براہ راست اس کے ساتھ کام نہیں کرتے ہیں، لیکن یہ وہی ہے جو تمام آٹومیشن کو چلتا رہتا ہے۔
- ڈیلیوری، آرکیسٹریشن اور دریافت کی خدمات (مثال کے طور پر، Jeknins، Consul، Nomad)۔ ان کی مدد سے، ہم سرورز پر کوڈ تعینات کرتے ہیں اور اس بات کو یقینی بناتے ہیں کہ خدمات ایک دوسرے کے ساتھ کام کریں۔
- جسمانی پرت (سرور، OS، متعلقہ سافٹ ویئر)۔ ہمارا کوڈ اس سطح پر کام کرتا ہے۔ یہ یا تو فزیکل سرور ہو سکتا ہے یا ورچوئل سرور (LXC، KVM، Docker)۔
اس تصور کی بنیاد پر، ہم DI ٹیم کے اندر ذمہ داری کے شعبوں کو تقسیم کرتے ہیں۔ پہلی دو سطحیں انٹیگرو ڈویلپمنٹ ڈائریکشن کی ذمہ داری کے علاقے میں ہیں، اور آخری دو لیولز پہلے سے ہی DevOps کی ذمہ داری کے علاقے میں ہیں۔ یہ علیحدگی ہمیں کاموں پر توجہ مرکوز کرنے کی اجازت دیتی ہے اور بات چیت میں مداخلت نہیں کرتی، کیونکہ ہم ایک دوسرے کے قریب ہیں اور مسلسل علم اور تجربے کا تبادلہ کرتے ہیں۔
برقرار
آئیے انٹیگرو پر توجہ مرکوز کریں اور ٹیکنالوجی اسٹیک کے ساتھ شروع کریں:
- CentOS 7
- ڈاکر + خانہ بدوش + قونصل + والٹ
- جاوا 11 (پرانا انٹیگرو مونولیتھ جاوا 8 پر رہے گا)
- Spring Boot 2.X + Spring Cloud Config
- پوسٹگری ایس کیو ایل 11
- خرگوش
- اپاچی اگنائٹ
- کیمونڈا (ایمبیڈڈ)
- گرافانا + گریفائٹ + پرومیتھیس + جیگر + ای ایل کے
- ویب UI: رد عمل (CSR) + MobX
- ایس ایس او: کی کلوک
ہم مائیکرو سروس ڈویلپمنٹ کے اصول پر کاربند ہیں، حالانکہ ہمارے پاس انٹیگرو کے ابتدائی ورژن کے یک سنگی کی شکل میں میراث ہے۔ ہر مائیکرو سروس اپنے اپنے ڈوکر کنٹینر میں چلتی ہے، اور خدمات HTTP درخواستوں اور RabbitMQ پیغامات کے ذریعے ایک دوسرے کے ساتھ بات چیت کرتی ہیں۔ مائیکرو سروسز قونصل کے ذریعے ایک دوسرے کو تلاش کرتی ہیں اور SSO (Keycloak, OAuth 2/OpenID Connect) کے ذریعے اجازت دیتے ہوئے اس سے درخواست کرتی ہیں۔
حقیقی زندگی کی مثال کے طور پر، جینکنز کے ساتھ بات چیت پر غور کریں، جو درج ذیل مراحل پر مشتمل ہے:
- ورک فلو مینجمنٹ مائیکرو سرویس (اس کے بعد فلو مائیکرو سرویس کہا جاتا ہے) جینکنز میں ایک تعمیر چلانا چاہتا ہے۔ ایسا کرنے کے لیے، وہ جینکنز کے ساتھ انضمام کے لیے مائیکرو سروس کے آئی پی:پورٹ کو تلاش کرنے کے لیے قونصل کا استعمال کرتا ہے (اس کے بعد اسے جینکنز مائیکرو سرویس کہا جاتا ہے) اور اسے جینکنز میں تعمیر شروع کرنے کے لیے ایک متضاد درخواست بھیجتا ہے۔
- درخواست موصول ہونے کے بعد، جینکنز مائیکرو سروس ایک جاب آئی ڈی تیار کرتی ہے اور اس کا جواب دیتی ہے، جسے پھر کام کے نتیجے کی شناخت کے لیے استعمال کیا جا سکتا ہے۔ ایک ہی وقت میں، یہ REST API کال کے ذریعے جینکنز میں تعمیر کو متحرک کرتا ہے۔
- جینکنز تعمیر کو انجام دیتا ہے اور تکمیل کے بعد، جینکنز مائیکرو سروس کو عملدرآمد کے نتائج کے ساتھ ایک ویب ہک بھیجتا ہے۔
- جینکنز مائیکرو سروس، ویب ہُک حاصل کرنے کے بعد، درخواست کی کارروائی کی تکمیل کے بارے میں ایک پیغام تیار کرتی ہے اور اس پر عملدرآمد کے نتائج کو منسلک کرتی ہے۔ تیار کردہ پیغام RabbitMQ قطار میں بھیجا جاتا ہے۔
- RabbitMQ کے ذریعے، شائع شدہ پیغام Flow microservice تک پہنچتا ہے، جو درخواست اور موصول ہونے والے پیغام سے جاب آئی ڈی کو ملا کر اپنے ٹاسک پر کارروائی کے نتیجے کے بارے میں سیکھتا ہے۔
اب ہمارے پاس تقریباً 30 مائیکرو سروسز ہیں، جنہیں کئی گروپوں میں تقسیم کیا جا سکتا ہے:
- کنفیگریشن مینجمنٹ۔
- صارفین کے ساتھ معلومات اور تعامل (میسنجر، میل)۔
- سورس کوڈ کے ساتھ کام کرنا۔
- تعیناتی ٹولز کے ساتھ انضمام (جینکنز، خانہ بدوش، قونصل وغیرہ)۔
- نگرانی (ریلیز، غلطیاں، وغیرہ)۔
- ویب یوٹیلیٹیز (ٹیسٹ کے ماحول کو منظم کرنے، اعدادوشمار جمع کرنے وغیرہ کے لیے UI)۔
- ٹاسک ٹریکرز اور اسی طرح کے سسٹمز کے ساتھ انضمام۔
- مختلف کاموں کے لیے ورک فلو کا انتظام۔
ورک فلو کے کام
انٹیگرو ٹاسک لائف سائیکل سے متعلق سرگرمیوں کو خودکار کرتا ہے۔ آسان الفاظ میں، کسی کام کے لائف سائیکل کو جیرا میں کسی کام کے ورک فلو کے طور پر سمجھا جائے گا۔ ہمارے ترقیاتی عمل میں پروجیکٹ، کام کی قسم اور کسی خاص کام میں منتخب کیے گئے اختیارات کے لحاظ سے ورک فلو کے متعدد تغیرات ہوتے ہیں۔
آئیے اس ورک فلو کو دیکھیں جسے ہم اکثر استعمال کرتے ہیں:
خاکہ میں، گیئر اشارہ کرتا ہے کہ منتقلی کو Integro کے ذریعے خود بخود بلایا جاتا ہے، جبکہ انسانی شکل یہ بتاتی ہے کہ منتقلی کو کسی شخص کے ذریعے دستی طور پر کہا جاتا ہے۔ آئیے کئی راستوں پر نظر ڈالتے ہیں جو ایک کام اس ورک فلو میں لے سکتا ہے۔
کینری ٹیسٹ کے بغیر DEV+BETA پر مکمل طور پر دستی ٹیسٹنگ (عام طور پر اس طرح ہم ایک یک سنگی کو جاری کرتے ہیں):
دوسرے منتقلی کے مجموعے ہو سکتے ہیں۔ بعض اوقات جو راستہ کوئی مسئلہ اختیار کرے گا اسے جیرا میں اختیارات کے ذریعے منتخب کیا جا سکتا ہے۔
ٹاسک موومنٹ
آئیے ان اہم اقدامات کو دیکھتے ہیں جو "DEV Testing + Canary Tests" ورک فلو کے ذریعے کسی کام کو منتقل کرتے وقت کیے جاتے ہیں:
1. ڈویلپر یا PM کام تخلیق کرتا ہے۔
2. ڈویلپر کام کرنے کے لیے کام لیتا ہے۔ تکمیل کے بعد، یہ جائزہ میں تبدیل ہو جاتا ہے۔
3. جیرا جیرا مائیکرو سروس (جیرا کے ساتھ انضمام کے لیے ذمہ دار) کو ویب ہک بھیجتا ہے۔
4. جیرا مائیکرو سروس ورک فلو شروع کرنے کے لیے فلو سروس (اندرونی ورک فلو کے لیے ذمہ دار ہے جس میں کام انجام دیا جاتا ہے) کو ایک درخواست بھیجتا ہے۔
5. فلو سروس کے اندر:
- جائزہ لینے والوں کو اس کام کے لیے تفویض کیا گیا ہے (صارفین مائیکرو سروس جو صارفین کے بارے میں سب کچھ جانتے ہیں + جیرا مائیکرو سروس)۔
- سورس مائیکرو سروس کے ذریعے (یہ ریپوزٹریز اور برانچز کے بارے میں جانتا ہے، لیکن خود کوڈ کے ساتھ کام نہیں کرتا)، ایک ایسے ریپوزٹریز کے لیے تلاش کی جاتی ہے جس میں ہمارے شمارے کی ایک شاخ ہوتی ہے (تلاش کو آسان بنانے کے لیے، برانچ کا نام اس مسئلے کے ساتھ موافق ہوتا ہے۔ جیرا میں نمبر) اکثر، ایک کام کی ایک ریپوزٹری میں صرف ایک شاخ ہوتی ہے؛ یہ تعیناتی قطار کے انتظام کو آسان بناتا ہے اور ذخیرہ خانوں کے درمیان رابطے کو کم کرتا ہے۔
- ہر پائی جانے والی شاخ کے لیے، اعمال کی درج ذیل ترتیب کی جاتی ہے:
i) ماسٹر برانچ کو اپ ڈیٹ کرنا (کوڈ کے ساتھ کام کرنے کے لیے گٹ مائیکرو سروس)۔
ii) برانچ کو ڈویلپر (Bitbucket microservice) کے ذریعے تبدیلیوں سے روک دیا گیا ہے۔
iii) اس برانچ (Bitbucket microservice) کے لیے ایک پل کی درخواست بنائی گئی ہے۔
iv) ایک نئی پل کی درخواست کے بارے میں ایک پیغام ڈویلپر چیٹس کو بھیجا جاتا ہے (اطلاعات کے ساتھ کام کرنے کے لیے مائیکرو سروس کو مطلع کریں)۔
v) ڈی ای وی (جینکنز کے ساتھ کام کرنے کے لیے جینکنز مائیکرو سرویس) پر تعمیر، جانچ اور تعیناتی کام شروع کیے گئے ہیں۔
vi) اگر پچھلے تمام مراحل کامیابی سے مکمل ہو جاتے ہیں، تو انٹیگرو اپنی منظوری کو پل کی درخواست (بٹ بکٹ مائیکرو سروس) میں رکھتا ہے۔ - انٹیگرو نامزد جائزہ کاروں کی طرف سے پل کی درخواست کی منظوری کا منتظر ہے۔
- جیسے ہی تمام ضروری منظوری مل جاتی ہے (بشمول خودکار ٹیسٹ مثبت طور پر گزر چکے ہیں)، انٹیگرو ٹاسک کو ٹیسٹ آن دیو (جیرا مائیکرو سروس) اسٹیٹس پر منتقل کر دیتا ہے۔
6. ٹیسٹرز کام کی جانچ کرتے ہیں۔ اگر کوئی مسئلہ نہیں ہے، تو کام کو تعمیر کے لیے تیار حالت میں منتقل کر دیا جاتا ہے۔
7. انٹیگرو "دیکھتا ہے" کہ ٹاسک ریلیز کے لیے تیار ہے اور کینری موڈ (جینکنز مائیکرو سروس) میں اپنی تعیناتی شروع کرتا ہے۔ رہائی کی تیاری کا تعین قوانین کے ایک سیٹ سے ہوتا ہے۔ مثال کے طور پر، کام مطلوبہ حالت میں ہے، دیگر کاموں پر کوئی تالے نہیں ہیں، فی الحال اس مائیکرو سروس کے کوئی فعال اپ لوڈز نہیں ہیں، وغیرہ۔
8. یہ کام کینری سٹیٹس (جیرا مائیکرو سروس) میں منتقل کر دیا گیا ہے۔
9. جینکنز کینری موڈ میں Nomad کے ذریعے ایک تعیناتی کا کام شروع کرتا ہے (عام طور پر 1-3 واقعات) اور ریلیز مانیٹرنگ سروس (DeployWatch microservice) کو تعیناتی کے بارے میں مطلع کرتا ہے۔
10. DeployWatch مائیکرو سروس خرابی کا پس منظر جمع کرتی ہے اور اگر ضروری ہو تو اس پر ردعمل ظاہر کرتی ہے۔ اگر خرابی کا پس منظر حد سے تجاوز کر جاتا ہے (پس منظر کا معیار خود بخود حساب کیا جاتا ہے)، ڈویلپرز کو مائیکرو سروس کے ذریعے مطلع کیا جاتا ہے۔ اگر 5 منٹ کے بعد ڈویلپر نے جواب نہیں دیا ہے (Revert or Stay پر کلک کریں)، تو کینری مثالوں کا ایک خودکار رول بیک شروع کیا جاتا ہے۔ اگر پس منظر کی حد سے زیادہ نہیں ہے، تو ڈویلپر کو دستی طور پر ٹاسک کی تعیناتی کو پروڈکشن میں شروع کرنا ہوگا (UI میں بٹن پر کلک کرکے)۔ اگر 60 منٹ کے اندر ڈویلپر نے پروڈکشن میں تعیناتی شروع نہیں کی ہے، تو حفاظتی وجوہات کی بنا پر کینری مثالیں بھی واپس کر دی جائیں گی۔
11. پیداوار میں تعیناتی شروع کرنے کے بعد:
- ٹاسک کو پروڈکشن اسٹیٹس (جیرا مائیکرو سروس) میں منتقل کر دیا گیا ہے۔
- جینکنز مائیکرو سروس تعیناتی کا عمل شروع کرتی ہے اور تعیناتی کے بارے میں DeployWatch مائیکرو سروس کو مطلع کرتی ہے۔
- DeployWatch مائیکرو سروس چیک کرتی ہے کہ پروڈکشن پر موجود تمام کنٹینرز کو اپ ڈیٹ کر دیا گیا ہے (ایسے معاملات تھے جب سب کو اپ ڈیٹ نہیں کیا گیا تھا)۔
- نوٹیفائی مائیکرو سروس کے ذریعے، تعیناتی کے نتائج کے بارے میں ایک اطلاع پروڈکشن کو بھیجی جاتی ہے۔
12. اگر غلط مائیکرو سروس رویے کا پتہ چلا تو ڈویلپرز کے پاس پروڈکشن سے کسی کام کو واپس شروع کرنے کے لیے 30 منٹ کا وقت ہوگا۔ اس وقت کے بعد، کام خود بخود ماسٹر (Git microservice) میں ضم ہو جائے گا۔
13. ماسٹر میں کامیاب انضمام کے بعد، ٹاسک اسٹیٹس کو بند (جیرا مائیکرو سروس) میں تبدیل کر دیا جائے گا۔
خاکہ مکمل طور پر تفصیلی ہونے کا بہانہ نہیں کرتا ہے (حقیقت میں اور بھی اقدامات ہیں)، لیکن یہ آپ کو عمل میں انضمام کی ڈگری کا اندازہ لگانے کی اجازت دیتا ہے۔ ہم اس اسکیم کو مثالی نہیں سمجھتے اور خودکار ریلیز اور تعیناتی سپورٹ کے عمل کو بہتر بنا رہے ہیں۔
آگے کیا ہے
ہمارے پاس آٹومیشن کی ترقی کے لیے بڑے منصوبے ہیں، مثال کے طور پر، یک سنگی ریلیز کے دوران دستی آپریشنز کو ختم کرنا، خودکار تعیناتی کے دوران نگرانی کو بہتر بنانا، اور ڈویلپرز کے ساتھ تعامل کو بہتر بنانا۔
لیکن اب کے لیے یہیں رکتے ہیں۔ ہم نے آٹومیشن کے جائزے میں بہت سے عنوانات کو سطحی طور پر احاطہ کیا، کچھ کو بالکل چھوا نہیں گیا، لہذا ہمیں سوالات کے جوابات دینے میں خوشی ہوگی۔ ہم تجاویز کا انتظار کر رہے ہیں کہ کیا تفصیل سے احاطہ کیا جائے، تبصرے میں لکھیں۔
ماخذ: www.habr.com