اس علم کے ساتھ کہاں جانا ہے، پراجیکٹ میں کیا کرنا ہے اور کتنا کمانا ہے، انٹرویو میں کیا کہنا اور پوچھنا ہے - ایکسپریس 42 کے منیجنگ پارٹنر اور مصنف کا کہنا ہے کہ الیگزینڈر ٹیتوف .
ہیلو! اگرچہ ڈی او اوپس کی اصطلاح 2009 سے موجود ہے، لیکن روسی کمیونٹی میں ابھی تک کوئی اتفاق رائے نہیں ہے۔ آپ نے شاید دیکھا ہو گا کہ کچھ لوگ DevOps کو ایک خاصیت سمجھتے ہیں، دوسرے اسے ایک فلسفہ سمجھتے ہیں، اور دوسرے اصطلاح کو ٹیکنالوجی کا مجموعہ سمجھتے ہیں۔ میں پہلے بھی کئی بار پرفارم کر چکا ہوں۔ اس سمت کی ترقی کے بارے میں، لہذا میں اس مضمون میں تفصیل میں نہیں جاؤں گا. میں صرف یہ کہوں کہ ایکسپریس 42 میں ہم اس میں درج ذیل کو شامل کرتے ہیں:
DevOps ایک مخصوص طریقہ کار ہے، ڈیجیٹل پروڈکٹ بنانے کا کلچر، جب ٹیم کے تمام ماہرین پروڈکشن میں حصہ لیتے ہیں۔
کلاسک کارپوریٹ ڈویلپمنٹ میں، سب کچھ ترتیب وار ہوتا ہے: پروگرامنگ، ٹیسٹنگ اور اس کے بعد ہی آپریشن، اور خیال سے پیداوار تک اس عمل کی رفتار 3 ماہ ہے۔ یہ ڈیجیٹل پروڈکٹس کے لیے ایک عالمی مسئلہ ہے، کیونکہ صارفین سے فوری رائے حاصل کرنا ناممکن ہے۔
DevOps میں، ٹولز اور اپروچز اس بات کو یقینی بنانے کے لیے ڈیزائن کیے گئے ہیں کہ ڈیولپمنٹ، ٹیسٹنگ اور آپریشنز ایک ساتھ چلیں۔
اس نقطہ نظر سے کیا ہوتا ہے؟
- آپ کسی "انجینئر" کی خدمات حاصل نہیں کر سکتے جو آکر پروڈکشن کے تمام مسائل کو حل کرے۔ پوری ٹیم کو تکنیک کا اطلاق کرنا ہوگا۔
- DevOps اپ گریڈ کرنے کے لیے sysadmin کی اگلی شکل نہیں ہے۔ "DevOps انجینئر" کی آواز "Agile ڈویلپر" جیسی ہی ہے۔
- اگر کوئی ٹیم Kubernetes، Ansible، Prometheus، Mesosphere اور Docker کا استعمال کرتی ہے، تو اس کا مطلب یہ نہیں ہے کہ وہاں DevOps کے طریقوں کو نافذ کیا گیا ہے۔
DevOps کے بعد کی زندگی کبھی ایک جیسی نہیں ہوگی۔
DevOps نقطہ نظر، سب سے پہلے، سوچنے کا ایک مختلف طریقہ، مجموعی طور پر ترقی کا تصور اور اس عمل میں کسی کی جگہ ہے۔ ہم نے اپنے آن لائن کورس کو 2 بلاکس میں تقسیم کیا:
1. خود ارادیت
سب سے پہلے، ہم DevOps اپروچ کے جوہر کا تفصیل سے جائزہ لیتے ہیں، اور طلباء ٹیم میں نئے کردار دریافت کرتے ہیں، دیکھتے ہیں کہ کون زیادہ جواب دیتا ہے، اور خود طے کرتے ہیں کہ کس سمت کو تیار کرنا ہے۔
2. ٹولز اور پریکٹس
طلباء DevOps طریقہ کار کے نقطہ نظر سے مخصوص ٹیکنالوجیز پر عبور حاصل کرتے ہیں۔
DevOps ٹولز کو DevOps نقطہ نظر اور کلاسیکی ترقی دونوں میں استعمال کیا جا سکتا ہے۔ سب سے واضح مثال Ansible کنفیگریشن مینجمنٹ ٹول کا استعمال ہو گی۔ یہ DevOps پریکٹس "Infrastructure as Code" کو نافذ کرنے کے لیے بنایا اور تصور کیا گیا تھا، جس کا مطلب ہے کہ آپریٹنگ سسٹم کی ترتیبات سے لے کر ایپلیکیشن سافٹ ویئر تک سسٹم کی مختلف حالتوں کو بیان کیا گیا ہے۔ تفصیل کو تہوں میں تقسیم کیا گیا ہے اور آپ کو ایک پیچیدہ، مسلسل بدلتی ہوئی ترتیب کو منظم کرنے کی اجازت دیتا ہے۔ لیکن انجینئر اکثر Ansible کو ایک سے زیادہ مشینوں پر bash اسکرپٹ چلانے کے طریقے کے طور پر استعمال کرتے ہیں۔ یہ نہ تو برا ہے اور نہ ہی اچھا، لیکن آپ کو یہ سمجھنے کی ضرورت ہے کہ Ansible کی موجودگی کمپنی میں DevOps کی موجودگی کی ضمانت نہیں دیتی۔
ہم عمل میں ہیں۔ آپ مشہور Reddit کی طرح ایک ایپلیکیشن تیار کرنے کے عمل میں غرق ہو جائیں گے، اس کے یک سنگی ورژن سے شروع ہو کر، قدم بہ قدم مائیکرو سروسز کی طرف بڑھیں گے۔ قدم بہ قدم ہم نئے ٹولز میں مہارت حاصل کریں گے: Git، Ansible، Gitlab اور Kubernetes اور Prometheus کے ساتھ ختم۔
پریکٹس کے لحاظ سے، ہم DevOps ہینڈ بک میں بیان کردہ تین راستوں کی حکمت عملی پر عمل کریں گے - مسلسل ترسیل کے طریقے، فیڈ بیک کے طریقے، اور پورے کورس کا نچوڑ آپ کے سسٹم کے ساتھ ساتھ مسلسل سیکھنے کی مشق ہے۔
یہ علم ہر ایک ماہر کو کیا دیتا ہے؟
سسٹم ایڈمنسٹریٹرز کے لیے
پریکٹسز آپ کو انتظامیہ سے ایک مسلسل ڈیلیوری پائپ لائن اور سافٹ ویئر کی ترسیل کے لیے انفراسٹرکچر پلیٹ فارم بنانے کی طرف جانے کی اجازت دیں گی۔ نقطہ یہ ہے کہ وہ ایک پروڈکٹ تیار کرتا ہے - ڈویلپرز کے لیے ایک انفراسٹرکچر پلیٹ فارم جو انہیں اپنی تبدیلیوں کو پروڈکشن میں تیزی سے آگے بڑھانے میں مدد کرتا ہے۔
پہلے سسٹم ایڈمنسٹریٹر آخری گڑھ تھے جس کے بعد سب کچھ پروڈکشن میں چلا جاتا ہے۔ اور بنیادی طور پر وہ مسلسل آگ بجھانے میں مصروف تھے - جس کی روشنی میں کاروبار کی ضروریات کو سمجھنا، پروڈکٹ اور صارف کے لیے فوائد کے بارے میں سوچنا کافی مشکل ہے۔
DevOps طریقہ کار کی بدولت سوچ بدل جاتی ہے۔ سسٹم ایڈمنسٹریٹر سمجھتا ہے کہ کنفیگریشن کو کوڈ میں کیسے ترجمہ کیا جائے، اس کے لیے کون سے طریقے موجود ہیں۔
یہ ضروری ہے کیونکہ کمپنیاں تیزی سے یہ سمجھ رہی ہیں کہ انہیں صرف ہر چیز کو خودکار کرنے کی ضرورت نہیں ہے، یعنی پرانے اسکول کے نظام کے منتظمین بنیادی طور پر کیا کرنے کے عادی تھے، جنہوں نے اس کے علاوہ بہت کم بات چیت کی اور ٹیم کو کی گئی تمام تبدیلیوں کے بارے میں مطلع نہیں کیا۔ اب ٹیمیں ان لوگوں کی تلاش کر رہی ہیں جو اندرونی انفراسٹرکچر پروڈکٹ کے کارخانہ دار بنیں گے اور الگ ہونے والے عمل کو ایک میں جوڑنے میں مدد کریں گے۔
ڈویلپرز
ڈویلپر صرف الگورتھم میں سوچنا چھوڑ دیتا ہے۔ وہ انفراسٹرکچر کے ساتھ کام کرنے کا ہنر، زمین کی تزئین کی آرکیٹیکچرل بیداری کی مہارت حاصل کرتا ہے۔ ایسا ڈویلپر سمجھتا ہے کہ ایپلی کیشن کیسے کام کرتی ہے، یہ مسلسل ڈیلیوری پائپ لائن سے کیسے گزرتی ہے، اسے کیسے مانیٹر کرنا ہے، اسے کیسے رجسٹر کرنا ہے تاکہ اس سے کلائنٹ کو فائدہ ہو۔ نتیجے کے طور پر، یہ تمام علم آپ کو متعلقہ کوڈ لکھنے کی اجازت دیتا ہے۔
ٹیسٹرز کے لیے
ٹیسٹنگ کافی عرصے سے آٹومیٹک موڈ میں چل رہی ہے؛ ہم سب کہتے ہیں کہ بہت سے ٹیسٹ نہیں کیے جانے چاہئیں، لیکن تحریری :) ٹیسٹنگ آپ کے پروڈکٹ کی پوری ڈیلیوری پائپ لائن کا حصہ بن جاتی ہے۔ ٹیسٹر کو نہ صرف یہ سیکھنے کی ضرورت ہوتی ہے کہ کوڈ کیسے لکھنا ہے، بلکہ یہ بھی سمجھنے کی ضرورت ہے کہ اسے مسلسل ڈیلیوری سسٹم میں کیسے ضم کیا جائے، ڈیلیوری کے تمام مراحل پر کوڈ سے فیڈ بیک کیسے حاصل کیا جائے، اور غلطیوں کا پتہ لگانے کے لیے ٹیسٹنگ کو مسلسل بہتر بنانے کا طریقہ جلد از جلد.
تو یہ پتہ چلتا ہے کہ تینوں مراحل ایک ساتھ ہوتے ہیں۔. مثال کے طور پر، یہ اس طرح نظر آسکتا ہے:
ڈویلپر کوڈ لکھتا ہے، فوری طور پر اس کے لیے ٹیسٹ لکھتا ہے، اور اس کوڈ کے لیے ایک ڈوکر کنٹینر کی وضاحت کرتا ہے جسے چلایا جانا چاہیے۔ یہ فوری طور پر نگرانی کی وضاحت کرتا ہے جو پیداوار میں اس سروس کے آپریشن کی نگرانی کرے گا، اور اس سب کا ارتکاب کرتا ہے۔
جب مسلسل انضمام شروع ہوتا ہے، عمل ایک ساتھ چلتے ہیں۔ سروس شروع ہوتی ہے اور ترتیب دی جاتی ہے۔ اسی وقت، ڈاکر کنٹینر شروع ہوتا ہے اور یہ چیک کیا جاتا ہے کہ یہ چل رہا ہے. ایک ہی وقت میں، تمام معلومات لاگنگ سسٹم میں جاتی ہیں۔ اور اسی طرح ترقی کے ہر مرحلے پر - یہ سسٹم ایڈمنسٹریٹرز، ڈویلپرز اور ٹیسٹرز کا حقیقی ٹیم ورک ثابت ہوتا ہے۔
میں نے DevOps کا مطالعہ کیا، آگے کیا؟
جیسا کہ آپ جانتے ہیں، میدان میں ایک جنگجو نہیں ہے. اگر آپ کی کمپنی یہ طریقہ استعمال نہیں کرتی ہے، تو حاصل کردہ مہارتیں بیکار پڑی ہوں گی۔ اور DevOps اپروچز سے واقف ہونے کے بعد، آپ غالباً کارپوریٹ ڈویلپمنٹ میں کوگ نہیں بننا چاہیں گے۔ اس میں ایک استثناء ہو سکتا ہے: آپ ٹیم میں ایک سسٹم ایڈمنسٹریٹر ہیں اور تمام عمل کو نئے طریقے سے دوبارہ بنا سکتے ہیں۔ یہاں یہ بات شامل کرنے کے قابل ہے کہ بہت ساری کمپنیاں ہیں جو اس طریقہ کار کو استعمال کرتی ہیں، اور وہ لاک ڈاؤن سے متاثر نہیں ہوئی ہیں اور ماہرین کی تلاش میں ہیں۔ کیونکہ DevOps آن لائن مصنوعات بنانے کے بارے میں ہے۔
اور اب اچھی چیزوں کے بارے میں: DevOps پریکٹسز اور ٹولز میں مہارت لیبر مارکیٹ میں آپ کی قدر کے تقریباً +30% ہے۔ تنخواہیں 140 ہزار روبل سے شروع ہوتی ہیں، لیکن فطری طور پر، آپ کی بنیادی خصوصیت اور فعالیت سے طے کی جاتی ہیں۔
آپ "انفراسٹرکچر اورینٹڈ" کے نشان والی خالی آسامیوں کو دیکھ سکتے ہیں، جہاں ٹیسٹ آٹومیشن، کلاؤڈ ٹیکنالوجیز کا استعمال کرتے ہوئے مائیکرو سروس ایپلیکیشنز کی ترقی، انفراسٹرکچر انجینئرز کے لیے آسامیاں اور ڈی او اوپس کے حوالے سے ہر طرح کے حوالے ہیں۔ بس یاد رکھیں کہ اس تعریف کے مطابق ہر کمپنی کا مطلب کچھ مختلف ہے - تفصیل کو غور سے پڑھیں۔
ہمارے کورس کے آغاز کے دوران، مجھے ایک بصیرت ملی - کورس کے بعد بہت سے لوگ DevOps انجینئر کے جال میں پھنس جاتے ہیں۔ وہ اوپر بیان کردہ عنوان کے ساتھ ایک خالی جگہ تلاش کرتے ہیں، ایک اچھی پیشکش حاصل کرتے ہیں، اور پھر کام پر آتے ہیں اور محسوس کرتے ہیں کہ انہیں جینکنز میں تین صفحات کی باش اسکرپٹ کو برقرار رکھنا پڑے گا۔ Kubernetes، ChatOps، کینری ریلیز اور وہ سب کہاں ہیں؟ لیکن وہاں کچھ بھی نہیں ہے، کیونکہ کمپنی کو ایک طریقہ کار کے طور پر DevOps کی ضرورت نہیں ہے، بلکہ انفرادی اختراعات کا استعمال کرتی ہے۔
یہ کمپنی سے یہ جاننے کی ایک وجہ ہے کہ سافٹ ویئر کی ترسیل کا عمل کس طرح کام کرتا ہے، ٹیکنالوجی کا اسٹیک اور آپ کون سی ذمہ داریاں انجام دیں گے۔
اگر آجر آپ کے سوالات کا خلاصہ جواب دیتا ہے، جیسا کہ کسی کتاب سے، بغیر تفصیلات کے، تو غالباً کمپنی میں ابھی تک کوئی ڈی او اوپس عمل نہیں ہے، لیکن یہ انکار کرنے کی وجہ نہیں ہے، کمپنی اور اس کی مصنوعات کا مطالعہ کریں، چاہے آن لائن موجود ہوں۔ وہ خدمات جو کمپنی خود تیار کرتی ہے، موبائل ایپلی کیشنز، پروڈکٹ آئیڈیاز۔
اگر ہاں، تو واضح کریں کہ آیا آپ کو ان سسٹمز کے ساتھ براہ راست کام کرنا پڑے گا یا DevOps طریقوں میں اچھے نتائج کا مظاہرہ کرتے ہوئے ان سروسز کی ٹیموں میں افقی حرکت کا امکان موجود ہے۔ اگر ہاں، تو یہ جانا اور فعال اور مفید رہنے کے قابل ہے، اور اگر آپ ہمارا کورس مکمل کرتے ہیں، تو بعد کی ضمانت ہے۔
یہ نوٹ کرنا ضروری ہے کہ ڈیوپس پریکٹیشنرز صرف ترقی/انتظامیہ/ٹیسٹنگ کے تجربے کے ساتھ حقیقی قدر حاصل کرتے ہیں۔ تب ہی علم تجریدی نہیں ہوگا، بلکہ ماہر (ہر لحاظ سے) مالا مال ہوگا۔ لہذا، "شروع سے DevOps سیکھنا" کا خیال "شروع سے لینس استعمال کرنا" سیکھنے جیسا ہی ہے اگر آپ نے کبھی اپنے ہاتھ میں کیمرہ نہیں پکڑا ہے یا شوٹ کی ہدایت نہیں کی ہے۔ یہ فیصلہ کرنے میں آپ کی مدد کرنے کے لیے کہ آیا کورس آپ کے لیے صحیح ہے، ہم نے ایک داخلہ ٹیسٹ دیا ہے جو آپ کے علم کی کافی سطح کی جانچ کرے گا۔
میرے خیال میں چالوں میں سے ایک ہے۔ - کہ تربیت کے دوران ہر طالب علم اپنے لیے یہ طے کرتا ہے کہ وہ کس سمت ترقی کرنا چاہتا ہے۔ ہم اکثر ٹرانزیشن دیکھتے ہیں جب ایک ڈویلپر انفراسٹرکچر انجینئر بن جاتا ہے، اور ایک ایڈمنسٹریٹر کو احساس ہوتا ہے کہ وہ کوڈ لکھنے میں دلچسپی رکھتا ہے - پھر وہ زبان کا مزید مطالعہ کرتا ہے اور اسے حاصل شدہ DevOps مہارتوں کے ساتھ پورا کرتا ہے۔ لہذا، ہم خاص طور پر ان لوگوں کا خیرمقدم کرتے ہیں جو محسوس کرتے ہیں کہ ان کا کیریئر ایک دوراہے پر پھنس گیا ہے۔ کورس 28 مئی سے شروع ہوتا ہے، لیکن آپ کلاسز شروع ہونے کے 2 ہفتے بعد اس میں شامل ہو سکتے ہیں۔ آپ پروگرام دیکھ سکتے ہیں اور ٹیسٹ دے سکتے ہیں۔ . OTUS میں ملیں گے!
ماخذ: www.habr.com