GitLab میں، ہم سافٹ ویئر کی اصلاحات کو دو طریقوں سے پروسیس کرتے ہیں: دستی اور خودکار طور پر۔ gitlab.com پر خودکار تعیناتی کے ذریعے اہم اپ ڈیٹس بنانے اور ڈیلیور کرنے کے ریلیز مینیجر کے کام کے بارے میں جاننے کے لیے پڑھیں، ساتھ ہی ساتھ صارفین کو ان کی اپنی تنصیبات پر کام کرنے کے لیے پیچ۔
میں آپ کی سمارٹ واچ پر ایک یاد دہانی ترتیب دینے کی تجویز کرتا ہوں: ہر ماہ 22 تاریخ کو، GitLab کے ساتھ اپنی سہولیات پر کام کرنے والے صارفین ہمارے پروڈکٹ کے موجودہ ورژن کی اپ ڈیٹس دیکھ سکتے ہیں۔ ماہانہ ریلیز نئی خصوصیات پر مشتمل ہے، موجودہ خصوصیات کی ترقی، اور اکثر ٹولنگ یا انضمام کے لیے کمیونٹی کی درخواستوں کا حتمی نتیجہ دکھاتا ہے۔
لیکن، جیسا کہ پریکٹس شوز، سافٹ ویئر ڈویلپمنٹ شاذ و نادر ہی خامیوں کے بغیر ہوتی ہے۔ جب کوئی بگ یا سیکیورٹی کمزوری دریافت ہوتی ہے، ڈیلیوری ٹیم میں ریلیز مینیجر ہمارے صارفین کے لیے ان کی تنصیبات کے ساتھ ایک پیچ بناتا ہے۔ Gitlab.com کو CD کے عمل کے دوران اپ ڈیٹ کیا جاتا ہے۔ ہم اس سی ڈی کے عمل کو خودکار تعیناتی کہتے ہیں تاکہ GitLab میں CD کی خصوصیت کے ساتھ الجھن سے بچا جا سکے۔ اس عمل میں صارفین، صارفین، اور ہماری داخلی ترقیاتی ٹیم کی طرف سے جمع کرائی گئی پل کی درخواستوں سے تجاویز شامل کی جا سکتی ہیں، تاکہ پیچ جاری کرنے کے بورنگ مسئلے کو دو مختلف طریقوں سے حل کیا جائے۔
«ہم اس بات کو یقینی بناتے ہیں کہ جو کچھ بھی ڈویلپرز بناتے ہیں اسے GitLab.com پر لانے سے پہلے ہر روز تمام ماحول میں تعینات کیا جاتا ہے۔"، وضاحت کرتا ہے ، سینئر ٹیکنیکل مینیجر، انفراسٹرکچر ڈیپارٹمنٹ۔ "اپنی تنصیبات کے لیے ریلیز کو gitlab.com کی تعیناتیوں کے لیے سنیپ شاٹس کے طور پر سوچیں، جس کے لیے ہم نے ایک پیکیج بنانے کے لیے الگ الگ اقدامات شامل کیے ہیں تاکہ ہمارے صارفین اسے اپنی تنصیبات پر انسٹال کرنے کے لیے استعمال کر سکیں۔'.
خرابی یا کمزوری سے قطع نظر، gitlab.com کے صارفین کو شائع ہونے کے فوراً بعد درستیاں موصول ہوں گی، جو خودکار CD کے عمل کا فائدہ ہے۔ ان کی اپنی تنصیبات والے صارفین کے لیے پیچ کو ریلیز مینیجر کی طرف سے علیحدہ تیاری کی ضرورت ہوتی ہے۔
ڈیلیوری ٹیم کم کرنے کے لیے ریلیز بنانے میں شامل زیادہ تر عمل کو خودکار بنانے کے لیے سخت محنت کر رہی ہے۔ (مطلب پروڈکشن کا وقت، یعنی پروڈکشن پر خرچ کیا گیا وقت)، ایک ڈویلپر کے ذریعے انضمام کی درخواست پر کارروائی کرنے سے لے کر gitlab.com پر تعیناتی تک کا وقت۔
«ڈیلیوری ٹیم کا مقصد اس بات کو یقینی بنانا ہے کہ ہم ایک کمپنی کے طور پر تیزی سے آگے بڑھ سکیں، یا کم از کم ڈیلیوری کرنے والے لوگوں کو تیزی سے کام کر سکیں، ٹھیک ہے؟، مارین کہتے ہیں۔
gitlab.com کے صارفین اور ان کی تنصیبات کے صارفین دونوں ڈیلیوری ٹیم کی سائیکل کے اوقات کو کم کرنے اور تعیناتیوں کو تیز کرنے کی کوششوں سے فائدہ اٹھاتے ہیں۔ اس مضمون میں ہم ان دو طریقوں کے درمیان مماثلت اور فرق کی وضاحت کریں گے۔ ، اور ہم یہ بھی بیان کریں گے کہ ہماری ڈیلیوری ٹیم کس طرح اپنی سہولیات پر کام کرنے والے صارفین کے لیے پیچ تیار کرتی ہے، اور ساتھ ہی ہم یہ بھی یقینی بناتے ہیں کہ gitlab.com خودکار تعیناتی کا استعمال کرتے ہوئے تازہ ترین ہے۔
ریلیز مینیجر کیا کرتا ہے؟
ٹیم کے ممبران ماہانہ صارفین کو ان کی سہولیات پر ہماری ریلیز، بشمول پیچ اور سیکیورٹی ریلیزز جو ریلیز کے درمیان ہو سکتی ہیں۔ وہ خودکار، مسلسل تعیناتی میں کمپنی کی منتقلی کی قیادت کرنے کے بھی ذمہ دار ہیں۔
خود انسٹالیشن ریلیز اور gitlab.com ریلیز اسی طرح کے ورک فلو کا استعمال کرتی ہیں لیکن مختلف اوقات میں چلتی ہیں، مارین بتاتی ہیں۔
سب سے پہلے اور اہم بات، ریلیز مینیجر، ریلیز کی قسم سے قطع نظر، اس بات کو یقینی بناتا ہے کہ GitLab اس وقت سے دستیاب اور محفوظ ہے جب سے gitlab.com پر ایپلیکیشن لانچ کی گئی ہے، بشمول اس بات کو یقینی بنانا کہ وہی مسائل صارفین کے بنیادی ڈھانچے میں ختم نہ ہوں۔ اپنی صلاحیتوں.
ایک بار جب گٹ لیب میں بگ یا کمزوری کو نشان زد کر دیا جاتا ہے، تو ریلیز مینیجر کو یہ جانچنا چاہیے کہ اسے ان کی تنصیبات والے صارفین کے لیے پیچ یا سیکیورٹی اپ ڈیٹس میں شامل کیا جائے گا۔ اگر وہ فیصلہ کرتا ہے کہ کوئی بگ یا کمزوری اپ ڈیٹ کا مستحق ہے، تو تیاری کا کام شروع ہو جاتا ہے۔
ریلیز مینیجر کو یہ فیصلہ کرنا چاہیے کہ آیا کوئی فکس تیار کرنا ہے، یا اسے کب تعینات کرنا ہے - اور یہ صورتحال کے تناظر پر بہت زیادہ منحصر ہے،"اس دوران، مشینیں سیاق و سباق کو منظم کرنے میں اتنی اچھی نہیں ہیں جتنی لوگوں کے"مارین کہتے ہیں.
یہ سب اصلاحات کے بارے میں ہے۔
پیچ کیا ہیں اور ہمیں ان کی ضرورت کیوں ہے؟
ریلیز مینیجر فیصلہ کرتا ہے کہ آیا بگ کی شدت کی بنیاد پر فکس جاری کرنا ہے۔
خرابیاں ان کی شدت کے لحاظ سے مختلف ہوتی ہیں۔ لہذا S4 یا S3 کی خرابیاں اسٹائلسٹک ہوسکتی ہیں، جیسے کہ پکسل یا آئیکن کی نقل مکانی۔ یہ کوئی کم اہم نہیں ہے، لیکن کسی کے ورک فلو پر کوئی خاص اثر نہیں پڑتا ہے، جس کا مطلب ہے کہ اس طرح کی S3 یا S4 غلطیوں کے لیے درست ہونے کا امکان بہت کم ہے، مارین بتاتی ہیں۔
تاہم، کمزوریوں S1 یا S2 کا مطلب ہے کہ صارف کو تازہ ترین ورژن میں اپ ڈیٹ نہیں کرنا چاہیے، یا کوئی اہم بگ ہے جو صارف کے ورک فلو کو متاثر کرتا ہے۔ اگر وہ ٹریکر میں شامل ہیں، تو بہت سے صارفین نے ان کا سامنا کیا ہے، لہذا ریلیز مینیجر فوری طور پر درست کرنے کی تیاری شروع کر دیتا ہے۔
ایک بار کمزوریوں S1 یا S2 کے لیے ایک پیچ تیار ہو جانے کے بعد، ریلیز مینیجر پیچ کو جاری کرنا شروع کر دیتا ہے۔
مثال کے طور پر، GitLab 12.10.1 پیچ کو بلاک کرنے کے متعدد مسائل کی نشاندہی کرنے کے بعد بنایا گیا تھا اور ڈویلپرز نے ان بنیادی مسئلے کو حل کیا تھا جو ان کا سبب بن رہا تھا۔ ریلیز مینیجر نے تفویض کردہ شدت کی سطحوں کی درستگی کا اندازہ لگایا، اور تصدیق کے بعد، ایک فکس جاری کرنے کا عمل شروع کیا گیا، جو کہ مسدود کرنے کے مسائل دریافت ہونے کے بعد XNUMX گھنٹوں کے اندر تیار ہو گیا۔
جب بہت سارے S4، S3 اور S2 جمع ہوتے ہیں، تو ریلیز مینیجر کسی فکس کو جاری کرنے کی عجلت کا تعین کرنے کے لیے سیاق و سباق کو دیکھتا ہے، اور جب ان میں سے ایک مخصوص تعداد تک پہنچ جاتی ہے، تو وہ سب کو یکجا کر کے چھوڑ دیا جاتا ہے۔ ریلیز کے بعد کی اصلاحات یا سیکیورٹی اپ ڈیٹس کا خلاصہ بلاگ پوسٹس میں کیا گیا ہے۔
ریلیز مینیجر پیچ کیسے بناتا ہے۔
ہم پیچ بنانے کے لیے GitLab CI اور دیگر خصوصیات جیسے اپنے ChatOps کا استعمال کرتے ہیں۔ ریلیز مینیجر ہمارے اندرونی چینل پر چیٹ اوپس ٹیم کو فعال کر کے فکس کی رہائی کو متحرک کرتا ہے۔ #releases سلیک میں.
/chatops run release prepare 12.10.1ChatOps مختلف واقعات کو متحرک کرنے کے لیے Slack کے اندر کام کرتا ہے، جن پر پھر GitLab کے ذریعے کارروائی اور عمل درآمد ہوتا ہے۔ مثال کے طور پر، ڈیلیوری ٹیم نے پیچ جاری کرنے کے لیے مختلف چیزوں کو خودکار کرنے کے لیے ChatOps ترتیب دیا۔
ایک بار ریلیز مینیجر ChatOps ٹیم کو سلیک میں شروع کر دیتا ہے، باقی کام خود بخود CICD کا استعمال کرتے ہوئے GitLab میں ہو جاتا ہے۔ ریلیز کے عمل کے دوران Slack اور GitLab میں ChatOps کے درمیان دو طرفہ مواصلت ہوتی ہے کیونکہ ریلیز مینیجر اس عمل میں کچھ اہم مراحل کو چالو کرتا ہے۔
نیچے دی گئی ویڈیو میں GitLab کے لیے پیچ تیار کرنے کا تکنیکی عمل دکھایا گیا ہے۔
gitlab.com پر خودکار تعیناتی کیسے کام کرتی ہے۔
gitlab.com کو اپ ڈیٹ کرنے کے لیے استعمال ہونے والا عمل اور ٹولز پیچ بنانے کے لیے استعمال کیے جانے والے مشابہ ہیں۔ gitlab.com کو اپ ڈیٹ کرنے کے لیے ریلیز مینیجر کے نقطہ نظر سے کم دستی کام کی ضرورت ہوتی ہے۔
ChatOps کا استعمال کرتے ہوئے تعیناتیوں کو چلانے کے بجائے، ہم CI خصوصیات کا استعمال کرتے ہیں جیسے ، جس کے ساتھ ریلیز مینیجر مطلوبہ وقت پر انجام دینے کے لئے کچھ اقدامات کا شیڈول بنا سکتا ہے۔ دستی عمل کے بجائے، ایک پائپ لائن ہے جو وقتاً فوقتاً ایک گھنٹے میں ایک بار چلتی ہے جو GitLab پروجیکٹس میں کی گئی نئی تبدیلیوں کو ڈاؤن لوڈ کرتی ہے، ان کو پیکج کرتی ہے اور تعیناتی کا شیڈول بناتی ہے، اور خود بخود ٹیسٹنگ، QA اور دیگر ضروری اقدامات کو چلاتی ہے۔
"لہذا ہمارے پاس gitlab.com سے پہلے مختلف ماحول میں بہت ساری تعیناتیاں چل رہی ہیں، اور ان ماحول کے اچھی حالت میں ہونے اور ٹیسٹنگ کے اچھے نتائج ظاہر کرنے کے بعد، ریلیز مینیجر gitlab.com کی تعیناتی کی کارروائیاں شروع کرتا ہے،" مارین کہتے ہیں۔
gitlab.com اپڈیٹس کو سپورٹ کرنے کے لیے CICD ٹیکنالوجی پورے عمل کو اس مقام تک خودکار بناتی ہے جہاں ریلیز مینیجر کو دستی طور پر gitlab.com پر پروڈکشن ماحول کی تعیناتی کا آغاز کرنا چاہیے۔
مارین نیچے دی گئی ویڈیو میں gitlab.com اپ ڈیٹ کے عمل کے بارے میں تفصیل سے جاتی ہے۔
ڈیلیوری ٹیم اور کیا کرتی ہے؟
gitlab.com اپ ڈیٹ کے عمل اور اندرون ملک صارفین کو پیچ جاری کرنے کے درمیان بنیادی فرق یہ ہے کہ بعد کے عمل میں ریلیز مینیجر سے زیادہ وقت اور زیادہ دستی کام کی ضرورت ہوتی ہے۔
مارین کا کہنا ہے کہ "ہم بعض اوقات رپورٹ شدہ مسائل، ٹولنگ کے مسائل، اور کئی باریکیوں کی وجہ سے صارفین کو ان کی تنصیبات کے ساتھ پیچ جاری کرنے میں تاخیر کرتے ہیں۔"
ڈیلیوری ٹیم کے قلیل مدتی اہداف میں سے ایک ریلیز مینیجر کی جانب سے دستی کام کی مقدار کو کم کرنا ہے تاکہ ریلیز کو تیز کیا جا سکے۔ ٹیم ریلیز کے عمل کو آسان، ہموار اور خودکار بنانے کے لیے کام کر رہی ہے، جس سے کم شدت کے مسائل (S3 اور S4، کو ٹھیک کرنے میں مدد ملے گی۔ تقریبا. مترجم)۔ رفتار پر توجہ مرکوز کرنا ایک اہم کارکردگی کا اشارہ ہے: MTTP کو کم کرنا ضروری ہے - انضمام کی درخواست موصول ہونے سے لے کر gitlab.com پر نتیجہ کو تعینات کرنے کا وقت - موجودہ 50 گھنٹے سے 8 گھنٹے تک۔
ڈیلیوری ٹیم gitlab.com کو Kubernetes پر مبنی انفراسٹرکچر میں منتقل کرنے پر بھی کام کر رہی ہے۔
ایڈیٹر کا n.b.: اگر آپ نے Kubernetes ٹیکنالوجی کے بارے میں پہلے ہی سنا ہے (اور مجھے اس میں کوئی شک نہیں کہ آپ کے پاس ہے)، لیکن ابھی تک اسے اپنے ہاتھوں سے نہیں چھوا ہے، تو میں آن لائن انٹینس کورسز میں حصہ لینے کی تجویز کرتا ہوں۔ ، جو 28-30 ستمبر کو منعقد ہوگا، اور ، جو 14-16 اکتوبر کو ہوگا۔ یہ آپ کو اعتماد کے ساتھ نیویگیٹ کرنے اور ٹیکنالوجی کے ساتھ کام کرنے کی اجازت دے گا۔
یہ دو نقطہ نظر ہیں جو ایک ہی مقصد کا تعاقب کرتے ہیں: اپ ڈیٹس کی تیز تر فراہمی، دونوں gitlab.com اور کلائنٹس کے لیے ان کی سہولیات پر۔
ہمارے لیے کوئی آئیڈیاز یا سفارشات؟
GitLab میں حصہ ڈالنے کے لیے ہر ایک کا خیرمقدم ہے، اور ہم اپنے قارئین کے تاثرات کا خیرمقدم کرتے ہیں۔ اگر آپ کے پاس ہماری ڈیلیوری ٹیم کے لیے کوئی آئیڈیاز ہیں تو ہچکچاہٹ نہ کریں۔ نوٹس کے ساتھ team: Delivery.
ماخذ: www.habr.com