اگر آپ کی کمپنی صرف DevOps یا CI/CD ٹولز کو لاگو کر رہی ہے، تو یہ آپ کے لیے سب سے عام غلطیوں سے واقف ہونا مفید ہو سکتا ہے تاکہ آپ ان کو دہرائیں اور کسی اور کے ریک پر قدم نہ رکھیں۔
ٹیم مضمون کا ترجمہ کیا۔ .
ثقافت اور عمل کو تبدیل کرنے کی خواہش
سائیکل ڈایاگرام کو دیکھ کر ، یہ واضح ہے کہ DevOps طریقوں میں، جانچ ایک مسلسل کام ہے، جو ہر فرد کی تعیناتی کا ایک بنیادی حصہ ہے۔
DevOps لامتناہی سائیکل ڈایاگرام
ڈیولپمنٹ اور ڈیلیوری کے دوران ٹیسٹنگ اور کوالٹی ایشورنس ڈویلپرز کے ہر کام کا لازمی حصہ ہے۔ اس کے لیے ہر کام میں ٹیسٹنگ کو شامل کرنے کے لیے ذہنیت کی تبدیلی کی ضرورت ہے۔
ٹیسٹنگ ٹیم کے ہر رکن کے روزمرہ کے کام کا حصہ بن جاتی ہے۔ مسلسل جانچ میں منتقلی آسان نہیں ہے، آپ کو اس کے لیے تیار رہنے کی ضرورت ہے۔
رائے کا فقدان۔
DevOps کی تاثیر مستقل رائے پر منحصر ہے۔ اگر تعاون اور رابطے کی گنجائش نہ ہو تو مسلسل بہتری ممکن نہیں۔
وہ کمپنیاں جو سابقہ میٹنگز کا اہتمام نہیں کرتیں ان کے لیے CI/CD میں مسلسل فیڈ بیک کے کلچر کو نافذ کرنا مشکل ہوتا ہے۔ ہر تکرار کے اختتام پر سابقہ میٹنگز منعقد کی جاتی ہیں، جہاں گروپ ممبران اس بات پر تبادلہ خیال کرتے ہیں کہ کیا اچھا ہوا اور کیا غلط ہوا۔ سابقہ ملاقاتیں Scrum/Agile کی بنیاد ہیں، لیکن یہ DevOps کے لیے بھی ضروری ہیں۔
اس کی وجہ یہ ہے کہ سابقہ ملاقاتیں رائے اور آراء کے تبادلے کی عادت ڈالتی ہیں۔ شروع کے سب سے اہم لمحات میں سے ایک بار بار ہونے والی ریٹرو میٹنگز کی تنظیم ہے تاکہ وہ پوری ٹیم کے لیے قابل فہم اور مانوس ہو جائیں۔
جب سافٹ ویئر کے معیار کی بات آتی ہے، تو ٹیم کے تمام اراکین اسے برقرار رکھنے کے ذمہ دار ہیں۔ مثال کے طور پر، ڈویلپرز یونٹ ٹیسٹ کے ساتھ ساتھ ٹیسٹ ایبلٹی کو ذہن میں رکھتے ہوئے کوڈ لکھ سکتے ہیں، جو شروع سے ہی خطرے کو کم کرنے میں مدد کرتے ہیں۔
ٹیسٹنگ کے بدلتے ہوئے تاثرات کی عکاسی کرنے کا ایک آسان طریقہ یہ ہے کہ ٹیسٹرز کو QA نہیں بلکہ سافٹ ویئر ٹیسٹر یا کوالٹی انجینئر بلایا جائے۔ یہ تبدیلی بہت سادہ یا احمقانہ بھی لگ سکتی ہے۔ لیکن کسی کو "سافٹ ویئر کوالٹی ایشورنس اسپیشلسٹ" کہنے سے یہ غلط خیال آتا ہے کہ پروڈکٹ کوالٹی کا ذمہ دار کون ہے۔ Agile، CI/CD، اور DevOps طریقوں میں، ہر کوئی سافٹ ویئر کے معیار کے لیے ذمہ دار ہے۔
ایک اور اہم نکتہ یہ سمجھنا ہے کہ پوری ٹیم اور اس کے ہر ممبر، تنظیم، اسٹیک ہولڈرز کے لیے معیار کا کیا مطلب ہے۔
مرحلے کی تکمیل کی غلط فہمی۔
اگر معیار ایک جاری اور مشترکہ عمل ہے تو، ایک مرحلے کی تکمیل کے بارے میں مشترکہ تفہیم کی ضرورت ہے۔ کیسے سمجھیں کہ مرحلہ ختم ہو گیا ہے؟ کیا ہوتا ہے جب ایک سنگ میل کو ٹریلو بورڈ یا دوسرے کنبن بورڈ پر مکمل کے طور پر نشان زد کیا جاتا ہے؟
مکمل شدہ سنگ میل (DoD) کا تعین CD DevOps/CI کے تناظر میں ایک طاقتور ٹول ہے۔ یہ ٹیم کیا اور کیسے بناتی ہے اس کے معیار کے معیار کو بہتر طور پر سمجھنے میں مدد کرتا ہے۔
ترقیاتی ٹیم کو فیصلہ کرنا چاہیے کہ "ہو گیا" کا مطلب کیا ہے۔ انہیں بیٹھ کر ان خصوصیات کی فہرست بنانے کی ضرورت ہے جن کو ہر مرحلے پر پورا کرنا ضروری ہے تاکہ اسے مکمل سمجھا جا سکے۔
DoD اس عمل کو مزید شفاف بناتا ہے اور CI/CD کے نفاذ میں سہولت فراہم کرتا ہے، اگر یہ ٹیم کے تمام اراکین کے لیے واضح ہو اور اس پر باہمی اتفاق ہو۔
حقیقت پسندانہ، واضح طور پر متعین اہداف کی کمی
یہ اکثر حوالہ جات میں سے ایک ہے، لیکن یہ دہرانے کے قابل ہے۔ کسی بھی سنجیدہ اقدام کی کامیابی کے لیے، بشمول CI/CD یا DevOps کو لاگو کرنا، آپ کو حقیقت پسندانہ اہداف طے کرنے اور ان کے خلاف کارکردگی کی پیمائش کرنے کی ضرورت ہے۔ آپ CI/CD کے ساتھ کیا حاصل کرنے کی کوشش کر رہے ہیں؟ کیا یہ بہتر معیار کے ساتھ تیز ریلیز کی اجازت دیتا ہے؟
کسی بھی اہداف کا تعین نہ صرف شفاف اور حقیقت پسندانہ ہونا چاہیے، بلکہ کمپنی کی موجودہ سرگرمیوں کے ساتھ بھی ہم آہنگ ہونا چاہیے۔ مثال کے طور پر، آپ کے گاہکوں کو کتنی بار نئے پیچ یا ورژن کی ضرورت ہوتی ہے؟ اگر صارفین کو کوئی اضافی فائدہ نہیں ہوتا ہے تو عمل کو زیادہ لوڈ کرنے اور تیزی سے جاری کرنے کی ضرورت نہیں ہے۔
اس کے علاوہ، آپ کو ہمیشہ CD اور CI دونوں کو لاگو کرنے کی ضرورت نہیں ہے۔ مثال کے طور پر، انتہائی ریگولیٹڈ کمپنیاں جیسے کہ بینک اور طبی کلینک صرف CI کے ساتھ کام کر سکتے ہیں۔
DevOps کو نافذ کرنے والی کسی بھی کمپنی کے لیے CI ایک اچھا نقطہ آغاز ہے۔ جب اسے کسی کمپنی میں لاگو کیا جاتا ہے، تو سافٹ ویئر کی ترسیل کے نقطہ نظر میں نمایاں تبدیلی آتی ہے۔ CI میں مہارت حاصل کرنے کے بعد، آپ پورے عمل کو بہتر بنانے، رول آؤٹ کی رفتار بڑھانے اور دیگر تبدیلیوں کے بارے میں سوچ سکتے ہیں۔
بہت سی تنظیموں کے لیے، ایک CI کافی ہے، اور CD کو صرف اس صورت میں لاگو کیا جانا چاہیے جب یہ قدر میں اضافہ کرے۔
متعلقہ ڈیش بورڈز اور میٹرکس کی کمی
ایک بار جب آپ اہداف طے کر لیتے ہیں، ترقیاتی ٹیم KPIs کی پیمائش کے لیے ایک ڈیش بورڈ بنا سکتی ہے۔ اس کی ترقی سے پہلے، ان پیرامیٹرز کا اندازہ لگانا ضروری ہے جن کی نگرانی کی جائے گی۔
مختلف رپورٹس اور ایپلیکیشنز ٹیم کے مختلف ارکان کے لیے مفید ہیں۔ سکرم ماسٹرز حیثیت اور رسائی کے بارے میں زیادہ فکر مند ہیں۔ جبکہ سینئر انتظامیہ ماہرین کے برن آؤٹ کی شرح میں دلچسپی لے سکتی ہے۔
کچھ ٹیمیں CI/CD کی حیثیت کا اندازہ لگانے کے لیے سرخ، پیلے اور سبز اشارے والے ڈیش بورڈز کا بھی استعمال کرتی ہیں، یہ سمجھنے کے لیے کہ آیا وہ سب کچھ ٹھیک کر رہی ہیں یا کوئی غلطی ہوئی ہے۔ سرخ کا مطلب ہے کہ آپ کو اس پر توجہ دینے کی ضرورت ہے جو ہو رہا ہے۔
تاہم، اگر ڈیش بورڈز معیاری نہیں ہیں، تو وہ گمراہ کن ہو سکتے ہیں۔ تجزیہ کریں کہ ہر کسی کو کس ڈیٹا کی ضرورت ہے اور پھر اس کا کیا مطلب ہے اس کی معیاری وضاحت بنائیں۔ معلوم کریں کہ آپ کے اسٹیک ہولڈرز کے لیے کیا زیادہ معنی رکھتا ہے: گرافکس، متن، یا نمبر۔
دستی ٹیسٹ کی کمی
ٹیسٹ آٹومیشن ایک اچھی CI/CD پائپ لائن کی بنیاد رکھتا ہے۔ لیکن تمام مراحل پر خودکار جانچ کا مطلب یہ نہیں ہے کہ آپ کو دستی جانچ نہیں کرنی چاہیے۔
ایک موثر CI/CD پائپ لائن بنانے کے لیے، دستی ٹیسٹ کی بھی ضرورت ہے۔ جانچ کے ہمیشہ کچھ ایسے پہلو ہوں گے جن کے لیے انسانی تجزیہ کی ضرورت ہوتی ہے۔
پائپ لائن میں دستی جانچ کی کوششوں کو ضم کرنے پر غور کرنے کے قابل ہے۔ کچھ ٹیسٹ کیسز کی دستی جانچ مکمل ہونے کے بعد، آپ تعیناتی کے مرحلے پر جا سکتے ہیں۔
ٹیسٹ کو بہتر بنانے کی کوشش نہ کریں۔
ایک موثر CI/CD پائپ لائن کے لیے صحیح ٹولز تک رسائی کی ضرورت ہوتی ہے، چاہے وہ ٹیسٹ مینجمنٹ ہو یا انضمام اور مسلسل نگرانی۔
ایک مضبوط، معیار پر مبنی ثقافت کی تخلیق کا مقصد ہے۔ ، تعیناتی کے بعد کسٹمر کے تجربے کی نگرانی کریں، اور بہتری کو ٹریک کریں۔
یہاں کچھ عملی تجاویز ہیں جنہیں آپ آسانی سے نافذ کر سکتے ہیں:
- اس بات کو یقینی بنائیں کہ ٹیسٹ لکھنے میں آسان اور اتنے لچکدار ہیں کہ جب کوڈ کو ری فیکٹر کیا جائے تو وہ ٹوٹ نہ جائیں۔
- ڈیولپمنٹ ٹیموں کو جانچ کے عمل میں شامل کیا جانا چاہیے - صارف کے مسائل اور درخواستوں کی فہرست دیکھیں جو CI پائپ لائنز کے دوران جانچنے کے لیے اہم ہیں۔
- ہو سکتا ہے کہ آپ کے پاس مکمل ٹیسٹ کوریج نہ ہو، لیکن ہمیشہ یقینی بنائیں کہ UX اور کسٹمر کے تجربے کے لیے اہم فلوز کی جانچ کی گئی ہے۔
آخری لیکن کم از کم نکتہ
CI/CD میں منتقلی عام طور پر نیچے سے شروع کی جاتی ہے، لیکن آخر میں یہ ایک تبدیلی ہے جس میں کمپنی کی جانب سے انتظامی شمولیت، وقت اور وسائل کی ضرورت ہوتی ہے۔ سب کے بعد، CI / CD مہارت، عمل، اوزار اور ثقافتی تنظیم نو کا ایک مجموعہ ہے، اس طرح کی تبدیلیوں کو صرف منظم طریقے سے لاگو کیا جا سکتا ہے.
موضوع پر اور کیا پڑھنا ہے۔:
- .
- .
- .
ماخذ: www.habr.com