ہم نے ایک بار ایک سہولت پر ایک صارف کو الیکٹرانک دستاویز کے انتظام کا نظام فراہم کیا تھا۔ اور پھر کسی اور اعتراض کی طرف۔ اور ایک اور۔ اور چوتھی پر اور پانچویں پر۔ ہم اتنے بہہ گئے کہ ہم 10 تقسیم شدہ اشیاء تک پہنچ گئے۔ یہ طاقتور طریقے سے نکلا... خاص طور پر جب ہمیں تبدیلیاں کرنا پڑیں۔ پروڈکشن سرکٹ کی ترسیل کے حصے کے طور پر، ٹیسٹنگ سسٹم کے 5 منظرناموں کے لیے بالآخر 10 گھنٹے اور 6-7 ملازمین درکار تھے۔ اس طرح کے اخراجات نے ہمیں جتنی شاذ و نادر ہی ممکن ہو ترسیل کرنے پر مجبور کیا۔ تین سال کے آپریشن کے بعد، ہم اسے برداشت نہیں کر سکے اور ایک چٹکی بھر DevOps کے ساتھ پروجیکٹ کو مسالا کرنے کا فیصلہ کیا۔
اب تمام ٹیسٹنگ 3 گھنٹے میں ہوتی ہے، اور اس میں 3 لوگ حصہ لیتے ہیں: ایک انجینئر اور دو ٹیسٹر۔ بہتریوں کا واضح طور پر تعداد میں اظہار کیا گیا ہے اور یہ بہت زیادہ پسند کیے جانے والے TTM میں کمی کا باعث بنتے ہیں۔ ہمارے تجربے میں، بہت زیادہ ایسے صارفین ہیں جو DevOps سے فائدہ اٹھا سکتے ہیں ان لوگوں کے مقابلے جو اس کے بارے میں جانتے ہیں۔ لہذا، DevOps کو لوگوں کے قریب لانے کے لیے، ہم نے ایک سادہ کنسٹرکٹر تیار کیا ہے، جس کے بارے میں ہم اس پوسٹ میں مزید تفصیل سے بات کریں گے۔
اب آئیے آپ کو مزید تفصیل سے بتاتے ہیں۔ ایک انرجی کمپنی 10 بڑی سہولیات پر تکنیکی دستاویز کے انتظام کے نظام کو تعینات کر رہی ہے۔ اس پیمانے کے پروجیکٹس کو DevOps کے بغیر نیویگیٹ کرنا آسان نہیں ہے، کیونکہ دستی مشقت کا ایک بڑا حصہ کام میں بہت تاخیر کرتا ہے اور معیار کو بھی کم کرتا ہے - تمام دستی کام غلطیوں سے بھرے ہوتے ہیں۔ دوسری طرف، ایسے منصوبے ہیں جہاں صرف ایک تنصیب ہے، لیکن ہر چیز کو خود بخود، مسلسل اور ناکامی کے بغیر کام کرنے کی ضرورت ہے - مثال کے طور پر، بڑی یک سنگی تنظیموں میں ایک ہی دستاویز کے بہاؤ کے نظام۔ دوسری صورت میں، کوئی شخص دستی طور پر ترتیبات بنائے گا، تعیناتی کی ہدایات کو بھول جائے گا - اور نتیجے کے طور پر، پیداوار میں ترتیبات ختم ہو جائیں گی اور سب کچھ گر جائے گا.
عام طور پر ہم ایک معاہدے کے ذریعے گاہک کے ساتھ کام کرتے ہیں، اور اس معاملے میں ہمارے مفادات قدرے ہٹ جاتے ہیں۔ صارف اس منصوبے کو بجٹ اور تکنیکی وضاحتوں کے اندر سختی سے دیکھتا ہے۔ اسے مختلف DevOps طریقوں کے فوائد کی وضاحت کرنا مشکل ہو سکتا ہے جو تکنیکی خصوصیات میں شامل نہیں ہیں۔ کیا ہوگا اگر وہ اضافی کاروباری قدر کے ساتھ فوری ریلیز میں، یا آٹومیشن پائپ لائن بنانے میں دلچسپی رکھتا ہے؟
افسوس، پہلے سے منظور شدہ لاگت کے ساتھ کام کرتے وقت، یہ دلچسپی ہمیشہ نہیں ملتی۔ ہمارے پریکٹس میں، ایک ایسا معاملہ تھا جب ہمیں ایک بے ضمیر اور لاپرواہ ٹھیکیدار کی ترقی کو اٹھانا پڑا۔ یہ خوفناک تھا: کوئی تازہ ترین سورس کوڈز نہیں تھے، مختلف تنصیبات پر ایک ہی سسٹم کا کوڈ بیس مختلف تھا، دستاویزات جزوی طور پر غائب تھیں، اور جزوی طور پر خوفناک معیار کا تھا۔ بلاشبہ، صارف کا سورس کوڈ، اسمبلی، ریلیز وغیرہ پر کنٹرول نہیں تھا۔
ابھی تک، ہر کوئی DevOps کے بارے میں نہیں جانتا، لیکن جیسے ہی ہم اس کے فوائد کے بارے میں، حقیقی وسائل کی بچت کے بارے میں بات کرتے ہیں، تمام صارفین کی آنکھیں روشن ہوجاتی ہیں۔ لہذا درخواستوں کی تعداد جن میں DevOps شامل ہیں وقت کے ساتھ ساتھ بڑھ رہی ہے۔ یہاں، صارفین کے ساتھ آسانی سے ایک ہی زبان بولنے کے لیے، ہمیں کاروباری مسائل اور DevOps کے طریقوں کو تیزی سے جوڑنے کی ضرورت ہے جو ایک مناسب ترقیاتی پائپ لائن بنانے میں مدد کریں گے۔
لہذا، ہمارے پاس ایک طرف مسائل کا ایک مجموعہ ہے، تو دوسری طرف ہمارے پاس DevOps علم، طرز عمل اور ٹولز ہیں۔ سب کے ساتھ تجربہ کیوں نہیں بانٹتے؟
ڈی او اوپس کنسٹرکٹر بنانا
فرتیلی کا اپنا منشور ہے۔ ITIL کا اپنا طریقہ کار ہے۔ DevOps کم خوش قسمت ہے - اس نے ابھی تک ٹیمپلیٹس اور معیارات حاصل نہیں کیے ہیں۔ اگرچہ ان کی ترقی اور آپریشنل طریقوں کے جائزے کی بنیاد پر کمپنیوں کی پختگی کا تعین کریں۔
خوش قسمتی سے، 2014 میں معروف کمپنی گارٹنر اور اہم DevOps طریقوں اور ان کے درمیان تعلقات کا تجزیہ کیا۔ اس کی بنیاد پر، میں نے ایک انفوگرافک جاری کیا:
ہم نے اسے اپنی بنیاد کے طور پر لیا۔ . چاروں شعبوں میں سے ہر ایک میں ٹولز کا ایک سیٹ ہے - ہم نے انہیں ایک ڈیٹا بیس میں جمع کیا، سب سے زیادہ مقبول کی نشاندہی کی، انضمام پوائنٹس اور موزوں اصلاحی میکانزم کی نشاندہی کی۔ مجموعی طور پر یہ نکلا۔ 36 مشقیں اور 115 ٹولز، جن میں سے ایک چوتھائی اوپن سورس یا مفت سافٹ ویئر ہیں۔ اس کے بعد، ہم اس بارے میں بات کریں گے کہ ہم نے ہر شعبے میں کیا حاصل کیا ہے اور، مثال کے طور پر، تکنیکی دستاویز کا انتظام بنانے کے منصوبے میں اس کو کیسے لاگو کیا گیا، جس کے ساتھ ہم نے پوسٹ شروع کی۔
پروسیسنگ
بدنام زمانہ EDMS پروجیکٹ میں، 10 اشیاء میں سے ہر ایک پر اسی اسکیم کے مطابق تکنیکی دستاویزات کے انتظام کے نظام کو تعینات کیا گیا تھا۔ انسٹالیشن میں 4 سرورز شامل ہیں: ڈیٹا بیس سرور، ایپلیکیشن سرور، فل ٹیکسٹ انڈیکسنگ اور مواد کا انتظام۔ تنصیب میں، وہ ایک ہی نوڈ کے اندر کام کرتے ہیں اور سہولیات کے ڈیٹا سینٹر میں واقع ہیں۔ تمام اشیاء بنیادی ڈھانچے میں تھوڑا سا مختلف ہیں، لیکن یہ عالمی تعامل میں مداخلت نہیں کرتا ہے۔
سب سے پہلے، DevOps طریقوں کے مطابق، ہم نے بنیادی ڈھانچے کو مقامی طور پر خودکار بنایا، پھر ہم ڈیلیوری کو ٹیسٹ سرکٹ پر، اور پھر گاہک کے پروڈکٹ تک لے آئے۔ ہر عمل کو مرحلہ وار طے کیا گیا۔ ماحول کی ترتیبات سورس کوڈ سسٹم میں طے کی جاتی ہیں، اس بات کو مدنظر رکھتے ہوئے کہ ڈسٹری بیوشن کٹ کو خودکار اپ ڈیٹ کرنے کے لیے مرتب کیا جاتا ہے۔ کنفیگریشن تبدیلیوں کی صورت میں، انجینئرز کو صرف ورژن کنٹرول سسٹم میں مناسب تبدیلیاں کرنے کی ضرورت ہوتی ہے - اور پھر خودکار اپ ڈیٹ بغیر کسی پریشانی کے ہو جائے گا۔
اس نقطہ نظر کی بدولت، جانچ کے عمل کو بہت آسان بنایا گیا ہے۔ پہلے، پروجیکٹ میں ٹیسٹرز تھے جنہوں نے اسٹینڈز کو دستی طور پر اپ ڈیٹ کرنے کے علاوہ کچھ نہیں کیا۔ اب وہ آتے ہیں، دیکھیں کہ سب کچھ کام کر رہا ہے اور مزید مفید چیزیں کرتے ہیں. ہر اپ ڈیٹ کا خود بخود تجربہ کیا جاتا ہے - سطح کی سطح سے لے کر کاروباری منظر نامے کی آٹومیشن تک۔ نتائج ٹیسٹ ریل میں علیحدہ رپورٹس کے طور پر پوسٹ کیے گئے ہیں۔
ثقافت
ٹیسٹ ڈیزائن کی مثال کے ذریعے مسلسل تجربات کی بہترین وضاحت کی گئی ہے۔ ایسے نظام کی جانچ کرنا جو ابھی تک موجود نہیں ہے تخلیقی کام ہے۔ ٹیسٹ پلان لکھتے وقت، آپ کو یہ سمجھنے کی ضرورت ہے کہ صحیح طریقے سے ٹیسٹ کیسے کیا جائے اور کن شاخوں کو فالو کرنا ہے۔ اور چیک کی زیادہ سے زیادہ تعداد کا تعین کرنے کے لیے وقت اور بجٹ کے درمیان توازن بھی تلاش کریں۔ بالکل ضروری ٹیسٹوں کا انتخاب کرنا ضروری ہے، اس بارے میں سوچیں کہ صارف سسٹم کے ساتھ کیسے تعامل کرے گا، ماحول اور ممکنہ بیرونی عوامل کو مدنظر رکھیں۔ مسلسل تجربات کے بغیر ایسا کرنا ناممکن ہے۔
اب بات چیت کے کلچر کے بارے میں۔ پہلے، دو مخالف فریق تھے - انجینئرز اور ڈویلپرز۔ ڈویلپرز نے کہا: "ہمیں پرواہ نہیں ہے کہ اسے کیسے شروع کیا جائے گا۔ آپ انجینئر ہیں، آپ ہوشیار ہیں، اس بات کو یقینی بنائیں کہ یہ ناکامی کے بغیر چلتا ہے۔". انجینئرز نے جواب دیا: "آپ ڈویلپرز بہت لاپرواہ ہیں۔ آئیے زیادہ محتاط رہیں، اور ہم آپ کی ریلیز کو کم ہی چلائیں گے۔ کیونکہ جب بھی آپ ہمیں کوئی لیکی کوڈ دیتے ہیں، یہ ہمارے لیے واضح نہیں ہوتا ہے کہ بات چیت کیسے کی جائے۔. یہ ایک ثقافتی تعامل کا مسئلہ ہے جس کی ساخت ڈی او اوپس کے نقطہ نظر سے مختلف ہے۔ یہاں، دونوں انجینئرز اور ڈویلپرز ایک ہی ٹیم کا حصہ ہیں جو مسلسل تبدیل کرنے پر مرکوز ہے، لیکن ساتھ ہی ساتھ قابل اعتماد سافٹ ویئر بھی۔
ایک ہی ٹیم کے اندر، ماہرین ایک دوسرے کی مدد کے لیے پرعزم ہیں۔ جیسا کہ پہلے تھا؟ مثال کے طور پر، تقریباً 50 صفحات پر مشتمل کچھ موٹی تعیناتی ہدایات تیار کی جا رہی تھیں۔ انجینئر نے اسے پڑھا، کچھ سمجھ نہیں آیا، لعنت بھیجی اور صبح تین بجے ڈویلپر سے تبصرہ کرنے کو کہا۔ ڈویلپر نے تبصرہ کیا اور لعنت بھیجی - آخر میں، کوئی بھی خوش نہیں تھا. اس کے علاوہ، قدرتی طور پر، کچھ غلطیاں تھیں، کیونکہ آپ ہدایات میں سب کچھ یاد نہیں رکھ سکتے۔ اور اب انجینئر، ڈویلپر کے ساتھ مل کر، ایپلیکیشن سافٹ ویئر کے بنیادی ڈھانچے کی خودکار تعیناتی کے لیے ایک اسکرپٹ لکھ رہا ہے۔ اور وہ ایک دوسرے سے عملی طور پر ایک ہی زبان میں بات کرتے ہیں۔
لوگ
ٹیم کے سائز کا تعین اپ ڈیٹ کے دائرہ کار سے ہوتا ہے۔ ٹیم کو ڈیلیوری کی تشکیل کے دوران بھرتی کیا جاتا ہے؛ اس میں وہ لوگ شامل ہوتے ہیں جو عام پروجیکٹ ٹیم سے دلچسپی رکھتے ہیں۔ پھر ہر مرحلے کے ذمہ داروں کے ساتھ ایک اپ ڈیٹ پلان لکھا جاتا ہے، اور ٹیم جیسے جیسے آگے بڑھتی ہے رپورٹ کرتی ہے۔ ٹیم کے تمام ممبران قابل تبادلہ ہیں۔ ٹیم کے حصے کے طور پر، ہمارے پاس ایک بیک اپ ڈویلپر بھی ہے، لیکن اسے تقریباً کبھی رابطہ نہیں کرنا پڑتا ہے۔
ٹیکنالوجی
ٹیکنالوجی کے خاکے میں، چند نکات کو نمایاں کیا گیا ہے، لیکن ان کے نیچے ٹیکنالوجیز کا ایک گروپ ہے - آپ ان کی تفصیل کے ساتھ ایک پوری کتاب شائع کر سکتے ہیں۔ تو ہم سب سے زیادہ دلچسپ کو اجاگر کریں گے۔
بنیادی ڈھانچہ بطور ضابطہ
اب، شاید، یہ تصور کسی کو حیران نہیں کرے گا، لیکن اس سے پہلے بنیادی ڈھانچے کی وضاحتیں بہت زیادہ مطلوبہ رہ گئی تھیں۔ , ٹیسٹ کے ماحول منفرد تھے، وہ پالے گئے اور پالے گئے تھے، ان سے دھول کے ذرات اڑا دیے گئے تھے۔
آج کل کوئی بھی تجربہ کرنے سے نہیں ڈرتا۔ ورچوئل مشینوں کی بنیادی تصاویر، اور ماحول کو تعینات کرنے کے لیے تیار شدہ منظرنامے ہیں۔ تمام ٹیمپلیٹس اور اسکرپٹس کو ایک ورژن کنٹرول سسٹم میں محفوظ کیا جاتا ہے اور فوری طور پر اپ ڈیٹ کیا جاتا ہے۔ پہلے، جب اسٹینڈ پر پیکج پہنچانا ضروری ہوتا تھا، تو کنفیگریشن گیپ ظاہر ہوتا تھا۔ اب آپ کو سورس کوڈ میں صرف ایک لائن شامل کرنے کی ضرورت ہے۔
بنیادی ڈھانچے کے اسکرپٹس اور پائپ لائنوں کے علاوہ، ڈاکومینٹیشن بطور کوڈ اپروچ کو بھی دستاویزات کے لیے استعمال کیا جاتا ہے۔ اس کی بدولت، نئے لوگوں کو پروجیکٹ سے جوڑنا، بیان کردہ افعال کی بنیاد پر انہیں سسٹم سے متعارف کرانا، مثال کے طور پر، ٹیسٹ پلان میں، اور ٹیسٹ کیسز کو دوبارہ استعمال کرنا آسان ہے۔
مسلسل ترسیل اور نگرانی
DevOps کے بارے میں، ہم نے اس بارے میں بات کی کہ ہم نے مسلسل ترسیل اور نگرانی کو لاگو کرنے کے لیے کس طرح ٹولز کا انتخاب کیا۔ اکثر کسی بھی چیز کو دوبارہ لکھنے کی ضرورت نہیں ہوتی ہے - یہ پہلے سے لکھے گئے اسکرپٹس کو استعمال کرنے، اجزاء کے درمیان صحیح طریقے سے انضمام اور ایک مشترکہ مینجمنٹ کنسول بنانے کے لیے کافی ہے۔ اور تمام عمل کو ایک بٹن یا شیڈول کے ذریعے شروع کیا جا سکتا ہے۔
انگریزی میں مختلف تصورات ہیں، مسلسل ترسیل اور مسلسل تعیناتی۔ دونوں کا ترجمہ "مسلسل ترسیل" کے طور پر کیا جا سکتا ہے، لیکن درحقیقت ان میں تھوڑا سا فرق ہے۔ تقسیم شدہ توانائی کمپنی کے تکنیکی دستاویز کے بہاؤ کے لیے ہمارے پروجیکٹ میں، ڈیلیوری کا استعمال کیا جاتا ہے - جب پیداوار کے لیے تنصیب کمانڈ پر ہوتی ہے۔ تعیناتی میں، تنصیب خود بخود ہوتی ہے۔ اس منصوبے میں مسلسل ترسیل عام طور پر بن گیا ہے DevOps کا مرکزی حصہ.
عام طور پر، کچھ پیرامیٹرز جمع کرکے، آپ واضح طور پر سمجھ سکتے ہیں کہ DevOps کے طریقے کارآمد کیوں ہیں۔ اور اسے انتظامیہ تک پہنچائیں، جو واقعی نمبروں سے محبت کرتا ہے۔ لانچوں کی کل تعداد، اسکرپٹ کے مراحل پر عمل درآمد کا وقت، کامیاب لانچوں کا حصہ - یہ سب براہ راست مارکیٹ میں ہر کسی کے پسندیدہ وقت پر اثر انداز ہوتا ہے، یعنی ورژن کنٹرول سسٹم سے وابستگی سے لے کر ایک ورژن کی ریلیز تک کا وقت۔ پیداواری ماحول ضروری ٹولز کے نفاذ کے ساتھ، انجینئرز بذریعہ ڈاک قیمتی اشارے وصول کرتے ہیں، اور پروجیکٹ مینیجر انہیں ڈیش بورڈ پر دیکھتا ہے۔ اس طرح آپ فوری طور پر نئے ٹولز کے فوائد کا اندازہ لگا سکتے ہیں۔ اور آپ DevOps ڈیزائنر کا استعمال کرتے ہوئے انہیں اپنے انفراسٹرکچر پر آزما سکتے ہیں۔
جس کو ہماری ضرورت ہو گی۔ ?
آئیے دکھاوا نہ کریں: ایک آغاز کے لیے، وہ ہمارے لیے مفید ہو گیا۔ جیسا کہ ہم پہلے ہی کہہ چکے ہیں، آپ کو گاہک کے ساتھ وہی زبان بولنے کی ضرورت ہے، اور DevOps ڈیزائنر کی مدد سے ہم اس طرح کی گفتگو کی بنیاد کو تیزی سے خاکہ بنا سکتے ہیں۔ کاروباری ماہرین خود اندازہ لگا سکیں گے کہ انہیں کس چیز کی ضرورت ہے اور اس طرح تیزی سے ترقی کریں گے۔ ہم نے ڈیزائنر کو ممکنہ حد تک تفصیلی بنانے کی کوشش کی، تفصیل کا ایک گروپ شامل کیا تاکہ کوئی بھی صارف سمجھ سکے کہ وہ کیا منتخب کر رہا ہے۔
ڈیزائنر کا فارمیٹ آپ کو عمارت کے عمل اور آٹومیشن میں کمپنی کی موجودہ پیش رفت کو مدنظر رکھنے کی اجازت دیتا ہے۔ ہر چیز کو پھاڑنے اور اسے دوبارہ بنانے کی ضرورت نہیں ہے اگر آپ صرف ایسے حل کا انتخاب کرسکتے ہیں جو موجودہ عمل کے ساتھ اچھی طرح سے مربوط ہوں اور جو خالی جگہوں کو پُر کرسکیں۔
شاید آپ کی ترقی پہلے ہی ایک اعلی سطح پر چلی گئی ہے اور ہمارا ٹول بہت "کپتان کا" لگتا ہے۔ لیکن ہم اسے اپنے لیے مفید سمجھتے ہیں اور امید کرتے ہیں کہ یہ کچھ قارئین کے لیے مفید ثابت ہو گا۔ ہم آپ کو یاد دلاتے ہیں۔ ڈیزائنر کو - اگر کچھ بھی ہو تو، آپ کو ابتدائی ڈیٹا داخل کرنے کے فوراً بعد خاکہ موصول ہوتا ہے۔ ہم آپ کے تاثرات اور اضافے کے لیے شکر گزار ہوں گے۔
ماخذ: www.habr.com