DevOps مشقیں کام کرتی ہیں۔ جب ہم نے ریلیز کی تنصیب کا وقت 10 گنا کم کیا تو ہمیں خود اس کا یقین ہو گیا۔ FIS پروفائل سسٹم میں، جسے ہم VTB میں استعمال کرتے ہیں، انسٹالیشن میں اب 90 کے بجائے 10 منٹ لگتے ہیں۔ ریلیز بنانے کا وقت دو ہفتوں سے کم ہو کر دو دن ہو گیا ہے۔ مسلسل نفاذ کے نقائص کی تعداد تقریباً کم سے کم رہ گئی ہے۔ "دستی مزدوری" سے دور ہونے اور دکاندار پر انحصار ختم کرنے کے لیے، ہمیں بیساکھیوں کے ساتھ کام کرنا پڑا اور غیر متوقع حل تلاش کرنا پڑے۔ کٹ کے نیچے ایک تفصیلی کہانی ہے کہ ہم نے ایک مکمل داخلی ترقی کیسے بنائی۔
Prologue: DevOps ایک فلسفہ ہے۔
پچھلے ایک سال کے دوران، ہم نے VTB میں DevOps طریقوں کی اندرونی ترقی اور نفاذ کو منظم کرنے کے لیے بہت کام کیا ہے:
- ہم نے 12 نظاموں کے لیے اندرونی ترقی کے عمل بنائے۔
- ہم نے 15 پائپ لائنیں شروع کیں، جن میں سے چار پروڈکشن کے لیے لائی گئیں۔
- خودکار 1445 ٹیسٹ منظرنامے؛
- ہم نے اندرون ملک ٹیموں کے ذریعہ تیار کردہ متعدد ریلیز کو کامیابی کے ساتھ نافذ کیا۔
ان ہاؤس ڈویلپمنٹ کو منظم کرنے اور DevSecOps کے طریقوں پر عمل درآمد کرنے میں سب سے مشکل میں سے ایک FIS پروفائل سسٹم نکلا - ایک غیر متعلقہ DBMS پر ایک خوردہ پروڈکٹ پروسیسر۔ اس کے باوجود، ہم ترقی کو بنانے، پائپ لائن شروع کرنے، پروڈکٹ پر انفرادی نان ریلیز پیکجز انسٹال کرنے، اور ریلیز کو جمع کرنے کا طریقہ سیکھنے میں کامیاب رہے۔ یہ کام آسان نہیں تھا، لیکن دلچسپ اور نفاذ میں واضح پابندیوں کے بغیر: یہ نظام ہے - آپ کو اندرون ملک ترقی کی ضرورت ہے۔ صرف شرط یہ ہے کہ سی ڈی کو پیداواری ماحول سے پہلے استعمال کیا جائے۔
سب سے پہلے، عمل درآمد الگورتھم سادہ اور واضح لگ رہا تھا:
- ہم ابتدائی ترقی کی مہارت کو تیار کرتے ہیں اور کوڈ ٹیم سے مجموعی نقائص کے بغیر قابل قبول معیار حاصل کرتے ہیں۔
- ہم موجودہ عمل میں جتنا ممکن ہو انضمام کرتے ہیں۔
- واضح مراحل کے درمیان کوڈ کی منتقلی کے لیے، ہم ایک پائپ لائن کاٹتے ہیں اور اس کے ایک سرے کو تسلسل میں دھکیل دیتے ہیں۔
اس وقت کے دوران، مطلوبہ سائز کی ڈیولپمنٹ ٹیم کو مہارتوں کی نشوونما کرنی چاہیے اور ریلیز کے لیے اپنی شراکت کا حصہ ایک قابل قبول سطح تک بڑھانا چاہیے۔ اور بس، ہم کام کو مکمل کرنے پر غور کر سکتے ہیں۔
ایسا لگتا ہے کہ یہ مطلوبہ نتیجہ کے لیے مکمل طور پر توانائی سے بھرپور راستہ ہے: یہاں DevOps ہے، یہاں ٹیم کی کارکردگی کے میٹرکس ہیں، یہاں جمع کردہ مہارت ہے... لیکن عملی طور پر، ہمیں ایک اور تصدیق ملی کہ DevOps ابھی بھی فلسفے کے بارے میں ہے۔ ، اور "گٹ لیب کے عمل سے منسلک نہیں، جوابدہ، گٹھ جوڑ اور فہرست میں مزید نیچے۔"
ایک بار پھر ایکشن پلان کا تجزیہ کرنے کے بعد، ہم نے محسوس کیا کہ ہم اپنے اندر ایک قسم کا آؤٹ سورس وینڈر بنا رہے ہیں۔ لہذا، اوپر بیان کردہ الگورتھم میں پروسیس ری انجینیئرنگ کو شامل کیا گیا، اور ساتھ ہی اس عمل میں ایک اہم کردار حاصل کرنے کے لیے پورے ترقیاتی راستے کے ساتھ مہارت کی نشوونما کی گئی۔ سب سے آسان آپشن نہیں، لیکن یہ نظریاتی طور پر درست ترقی کا راستہ ہے۔
اندرونی ترقی کہاں سے شروع ہوتی ہے؟
یہ کام کرنے کے لیے سب سے زیادہ دوستانہ نظام نہیں تھا۔ آرکیٹیکچرل طور پر، یہ ایک بڑا غیر متعلقہ ڈی بی ایم ایس تھا، جس میں بہت سی الگ الگ قابل عمل اشیاء (اسکرپٹ، طریقہ کار، بیچز وغیرہ) پر مشتمل تھا، جنہیں ضرورت کے مطابق بلایا جاتا تھا، اور بلیک باکس کے اصول پر کام کیا جاتا تھا: اسے ایک درخواست اور مسائل موصول ہوتے ہیں۔ ایک جواب. قابل توجہ دیگر مشکلات میں شامل ہیں:
- غیر ملکی زبان (MUMPS)؛
- کنسول انٹرفیس؛
- مقبول آٹومیشن ٹولز اور فریم ورک کے ساتھ انضمام کی کمی؛
- دسیوں ٹیرا بائٹس میں ڈیٹا کا حجم؛
- فی گھنٹہ 2 ملین سے زیادہ آپریشنز کا بوجھ؛
- اہمیت - کاروبار - اہم.
اسی وقت، ہماری طرف کوئی سورس کوڈ ذخیرہ نہیں تھا۔ بالکل. دستاویزات موجود تھیں، لیکن تمام کلیدی علم اور قابلیت ایک بیرونی تنظیم کی طرف تھی۔
ہم نے اس کی خصوصیات اور کم تقسیم کو مدنظر رکھتے ہوئے تقریباً شروع سے ہی نظام کی ترقی میں مہارت حاصل کرنا شروع کر دی۔ اکتوبر 2018 میں شروع ہوا:
- کوڈ جنریشن کی دستاویزات اور بنیادی باتوں کا مطالعہ کیا۔
- ہم نے وینڈر سے حاصل کردہ ترقی پر مختصر کورس کا مطالعہ کیا۔
- ابتدائی ترقی کی مہارت میں مہارت حاصل کی؛
- ہم نے ٹیم کے نئے ارکان کے لیے تربیتی کتابچہ مرتب کیا۔
- ہم نے ٹیم کو "جنگی" موڈ میں شامل کرنے پر اتفاق کیا۔
- کوڈ کوالٹی کنٹرول کے ساتھ مسئلہ حل کیا؛
- ہم نے ترقی کے لیے ایک موقف ترتیب دیا۔
ہم نے مہارت پیدا کرنے اور خود کو سسٹم میں غرق کرنے میں تین ماہ گزارے، اور 2019 کے آغاز سے، اندرونی ترقی نے ایک روشن مستقبل کی طرف اپنی تحریک شروع کی، بعض اوقات مشکل کے ساتھ، لیکن اعتماد اور مقصد کے ساتھ۔
ذخیرہ منتقلی اور آٹو ٹیسٹس
پہلا DevOps ٹاسک ریپوزٹری ہے۔ ہم نے فوری طور پر رسائی فراہم کرنے پر اتفاق کیا، لیکن موجودہ SVN سے متعدد شاخوں کے ماڈل میں منتقلی اور گٹ فلو کی ترقی کے ساتھ ایک ٹرنک برانچ کے ساتھ ہمارے ٹارگٹ Git میں منتقل ہونا ضروری تھا۔ ہمارے پاس 2 ٹیمیں بھی ہیں جن کا اپنا بنیادی ڈھانچہ ہے، نیز بیرون ملک وینڈرز ٹیم کا حصہ ہے۔ مجھے دو Gits کے ساتھ رہنا تھا اور ہم آہنگی کو یقینی بنانا تھا۔ ایسی حالت میں یہ دو برائیوں سے کم تھی۔
مخزن کی منتقلی کو بار بار ملتوی کیا گیا، یہ فرنٹ لائن کے ساتھیوں کی مدد سے اپریل میں ہی مکمل ہوا۔ Git Flow کے ساتھ، ہم نے شروعات کے لیے چیزوں کو آسان رکھنے کا فیصلہ کیا اور ہاٹ فکس، ڈیولپ اور ریلیز کے ساتھ کلاسک اسکیم پر طے کیا۔ انہوں نے ماسٹر (عرف پروڈ کی طرح) کو ترک کرنے کا فیصلہ کیا۔ ذیل میں ہم وضاحت کریں گے کہ یہ آپشن ہمارے لیے بہترین کیوں نکلا۔ وینڈر سے تعلق رکھنے والا ایک بیرونی ذخیرہ، جو دو ٹیموں کے لیے عام تھا، بطور کارکن استعمال ہوتا تھا۔ یہ ایک شیڈول کے مطابق اندرونی ذخیرہ کے ساتھ مطابقت پذیر ہے۔ اب Git اور Gitlab کے ساتھ عمل کو خودکار کرنا ممکن تھا۔
آٹو ٹیسٹ کا مسئلہ حیرت انگیز طور پر آسانی سے حل ہو گیا تھا - ہمیں ایک تیار فریم ورک فراہم کیا گیا تھا۔ سسٹم کی خصوصیات کو مدنظر رکھتے ہوئے، علیحدہ آپریشن کو کال کرنا کاروباری عمل کا ایک قابل فہم حصہ تھا اور ساتھ ہی یہ یونٹ ٹیسٹ کے طور پر بھی کام کرتا تھا۔ صرف ٹیسٹ ڈیٹا تیار کرنا اور اسکرپٹ کو کال کرنے اور نتائج کا جائزہ لینے کا مطلوبہ ترتیب ترتیب دینا باقی تھا۔ جیسا کہ منظرناموں کی فہرست، آپریشن کے اعدادوشمار کی بنیاد پر تشکیل دی گئی، عمل کی تنقیدی اور موجودہ رجعت کے طریقہ کار کو پُر کیا گیا، خودکار ٹیسٹ سامنے آنے لگے۔ اب ہم پائپ لائن کی تعمیر شروع کر سکتے ہیں۔
یہ کیسا تھا: آٹومیشن سے پہلے کا ماڈل
عمل درآمد کا موجودہ ماڈل ایک الگ کہانی ہے۔ ہر ترمیم کو دستی طور پر ایک علیحدہ اضافی تنصیب پیکج کے طور پر منتقل کیا گیا تھا۔ اس کے بعد جیرا میں دستی رجسٹریشن اور ماحولیات پر دستی تنصیب ہوئی۔ انفرادی پیکجوں کے لئے، سب کچھ واضح نظر آتا ہے، لیکن رہائی کی تیاری کے ساتھ، چیزیں زیادہ پیچیدہ تھیں.
اسمبلی انفرادی ترسیل کی سطح پر کی گئی تھی، جو آزاد اشیاء تھیں۔ کوئی بھی تبدیلی ایک نئی ترسیل ہے۔ دیگر چیزوں کے علاوہ، مرکزی ریلیز کمپوزیشن کے 60-70 پیکجز میں 10-15 تکنیکی ورژن شامل کیے گئے تھے - وہ ورژن جو ریلیز میں کسی چیز کو شامل یا خارج کرتے وقت حاصل کیے گئے تھے اور ریلیز کے باہر فروخت میں تبدیلیوں کی عکاسی کرتے تھے۔
ڈیلیوری کے اندر موجود اشیاء ایک دوسرے کے ساتھ اوورلیپ ہوتی ہیں، خاص طور پر قابل عمل کوڈ میں، جو نصف سے بھی کم منفرد تھا۔ پہلے سے نصب شدہ کوڈ پر اور جس کی تنصیب کا ابھی منصوبہ بنایا گیا تھا دونوں پر بہت سے انحصار تھے۔
کوڈ کے مطلوبہ ورژن کو حاصل کرنے کے لیے، انسٹالیشن آرڈر پر سختی سے عمل کرنا ضروری تھا، جس کے دوران اشیاء کو جسمانی طور پر کئی بار، تقریباً 10-12 بار لکھا گیا۔
پیکجوں کے بیچ کو انسٹال کرنے کے بعد، مجھے ترتیبات کو شروع کرنے کے لیے دستی طور پر ہدایات پر عمل کرنا پڑا۔ ریلیز کو وینڈر کے ذریعہ جمع اور انسٹال کیا گیا تھا۔ ریلیز کی ساخت کو نفاذ کے لمحے سے پہلے ہی واضح کیا گیا تھا، جس میں "ڈیکپلنگ" پیکجز کی تخلیق شامل تھی۔ نتیجے کے طور پر، سپلائیز کا ایک اہم حصہ "ڈیکپلنگز" کی اپنی دم کے ساتھ رہائی سے رہائی کی طرف چلا گیا۔
اب یہ واضح ہے کہ اس نقطہ نظر سے - پیکیج کی سطح پر ریلیز پہیلی کو جمع کرنا - ایک واحد ماسٹر برانچ کا کوئی عملی معنی نہیں تھا۔ پیداوار پر تنصیب میں ڈیڑھ سے دو گھنٹے تک دستی مشقت لی گئی۔ یہ اچھی بات ہے کہ کم از کم انسٹالر کی سطح پر آبجیکٹ پروسیسنگ کی ترتیب کی وضاحت کی گئی تھی: فیلڈز اور ڈھانچے کو ان کے ڈیٹا اور طریقہ کار سے پہلے درج کیا گیا تھا۔ تاہم، یہ صرف ایک علیحدہ پیکیج کے اندر کام کرتا ہے۔
اس نقطہ نظر کا منطقی نتیجہ اشیاء کے ٹیڑھے ورژن، غیر ضروری کوڈ، گمشدہ ہدایات اور اشیاء کے باہمی اثر و رسوخ کے لیے غیر حساب کتاب کی صورت میں انسٹالیشن کے لازمی نقائص تھے، جنہیں رہائی کے بعد بخار کے ساتھ ختم کر دیا گیا تھا۔
پہلی اپ ڈیٹس: اسمبلی اور ترسیل کا عہد کریں۔
آٹومیشن کا آغاز اس راستے پر پائپ کے ذریعے کوڈ منتقل کرنے سے ہوا:
- اسٹوریج سے تیار شدہ ڈیلیوری اٹھاو؛
- اسے ایک سرشار ماحول پر انسٹال کریں۔
- آٹو ٹیسٹ چلائیں؛
- تنصیب کے نتائج کا اندازہ کریں؛
- ٹیسٹنگ کمانڈ کے سائیڈ پر درج ذیل پائپ لائن کو کال کریں۔
اگلی پائپ لائن کو جیرا میں ٹاسک کو رجسٹر کرنا چاہیے اور منتخب ٹیسٹنگ لوپس پر کمانڈز کی تقسیم کا انتظار کرنا چاہیے، جو ٹاسک کے نفاذ کے وقت پر منحصر ہے۔ ٹرگر - دیے گئے پتے پر ترسیل کی تیاری کے بارے میں ایک خط۔ یہ، یقیناً، ایک واضح بیساکھی تھی، لیکن مجھے کہیں سے شروع کرنا تھا۔ مئی 2019 میں، کوڈ کی منتقلی ہمارے ماحول کی جانچ کے ساتھ شروع ہوئی۔ عمل شروع ہو چکا ہے، بس اسے مہذب شکل میں لانا باقی ہے:
- ہر ترمیم ایک الگ برانچ میں کی جاتی ہے، جو کہ انسٹالیشن پیکج سے مطابقت رکھتی ہے اور ٹارگٹ ماسٹر برانچ میں ضم ہوجاتی ہے۔
- پائپ لائن لانچ ٹرگر انضمام کی درخواست کے ذریعے ماسٹر برانچ میں ایک نئی کمٹ کی ظاہری شکل ہے، جسے ان ہاؤس ٹیم کے مینٹینرز نے بند کر دیا ہے۔
- ذخیرے ہر پانچ منٹ میں ایک بار ہم آہنگ ہوتے ہیں۔
- انسٹالیشن پیکج کی اسمبلی شروع ہو گئی ہے - وینڈر سے موصول ہونے والے اسمبلر کا استعمال کرتے ہوئے۔
اس کے بعد، کوڈ کو چیک کرنے اور ٹرانسفر کرنے، پائپ کو لانچ کرنے اور ہماری طرف جمع کرنے کے لیے پہلے سے موجود اقدامات موجود تھے۔
یہ آپشن جولائی میں شروع کیا گیا تھا۔ منتقلی کی مشکلات کے نتیجے میں وینڈر اور فرنٹ لائن میں کچھ عدم اطمینان پیدا ہوا، لیکن اگلے مہینے میں ہم نے تمام ناہموار کناروں کو ہٹا دیا اور ٹیموں کے درمیان ایک عمل قائم کیا۔ اب ہمارے پاس کمٹ اور ڈیلیوری کے ذریعہ اسمبلی ہے۔
اگست میں، ہم اپنی پائپ لائن کا استعمال کرتے ہوئے پروڈکشن پر ایک علیحدہ پیکج کی پہلی تنصیب کو مکمل کرنے میں کامیاب ہوئے، اور ستمبر سے، بغیر کسی استثناء کے، انفرادی نان ریلیز پیکجز کی تمام تنصیبات ہمارے CD ٹول کے ذریعے انجام دی گئیں۔ اس کے علاوہ، ہم وینڈر سے چھوٹی ٹیم کے ساتھ ریلیز کمپوزیشن کے 40% میں اندرون خانہ کاموں کا حصہ حاصل کرنے میں کامیاب ہوئے - یہ ایک یقینی کامیابی ہے۔ سب سے زیادہ سنگین کام رہا - ریلیز کو جمع اور انسٹال کرنا۔
حتمی حل: مجموعی انسٹالیشن پیکجز
ہم بخوبی سمجھ گئے تھے کہ وینڈر کی ہدایات کو اسکرپٹ کرنا ایک ایسا آٹومیشن تھا؛ ہمیں خود اس عمل پر دوبارہ غور کرنا تھا۔ حل واضح تھا - ریلیز برانچ سے مطلوبہ ورژن کی تمام اشیاء کے ساتھ مجموعی سپلائی جمع کرنا۔
ہم نے تصور کے ثبوت کے ساتھ آغاز کیا: ہم نے ماضی کے نفاذ کے مواد کے مطابق ریلیز پیکیج کو ہاتھ سے اسمبل کیا اور اسے اپنے ماحول پر انسٹال کیا۔ سب کچھ کام ہوا، تصور قابل عمل نکلا۔ اگلا، ہم نے ابتدائی ترتیبات کو اسکرپٹ کرنے اور انہیں کمٹ میں شامل کرنے کے مسئلے کو حل کیا۔ ہم نے ایک نیا پیکج تیار کیا اور کونٹور اپ ڈیٹ کے حصے کے طور پر اسے ٹیسٹنگ ماحول میں آزمایا۔ تنصیب کامیاب رہی، اگرچہ عمل درآمد کرنے والی ٹیم کے تبصروں کی ایک وسیع رینج کے ساتھ۔ لیکن اہم بات یہ ہے کہ ہمیں نومبر کی ریلیز میں اپنی اسمبلی کے ساتھ پروڈکشن میں جانے کی اجازت دی گئی۔
ابھی صرف ایک ماہ باقی رہ گیا ہے، ہاتھ سے اٹھائے گئے سامان نے واضح طور پر اشارہ کیا کہ وقت ختم ہو رہا ہے۔ انہوں نے ریلیز برانچ سے تعمیر کرنے کا فیصلہ کیا، لیکن اسے کیوں الگ کیا جائے؟ ہمارے پاس پروڈ جیسا نہیں ہے، اور موجودہ شاخیں اچھی نہیں ہیں - بہت سارے غیر ضروری کوڈ ہیں۔ ہمیں فوری طور پر پروڈ لائکس کو کم کرنے کی ضرورت ہے، اور یہ تین ہزار سے زیادہ کمٹ ہے۔ ہاتھ سے جمع کرنا کوئی آپشن نہیں ہے۔ ہم نے ایک اسکرپٹ کا خاکہ تیار کیا جو پروڈکٹ انسٹالیشن لاگ کے ذریعے چلتا ہے اور برانچ کو کمٹ جمع کرتا ہے۔ تیسری بار اس نے صحیح طریقے سے کام کیا، اور "فائل کے ساتھ ختم" کے بعد برانچ تیار ہو گئی۔
ہم نے انسٹالیشن پیکج کے لیے اپنے بلڈر کو لکھا اور اسے ایک ہفتے میں مکمل کر لیا۔ پھر ہمیں سسٹم کی بنیادی فعالیت سے انسٹالر کو تبدیل کرنا پڑا، کیونکہ یہ اوپن سورس ہے۔ چیک اور ترمیم کی ایک سیریز کے بعد، نتیجہ کامیاب سمجھا گیا تھا. اس دوران، ریلیز کی ساخت نے شکل اختیار کی، جس کی درست تنصیب کے لیے ٹیسٹ سرکٹ کو پروڈکشن ون کے ساتھ سیدھا کرنا ضروری تھا، اور اس کے لیے ایک الگ اسکرپٹ لکھا گیا تھا۔
قدرتی طور پر، پہلی تنصیب کے بارے میں بہت سارے تبصرے تھے، لیکن مجموعی طور پر کوڈ نے کام کیا۔ اور تیسری تنصیب کے بعد سب کچھ اچھا لگنا شروع ہو گیا۔ اشیاء کے کمپوزیشن کنٹرول اور ورژن کنٹرول کو دستی موڈ میں الگ الگ مانیٹر کیا گیا، جو اس مرحلے پر کافی حد تک جائز تھا۔
ایک اضافی چیلنج غیر ریلیز کی بڑی تعداد تھا جس کو مدنظر رکھنا تھا۔ لیکن پروڈ نما شاخ اور ریبیس کے ساتھ، کام شفاف ہو گیا۔
پہلی بار، جلدی اور غلطیوں کے بغیر
ہم نے ایک پر امید رویہ اور مختلف سرکٹس پر ایک درجن سے زیادہ کامیاب تنصیبات کے ساتھ ریلیز تک رسائی حاصل کی۔ لیکن لفظی طور پر آخری تاریخ سے ایک دن پہلے، یہ پتہ چلا کہ وینڈر نے قبول شدہ طریقے سے تنصیب کے لیے ریلیز تیار کرنے کا کام مکمل نہیں کیا تھا۔ اگر کسی وجہ سے ہماری تعمیر کام نہیں کرتی ہے، تو ریلیز میں خلل پڑ جائے گا۔ اس کے علاوہ، ہماری کوششوں کے ذریعے، جو خاص طور پر ناخوشگوار ہے. ہمارے پاس پیچھے ہٹنے کا کوئی راستہ نہیں تھا۔ لہذا، ہم نے متبادل آپشنز کے ذریعے سوچا، ایکشن پلان تیار کیا اور تنصیب شروع کی۔
حیرت انگیز طور پر، 800 سے زیادہ اشیاء پر مشتمل پوری ریلیز، پہلی بار اور صرف 10 منٹ میں درست طریقے سے شروع ہوئی۔ ہم نے ایک گھنٹہ لاگوں کی جانچ پڑتال میں غلطیوں کی تلاش میں گزارا، لیکن کوئی پتہ نہیں چلا۔
اگلے دن ریلیز چیٹ میں خاموشی چھائی رہی: نفاذ میں کوئی دشواری، ٹیڑھے ورژن یا "نامناسب" کوڈ نہیں۔ یہاں تک کہ یہ کسی حد تک عجیب تھا۔ بعد میں، کچھ تبصرے سامنے آئے، لیکن دوسرے سسٹمز اور سابقہ تجربے کے مقابلے ان کی تعداد اور ترجیح نمایاں طور پر کم تھی۔
مجموعی اثر سے ایک اضافی اثر اسمبلی اور جانچ کے معیار میں اضافہ تھا۔ مکمل ریلیز کی متعدد تنصیبات کی وجہ سے، تعمیراتی نقائص اور تعیناتی کی غلطیوں کی بروقت نشاندہی کی گئی۔ مکمل ریلیز کنفیگریشن میں ٹیسٹنگ نے اضافی تنصیبات کے دوران ظاہر نہ ہونے والی اشیاء کے باہمی اثر و رسوخ میں نقائص کی نشاندہی کرنا ممکن بنایا۔ یہ یقینی طور پر ایک کامیابی تھی، خاص طور پر ریلیز میں ہمارے 57٪ شراکت کو دیکھتے ہوئے.
خلاصہ اور نتائج
ایک سال سے بھی کم عرصے میں ہم اس میں کامیاب ہو گئے:
- ایک غیر ملکی نظام کا استعمال کرتے ہوئے ایک مکمل داخلی ترقی کی تعمیر؛
- اہم وینڈر انحصار کو ختم کریں؛
- انتہائی غیر دوستانہ میراث کے لیے CI/CD لانچ کریں۔
- نفاذ کے عمل کو ایک نئی تکنیکی سطح تک بڑھانا؛
- تعیناتی کے وقت کو نمایاں طور پر کم کریں؛
- نفاذ کی غلطیوں کی تعداد کو نمایاں طور پر کم کرنا؛
- اعتماد کے ساتھ اپنے آپ کو ترقی کے معروف ماہر کے طور پر اعلان کریں۔
بلاشبہ، جو کچھ بیان کیا گیا ہے وہ سراسر گھٹیا لگتا ہے، لیکن یہ نظام کی خصوصیات اور اس میں موجود عمل کی حدود ہیں۔ اس وقت، تبدیلیوں نے IS پروفائل پروڈکٹس اور سروسز (ماسٹر اکاؤنٹس، پلاسٹک کارڈز، سیونگ اکاؤنٹس، ایسکرو، کیش لون) کو متاثر کیا ہے، لیکن ممکنہ طور پر یہ طریقہ کسی بھی IS پر لاگو کیا جا سکتا ہے جس کے لیے DevOps طریقوں کو لاگو کرنے کا کام سیٹ کیا گیا ہے۔ جمع شدہ ماڈل کو کئی ڈیلیوریوں سے بعد کے نفاذ (بشمول نان ریلیز والے) کے لیے محفوظ طریقے سے نقل کیا جا سکتا ہے۔
ماخذ: www.habr.com