RIT 2019 تي، اسان جي ساٿي اليگزينڊر ڪوروتڪوف ٺاهيو CIAN تي ترقي جي آٽوميشن بابت: زندگي ۽ ڪم کي آسان ڪرڻ لاءِ، اسان پنهنجو انٽيگرو پليٽ فارم استعمال ڪريون ٿا. اهو ڪمن جي زندگي جي چڪر کي ٽريڪ ڪري ٿو، روزاني آپريشن جي ڊولپرز کي رليف ڪري ٿو ۽ خاص طور تي پيداوار ۾ بگ جي تعداد کي گھٽائي ٿو. هن پوسٽ ۾، اسان اليگزينڊر جي رپورٽ کي پورو ڪنداسين ۽ توهان کي ٻڌائينداسين ته ڪيئن اسان سادي اسڪرپٽ کان وٺي پنهنجي پليٽ فارم ذريعي اوپن سورس پروڊڪٽس کي گڏ ڪرڻ ۽ اسان جي الڳ آٽوميشن ٽيم ڇا ڪري ٿي.
صفر سطح
”صفر جي سطح جهڙي ڪا به شيءِ ناهي، مون کي اهڙي ڪا خبر ناهي“
فلم "ڪنگ فو پانڊا" مان ماسٽر شيفو
CIAN تي آٽوميشن شروع ٿي 14 سال پوءِ ڪمپني ٺهڻ کان پوءِ. ان وقت ترقياتي ٽيم ۾ 35 ماڻهو هئا. يقين ڪرڻ ڏکيو، صحيح؟ يقينن، آٽوميشن ڪجهه شڪل ۾ موجود هئي، پر مسلسل انضمام ۽ ڪوڊ پهچائڻ لاء هڪ الڳ هدايت 2015 ۾ شڪل وٺڻ شروع ڪيو.
ان وقت، اسان وٽ پٿون، C# ۽ PHP جو هڪ وڏو مول هو، جيڪو لينڪس/ونڊوز سرورز تي لڳايو ويو هو. هن دانو کي ترتيب ڏيڻ لاء، اسان وٽ اسڪرپٽ جو هڪ سيٽ هو جيڪو اسان دستي طور تي هلائي ڇڏيو. اتي پڻ منوليٿ جي اسيمبلي هئي، جيڪا شاخن کي ضم ڪرڻ، خرابين کي درست ڪرڻ، ۽ تعمير ۾ "مختلف ڪمن جي مختلف سيٽن سان" تعمير ڪرڻ دوران تڪرار سبب درد ۽ مصيبت آڻيندي. هڪ آسان عمل هن طرح نظر آيو:
اسان ان سان خوش نه هئاسين، ۽ اسان هڪ ورجائي، خودڪار ۽ منظم ڪرڻ جي قابل تعمير ۽ ترتيب ڏيڻ جي عمل کي ٺاهڻ چاهيون ٿا. ان لاءِ، اسان کي هڪ CI/CD سسٽم جي ضرورت هئي، ۽ اسان ٽيم سٽي جي مفت ورزن ۽ جينڪنز جي مفت ورزن جي وچ ۾ چونڊيو، ڇاڪاڻ ته اسان انهن سان گڏ ڪم ڪيو ۽ ٻنهي ڪمن جي سيٽ جي لحاظ کان اسان لاءِ مناسب هئا. اسان ٽيم سٽي کي وڌيڪ تازو پراڊڪٽ طور چونڊيو. ان وقت، اسان اڃا تائين microservice فن تعمير کي استعمال نه ڪيو هو ۽ وڏي تعداد ۾ ڪمن ۽ منصوبن جي توقع نه ڪئي هئي.
اسان کي پنهنجي نظام جو خيال اچي ٿو
Teamcity تي عمل درآمد صرف دستي ڪم جو حصو هٽايو ويو: باقي رهي ٿو پل جي درخواستن جي پيدائش، جيرا ۾ اسٽيٽس طرفان مسئلن جي واڌاري، ۽ ڇڏڻ لاءِ مسئلن جو انتخاب. ٽيم سٽي سسٽم هاڻي هن سان مقابلو نه ڪري سگهيو. ان کي وڌيڪ automation جو رستو چونڊڻ لاء ضروري هو. اسان ٽيم سٽي ۾ اسڪرپٽ سان ڪم ڪرڻ يا ٽئين پارٽي آٽوميشن سسٽم کي تبديل ڪرڻ لاءِ اختيارن تي غور ڪيو. پر آخر ۾ اسان فيصلو ڪيو ته اسان کي وڌ ۾ وڌ لچڪ جي ضرورت آهي، جيڪا صرف اسان جو پنهنجو حل مهيا ڪري سگهي ٿي. اهڙي طرح اندروني آٽوميشن سسٽم جو پهريون نسخو انٽيگرو نالي ظاهر ٿيو.
ٽيم سٽي تعمير ۽ مقرري جي عمل کي شروع ڪرڻ جي سطح تي آٽوميشن سان واسطو رکي ٿي، جڏهن ته انٽيگرو ترقي جي عملن جي اعليٰ سطحي آٽوميشن تي ڌيان ڏنو. اهو ضروري هو ته جرا ۾ مسئلن سان ڪم کي گڏ ڪرڻ سان لاڳاپيل سورس ڪوڊ جي پروسيسنگ سان Bitbucket ۾. هن اسٽيج تي، Integro شروع ڪيو مختلف قسمن جي ڪمن سان ڪم ڪرڻ لاءِ پنهنجو ڪم فلو.
ڪاروباري عملن ۾ آٽوميشن ۾ واڌ جي ڪري، ٽيم سٽي ۾ منصوبن ۽ رن جو تعداد وڌي ويو آھي. تنهنڪري هڪ نئون مسئلو آيو: هڪ مفت ٽيم سٽي مثال ڪافي نه هو (3 ايجنٽ ۽ 100 منصوبا)، اسان هڪ ٻيو مثال شامل ڪيو (3 وڌيڪ ايجنٽ ۽ 100 منصوبا)، پوءِ ٻيو. نتيجي طور، اسان ڪيترن ئي ڪلستر جي سسٽم سان ختم ڪيو، جنهن کي منظم ڪرڻ ڏکيو هو:
جڏهن چوٿين مثال جو سوال اڀريو، اسان محسوس ڪيو ته اسان اهڙي طرح جيئرو نه ٿا رهي سگهون، ڇاڪاڻ ته 4 مثالن جي حمايت ڪرڻ جا ڪل خرچ هاڻي ڪنهن حد ۾ نه هئا. سوال پيدا ٿيو خريد ڪيل ٽيم سٽي خريد ڪرڻ يا مفت جينڪنز چونڊڻ بابت. اسان مثالن ۽ آٽوميشن منصوبن تي حساب ڪيو ۽ فيصلو ڪيو ته اسان جينڪنز تي رهنداسين. ڪجهه هفتن کان پوء، اسان جينڪنز ڏانهن تبديل ڪيو ۽ ڪيترن ئي ٽيمسٽي مثالن کي برقرار رکڻ سان لاڳاپيل ڪجهه سر درد کي ختم ڪيو. تنهن ڪري، اسان انٽيگرو کي ترقي ڪرڻ ۽ پنهنجي لاءِ جينڪنز کي ترتيب ڏيڻ تي ڌيان ڏيڻ جي قابل هئاسين.
بنيادي آٽوميشن (Pull Requests جي خودڪار ٺاھڻ جي صورت ۾، ڪوڊ ڪوريج ۽ ٻين چيڪن کي گڏ ڪرڻ ۽ شايع ڪرڻ جي صورت ۾) جي ترقيءَ سان، ھتي ھميشه ھميشه دستي رليز کي ختم ڪرڻ ۽ اھو ڪم روبوٽس کي ڏيڻ جي سخت تمنا آھي. ان کان علاوه، ڪمپني ڪمپني جي اندر microservices ڏانهن منتقل ڪرڻ شروع ڪيو، جنهن کي بار بار جاري ڪرڻ جي ضرورت آهي، ۽ هڪ ٻئي کان الڳ الڳ. اهڙيءَ طرح اسان آهستي آهستي اسان جي مائڪرو سروسز جي خودڪار رليز تي پهتاسين (اسان هن وقت عمل جي پيچيدگي جي ڪري مونولٿ کي دستي طور تي جاري ڪري رهيا آهيون). پر، جيئن عام طور تي ٿئي ٿي، هڪ نئين پيچيدگي پيدا ٿي.
اسان خودڪار ٽيسٽ
ريليز جي آٽوميشن جي ڪري، ترقياتي عمل تيز ٿي ويا آهن، جزوي طور تي ڪجهه جاچ جي مرحلن کي ڇڏڻ جي ڪري. ۽ هي معيار جي هڪ عارضي نقصان جي نتيجي ۾. اهو ٿورڙي آواز آهي، پر رليز جي تيز رفتار سان گڏ، اهو ضروري هو ته پيداوار جي ترقي جي طريقيڪار کي تبديل ڪرڻ. اهو ضروري هو ته ٽيسٽنگ جي آٽوميشن بابت سوچڻ، ذاتي ذميواري کي جنم ڏيڻ (هتي اسان ڳالهائي رهيا آهيون "هيڊ ۾ خيال کي قبول ڪرڻ"، نه ئي مالي ڏنڊ) ڊولپر جي جاري ڪيل ڪوڊ ۽ ان ۾ موجود غلطين لاءِ، انهي سان گڏ فيصلو. پاڻمرادو ڊيپلائيمينٽ ذريعي ٽاسڪ ڇڏڻ/نه ڇڏڻ.
معيار جي مسئلن کي ختم ڪندي، اسان ٻن اهم فيصلن تي آيا آهيون: اسان ڪينري ٽيسٽ ڪرڻ شروع ڪيو ۽ ان جي اضافي جي خودڪار جواب سان غلطي جي پس منظر جي خودڪار نگراني متعارف ڪرايو. پهرين حل اهو ممڪن ڪيو ته واضح غلطيون ڳولڻ کان اڳ ڪوڊ مڪمل طور تي پيداوار ۾ جاري ڪيو ويو، ٻيو پيداوار ۾ مسئلن جي جواب جي وقت کي گھٽائي ڇڏيو. غلطيون، يقينا، ٿينديون آهن، پر اسان پنهنجو گهڻو وقت ۽ ڪوشش انهن کي درست ڪرڻ تي نه، پر انهن کي گهٽائڻ تي خرچ ڪندا آهيون.
خودڪار ٽيم
اسان وٽ هن وقت 130 ڊولپرز جو اسٽاف آهي، ۽ اسان جاري رکون ٿا . مسلسل انٽيگريشن ۽ ڪوڊ ڊليوري لاءِ ٽيم (هتان بعد ۾ حوالو ڏنو ويو آهي Deploy and Integration or DI ٽيم) 7 ماڻهن تي مشتمل آهي ۽ 2 هدايتن ۾ ڪم ڪري ٿو: انٽيگرو آٽوميشن پليٽ فارم ۽ DevOps جي ترقي.
DevOps CIAN سائيٽ جي ديو/بيٽا ماحول لاءِ ذميوار آهي، انٽيگرو ماحول، ڊولپرز کي مسئلا حل ڪرڻ ۾ مدد ڪري ٿو ۽ اسڪيلنگ ماحول لاءِ نوان طريقا ٺاهي ٿو. انٽيگرو ڊولپمينٽ جي هدايت انٽيگرو پاڻ ۽ لاڳاپيل خدمتن سان واسطو رکي ٿي، مثال طور، جينڪنز، جيرا، سنگم لاءِ پلگ ان، ۽ ڊولپمينٽ ٽيمن لاءِ معاون يوٽيلٽيز ۽ ايپليڪيشنون پڻ تيار ڪري ٿي.
DI ٽيم پليٽ فارم ٽيم سان گڏجي ڪم ڪري ٿي، جيڪا اندروني طور فن تعمير، لائبريرين ۽ ترقي جي طريقن کي ترقي ڪري ٿي. ساڳئي وقت، CIAN جي اندر ڪو به ڊولپر آٽوميشن ۾ حصو وٺي سگھي ٿو، مثال طور، ٽيم جي ضرورتن کي پورو ڪرڻ لاءِ مائڪرو آٽوميشن ٺاهيو يا آٽوميشن کي اڃا به بهتر ڪيئن بڻايو وڃي ان تي هڪ بهترين خيال شيئر ڪري.
CIAN تي آٽوميشن جو پرت ڪيڪ
خودڪار ۾ شامل سڀ نظام ڪيترن ئي تہن ۾ تقسيم ڪري سگهجي ٿو:
- خارجي نظام (جيرا، بٽ بڪ، وغيره). ترقياتي ٽيمون انهن سان گڏ ڪم ڪن ٿيون.
- انٽيگرو پليٽ فارم. گهڻو ڪري، ڊولپرز ان سان سڌو سنئون ڪم نه ڪندا آهن، پر اهو آهي جيڪو سڀني آٽوميشن کي هلندو رهي ٿو.
- ترسيل، آرڪيسٽريشن ۽ دريافت جون خدمتون (مثال طور، Jeknins، Consul، Nomad). انهن جي مدد سان، اسان سرورز تي ڪوڊ لڳايو ۽ يقيني بڻايون ته خدمتون هڪ ٻئي سان ڪم ڪن ٿيون.
- جسماني پرت (سرور، او ايس، لاڳاپيل سافٽ ويئر). اسان جو ڪوڊ هن سطح تي هلندي آهي. اهو ٿي سگهي ٿو هڪ جسماني سرور يا هڪ مجازي هڪ (LXC، KVM، Docker).
هن تصور جي بنياد تي، اسان DI ٽيم جي اندر ذميواري جا علائقا ورهايون ٿا. پهرين ٻه سطحون انٽيگرو ترقي جي هدايت جي ذميواري جي علائقي ۾ آهن، ۽ آخري ٻه سطحون اڳ ۾ ئي DevOps جي ذميواري جي علائقي ۾ آهن. هي علحدگي اسان کي ڪمن تي ڌيان ڏيڻ جي اجازت ڏئي ٿي ۽ رابطي ۾ مداخلت نه ڪندو آهي، ڇاڪاڻ ته اسان هڪ ٻئي جي ويجهو آهيون ۽ مسلسل علم ۽ تجربو مٽائي رهيا آهيون.
برقرار
اچو ته Integro تي ڌيان ڏيو ۽ ٽيڪنالاجي اسٽيڪ سان شروع ڪريو:
- CentOS 7
- Docker + Nomad + Consul + Vault
- جاوا 11 (پراڻو Integro monolith جاوا 8 تي رهندو)
- اسپرنگ بوٽ 2.X + اسپرنگ Cloud Config
- PostgreSql 11
- رباب ايم
- Apache Ignite
- ڪيمنڊا (سرڪاري)
- Grafana + Graphite + Prometheus + Jaeger + ELK
- ويب UI: رد عمل (CSR) + MobX
- SSO: Keycloak
اسان مائيڪرو سروس ڊولپمينٽ جي اصول تي عمل ڪريون ٿا، جيتوڻيڪ اسان وٽ انٽيگرو جي شروعاتي ورزن جي هڪ monolith جي صورت ۾ ورثي آهي. هر مائڪرو سروس پنهنجي ڊاکر ڪنٽينر ۾ هلندو آهي، ۽ خدمتون هڪ ٻئي سان HTTP درخواستن ۽ RabbitMQ پيغامن ذريعي رابطو ڪن ٿيون. Microservices هڪ ٻئي کي Consul ذريعي ڳولهينديون آهن ۽ ان لاءِ هڪ درخواست ڪنديون آهن، ايس ايس او (Keycloak، OAuth 2/OpenID Connect) ذريعي اختيار ڏيڻ.
حقيقي زندگي جي مثال طور، جينڪنز سان لهه وچڙ تي غور ڪريو، جنهن ۾ هيٺيان قدم شامل آهن:
- ورڪ فلو مئنيجمينٽ مائڪروسروس (هتان کان پوءِ فلو مائڪرو سروس جي طور تي حوالو ڏنو ويو آهي) جينڪنز ۾ هڪ تعمير هلائڻ چاهي ٿي. هن کي ڪرڻ لاءِ، هو جينڪنز سان انضمام لاءِ مائڪرو سروس جو IP:PORT ڳولڻ لاءِ قونصل استعمال ڪري ٿو (هتي جينڪنز مائڪرو سروس جي طور تي حوالو ڏنو ويو آهي) ۽ جينڪنز ۾ تعمير شروع ڪرڻ لاءِ ان کي هڪ غير مطابقت واري درخواست موڪلي ٿو.
- هڪ درخواست حاصل ڪرڻ کان پوء، جينڪنز مائڪرو سروس ٺاهي ٿو ۽ هڪ ملازمت جي ID سان جواب ڏئي ٿو، جيڪو پوء ڪم جي نتيجي کي سڃاڻڻ لاء استعمال ڪري سگهجي ٿو. ساڳئي وقت، اهو جينڪنز ۾ تعمير کي هڪ REST API ڪال ذريعي هلائي ٿو.
- جينڪنز تعمير کي انجام ڏئي ٿو ۽، مڪمل ٿيڻ کان پوء، جينڪنز مائڪرو سروس ڏانهن عملدرآمد جي نتيجن سان گڏ هڪ ويب هک موڪلي ٿو.
- جينڪنز مائڪرو سروس، ويب هِڪ حاصل ڪري، درخواست جي پروسيسنگ جي مڪمل ٿيڻ بابت هڪ پيغام ٺاهي ٿو ۽ ان تي عملدرآمد جا نتيجا ڳنڍي ٿو. ٺاهيل پيغام RabbitMQ قطار ڏانهن موڪليو ويو آهي.
- RabbitMQ ذريعي، شايع ٿيل پيغام Flow microservice تائين پهچندو آهي، جيڪو پنهنجي ٽاسڪ کي پروسيس ڪرڻ جي نتيجي جي باري ۾ سکندو آهي درخواست ۽ وصول ڪيل پيغام مان جاب ID کي ملائيندي.
هاڻي اسان وٽ اٽڪل 30 مائڪرو سروسز آهن، جن کي ڪيترن ئي گروپن ۾ ورهائي سگهجي ٿو:
- ترتيب ڏيڻ جو انتظام.
- معلومات ۽ استعمال ڪندڙن سان رابطي (ميسينجر، ميل).
- سورس ڪوڊ سان ڪم ڪرڻ.
- لڳائڻ جي اوزارن سان انضمام (جينڪنز، ڪومڊ، قونصل، وغيره).
- مانيٽرنگ (رليز، غلطيون، وغيره).
- ويب يوٽيلٽيز (UI ٽيسٽ ماحول کي منظم ڪرڻ، انگ اکر گڏ ڪرڻ، وغيره).
- ٽاسڪ ٽريڪرز ۽ ساڳئي سسٽم سان انضمام.
- مختلف ڪمن لاء ڪم فلو انتظام.
ڪم فلو ڪم
انٽيگرو ٽاسڪ لائف سائيڪل سان لاڳاپيل سرگرمين کي خودڪار ڪري ٿو. آسان اصطلاحن ۾، هڪ ڪم جي زندگي جي چڪر کي سمجھيو ويندو جيرا ۾ ڪم جي ڪم جي فلو. اسان جي ڊولپمينٽ جي عملن ۾ ڪيترائي ڪم فلو مختلف تبديليون آھن پراجيڪٽ جي لحاظ کان، ڪم جي قسم ۽ خاص ڪم ۾ چونڊيل اختيارن.
اچو ته ڪم جي فلو کي ڏسو جيڪو اسان اڪثر استعمال ڪندا آهيون:
ڊراگرام ۾، گيئر اشارو ڪري ٿو ته منتقلي کي سڏيو ويندو آهي خودڪار طريقي سان Integro، جڏهن ته انساني شڪل ظاهر ڪري ٿو ته منتقلي کي دستي طور تي سڏيو ويندو آهي هڪ شخص طرفان. اچو ته ڪيترن ئي رستن تي نظر رکون ٿا جيڪو ڪم هن ڪم فلو ۾ وٺي سگھي ٿو.
مڪمل طور تي دستياب ٽيسٽنگ DEV + BETA تي بغير ڪينيري ٽيسٽن جي (عام طور تي هن طريقي سان اسان هڪ مونولٿ کي جاري ڪندا آهيون):
اتي ٿي سگھي ٿو ٻيا منتقلي مجموعا. ڪڏهن ڪڏهن رستو جيڪو هڪ مسئلو کڻندو جيرا ۾ اختيارن ذريعي چونڊيو وڃي ٿو.
ڪم تحريڪ
اچو ته مکيه مرحلن تي نظر رکون جيڪي انجام ڏنا ويندا آهن جڏهن هڪ ڪم "DEV ٽيسٽنگ + ڪينري ٽيسٽ" ورڪ فلو ذريعي هلندو آهي:
1. ڊولپر يا پي ايم ڪم ٺاهي ٿو.
2. ڊولپر ڪم ڪرڻ لاء ڪم وٺندو آهي. مڪمل ٿيڻ کان پوء، ان کي تبديل ڪري ٿو جائزو جي حالت ۾.
3. جيرا هڪ ويب بڪ موڪلي ٿو جيرا مائڪرو سروس ڏانهن (جيرا سان انضمام لاءِ ذميوار).
4. جيرا مائڪرو سروس فلو سروس کي هڪ درخواست موڪلي ٿو (اندروني ڪم جي فلوز لاءِ ذميوار آهي جنهن ۾ ڪم ڪيو ويندو آهي) ڪم فلو شروع ڪرڻ لاءِ.
5. فلو سروس جي اندر:
- نظر ثاني ڪندڙ کي ڪم تي لڳايو ويو آهي (استعمال ڪندڙ microservice جيڪي صارفين بابت سڀ ڪجهه ڄاڻن ٿا + جيرا مائڪرو سروس).
- ذريعن جي microservice ذريعي (اهو ذخيرن ۽ شاخن جي باري ۾ ڄاڻي ٿو، پر ڪوڊ سان گڏ ڪم نه ڪندو آهي)، هڪ ڳولها مخزن جي لاء ڪئي وئي آهي جنهن ۾ اسان جي مسئلي جي هڪ شاخ شامل آهي (ڳولا کي آسان ڪرڻ لاء، شاخ جو نالو مسئلو سان ٺهڪي اچي ٿو. جيرا ۾ نمبر). گهڻو ڪري، هڪ ڪم ۾ صرف هڪ شاخ آهي هڪ مخزن ۾؛ هي ترتيب ڏيڻ واري قطار جي انتظام کي آسان بڻائي ٿو ۽ مخزن جي وچ ۾ رابطي کي گھٽائي ٿو.
- هر مليل شاخ لاءِ، عملن جو هيٺيون سلسلو ڪيو ويندو آهي:
i) ماسٽر برانچ کي اپڊيٽ ڪرڻ (گٽ مائڪرو سروس ڪوڊ سان ڪم ڪرڻ لاءِ).
ii) برانچ ڊولپر طرفان تبديلين کان روڪيو ويو آهي (Bitbucket microservice).
iii) هن برانچ (Bitbucket microservice) لاءِ پل جي درخواست ٺاهي وئي آهي.
iv) نئين پل جي درخواست بابت هڪ پيغام ڊولپر چيٽس ڏانهن موڪليو ويو آهي (اطلاعات سان ڪم ڪرڻ لاءِ مائڪرو سروس کي اطلاع ڏيو).
v) ٺاھڻ، ٽيسٽ ۽ ترتيب ڏيڻ وارا ڪم DEV تي شروع ڪيا ويا آھن (جينڪنز سان ڪم ڪرڻ لاءِ جينڪنز مائڪرو سروس).
vi) جيڪڏهن سڀ پوئين مرحلا ڪاميابيءَ سان مڪمل ٿي ويا، ته پوءِ انٽيگرو ان جي منظوري کي پل جي درخواست ۾ رکي ٿو (Bitbucket microservice). - انٽيگرو نامزد ٿيل نظرثاني ڪندڙن کان پل درخواست ۾ منظوري جو انتظار ڪري ٿو.
- جيئن ئي تمام ضروري منظوريون مليون (بشمول خودڪار ٽيسٽون مثبت طور تي گذري ويون)، انٽيگرو ٽاسڪ کي ديو (جيرا مائڪرو سروس) اسٽيٽس تي ٽيسٽ منتقل ڪري ٿو.
6. جاچ ڪندڙ ڪم کي جانچيندا آهن. جيڪڏهن ڪو مسئلو ناهي، ته پوء ڪم کي منتقل ڪيو ويو آهي تيار ڪرڻ لاء تيار ڪيل صورتحال.
7. انٽيگرو ”ڏسي ٿو“ ته اهو ڪم رليز لاءِ تيار آهي ۽ ڪينري موڊ (جينڪنز مائڪرو سروس) ۾ ان جي ڊيپلائيمينٽ شروع ڪري ٿو. ڇڏڻ جي تياري ضابطن جي هڪ سيٽ جي ذريعي طئي ڪيو ويندو آهي. مثال طور، ڪم گهربل حالت ۾ آهي، ٻين ڪمن تي ڪو به تالا نه آهن، في الحال هن microservice جي ڪي به فعال اپلوڊ نه آهن، وغيره.
8. ڪم کي ڪينري جي حيثيت ۾ منتقل ڪيو ويو آهي (جيرا مائڪرو سروس).
9. جينڪنز ڪينري موڊ (عام طور تي 1-3 مثالن) ۾ Nomad ذريعي ڊيپلائيمينٽ ٽاسڪ شروع ڪري ٿو ۽ رليز مانيٽرنگ سروس (DeployWatch microservice) کي ڊيپلائيمينٽ بابت اطلاع ڏئي ٿو.
10. DeployWatch microservice غلطي جي پس منظر کي گڏ ڪري ٿو ۽ ان کي رد ڪري ٿو، جيڪڏهن ضروري هجي. جيڪڏهن غلطي جي پس منظر کان وڌي وئي آهي (پس منظر جو معيار خودڪار طريقي سان ڳڻيو ويندو آهي)، ڊولپرز کي اطلاع ڏنو ويو آهي Microsoft microservice ذريعي. جيڪڏهن 5 منٽن کان پوءِ ڊولپر جواب نه ڏنو آهي (ڪلڪ ڪيو واپس وڃو يا رکو)، پوءِ ڪينري مثالن جو هڪ خودڪار رول بيڪ شروع ڪيو ويندو. جيڪڏهن پس منظر کان وڌيڪ نه آهي، پوء ڊولپر کي دستي طور تي شروع ڪرڻ گهرجي ٽاسڪ ڊيپلائيشن کي پيداوار ڏانهن (UI ۾ هڪ بٽڻ تي ڪلڪ ڪندي). جيڪڏهن 60 منٽن اندر ڊولپر پيداوار لاءِ ڊيپلائيمينٽ شروع نه ڪئي آهي، ته پوءِ ڪينري جا واقعا به حفاظتي سببن لاءِ واپس ورتا ويندا.
11. پيداوار لاءِ ڊيپلائيمينٽ شروع ڪرڻ کان پوءِ:
- ڪم پيداوار جي حيثيت (جيرا microservice) ڏانهن منتقل ڪيو ويو آهي.
- Jenkins microservice deployment process کي شروع ڪري ٿو ۽ DeployWatch microservice کي ڊيپلائيمينٽ بابت اطلاع ڏئي ٿو.
- DeployWatch microservice چيڪ ڪري ٿو ته پيداوار تي سڀئي ڪنٽينر اپڊيٽ ڪيا ويا آهن (اهڙا ڪيس هئا جڏهن سڀ اپڊيٽ نه ڪيا ويا).
- نوٽيفڪيشن مائڪرو سروس ذريعي، تعیناتي جي نتيجن بابت هڪ نوٽيفڪيشن پيداوار ڏانهن موڪليو ويو آهي.
12. ڊولپرز وٽ 30 منٽ ھوندا آھن پروڊڪشن مان ھڪڙي ڪم کي واپس ڪرڻ شروع ڪرڻ لاءِ جيڪڏھن غلط microservice رويي جو پتو پوي ٿو. هن وقت کان پوء، ڪم خودڪار طريقي سان ماسٽر (Git microservice) ۾ ضم ٿي ويندو.
13. ماسٽر ۾ ڪامياب ضم ٿيڻ کان پوء، ٽاسڪ اسٽيٽس کي بند ڪيو ويندو (جيرا مائڪرو سروس).
ڊراگرام مڪمل طور تي تفصيلي ٿيڻ جو ارادو نٿو ڪري (حقيقت ۾ اڃا به وڌيڪ مرحلا آهن)، پر اهو توهان کي پروسيس ۾ انضمام جي درجي جو اندازو لڳائڻ جي اجازت ڏئي ٿو. اسان هن اسڪيم کي مثالي نه ٿا سمجهون ۽ خودڪار رليز ۽ ڊيپلائيمينٽ سپورٽ جي عمل کي بهتر ڪري رهيا آهيون.
ايندڙ ڇا آهي
اسان وٽ آٽوميشن جي ترقي لاءِ وڏا منصوبا آهن، مثال طور، مينولٿ رليز دوران مينوئل آپريشنز کي ختم ڪرڻ، خودڪار ڊيپلائيمينٽ دوران نگراني کي بهتر بڻائڻ، ۽ ڊولپرز سان رابطي کي بهتر بڻائڻ.
پر اچو ته ھاڻي ھتي رکون. اسان ڪيترن ئي عنوانن کي شامل ڪيو آٽوميشن جي جائزي ۾ سپرفيشل طور تي، ڪجهه کي هٿ نه ڪيو ويو، تنهنڪري اسان سوالن جا جواب ڏيڻ ۾ خوش ٿينداسين. اسان تجويزن جو انتظار ڪري رهيا آهيون ته تفصيل سان ڇا ڪجي، تبصرن ۾ لکندا.
جو ذريعو: www.habr.com