اسان ڪيئن GitLab ۾ سافٽ ويئر پيچ جاري ڪريون ٿا

اسان ڪيئن GitLab ۾ سافٽ ويئر پيچ جاري ڪريون ٿا

GitLab تي، اسان ٻن طريقن سان سافٽ ويئر فيڪس کي پروسيس ڪريون ٿا: دستي ۽ خودڪار. رليز مئنيجر جي نوڪري بابت سکڻ لاءِ پڙهو اھم اپ ڊيٽون ٺاهڻ ۽ پهچائڻ جي خودڪار طريقي سان gitlab.com تي، ۽ گڏوگڏ پيچس استعمال ڪندڙن لاءِ انھن جي پنھنجي تنصيب تي ڪم ڪرڻ لاءِ.

مان توهان جي سمارٽ واچ تي هڪ ياد ڏياريندڙ ترتيب ڏيڻ جي صلاح ڏيان ٿو: هر مهيني 22 تاريخ تي، استعمال ڪندڙ GitLab سان ڪم ڪري رهيا آهن انهن جي سهولتن تي اسان جي پراڊڪٽ جي موجوده ورزن تي تازه ڪاريون ڏسي سگهن ٿا. مھينا رليز ۾ نيون خصوصيتون شامل آھن، موجود آھن جي ترقي، ۽ اڪثر ڪري ڏيکاري ٿو آخري نتيجو ٽولنگ يا ضم ڪرڻ لاءِ ڪميونٽي جي درخواستن جو.

پر، جيئن مشق ڏيکاري ٿو، سافٽ ويئر ڊولپمينٽ گهٽ ۾ گهٽ خامين کان سواء آهي. جڏهن ڪو بگ يا سيڪيورٽي ڪمزوري دريافت ٿئي ٿي، پهچائڻ واري ٽيم ۾ رليز مينيجر اسان جي استعمال ڪندڙن لاءِ انهن جي تنصيب سان هڪ پيچ ٺاهي ٿو. Gitlab.com سي ڊي جي عمل دوران اپڊيٽ ڪئي وئي آهي. GitLab ۾ سي ڊي جي خصوصيت سان مونجهاري کان بچڻ لاءِ اسان هن سي ڊي جي عمل کي پاڻمرادو تعیناتي سڏين ٿا. اهو عمل صارفين، گراهڪن، ۽ اسان جي اندروني ترقياتي ٽيم پاران پيش ڪيل پل درخواستن مان تجويزون شامل ڪري سگھن ٿا، انهي ڪري ته پيچ ڇڏڻ جي بورنگ مسئلي کي حل ڪرڻ ٻن مختلف طريقن سان حل ڪيو وڃي.

«اسان انهي ڳالهه کي يقيني بڻايون ٿا ته ڊولپر جيڪي ٺاهيندا آهن هر روز ان کي GitLab.com ڏانهن رول آئوٽ ڪرڻ کان پهريان سڀني ماحولن ۾ لڳايو ويندو آهي."، وضاحت ڪري ٿو مارين جانڪوڪي، سينئر ٽيڪنيڪل مئنيجر، انفراسٽرڪچر ڊپارٽمينٽ. "توهان جي تنصيب لاءِ رليز جي باري ۾ سوچيو جيئن سنيپ شاٽ لاءِ gitlab.com ڊپلوميٽس، جنهن لاءِ اسان هڪ پيڪيج ٺاهڻ لاءِ الڳ قدم شامل ڪيا آهن ته جيئن اسان جا صارف ان کي استعمال ڪري سگهن انهن جي تنصيب تي انسٽال ڪرڻ لاءِ».

بغير ڪنهن خرابي يا نقصان جي، gitlab.com گراهڪ شايع ٿيڻ کان پوءِ جلد ئي فيڪس وصول ڪندا، جيڪو خودڪار ٿيل سي ڊي جي عمل جو فائدو آهي. استعمال ڪندڙن لاءِ پيچس انھن جي پنھنجي تنصيب سان رليز مئنيجر پاران الڳ تيار ڪرڻ جي ضرورت آھي.

پهچائڻ واري ٽيم سخت محنت ڪري رهي آهي خودڪار ڪرڻ لاءِ اڪثر عمل کي گهٽائڻ لاءِ رليز ٺاهڻ ۾ شامل ايم ٽي پي (مطلب پيداوار لاءِ وقت، يعني پيداوار تي خرچ ٿيل وقت)، ڊولپر طرفان ضم ٿيڻ جي درخواست کي پروسيس ڪرڻ کان وٺي وقت جو عرصو gitlab.com تي مقرر ڪرڻ لاءِ.

«ترسيل ٽيم جو مقصد اهو يقيني بڻائڻ آهي ته اسان هڪ ڪمپني جي طور تي تيزيءَ سان اڳتي وڌي سگهون ٿا، يا گهٽ ۾ گهٽ ترسيل ماڻهن کي تيزيءَ سان ڪم ڪري سگهون ٿا، صحيح؟، مارين چوي ٿو.

ٻئي gitlab.com گراهڪ ۽ انهن جي تنصيب جا استعمال ڪندڙ ڊليوري ٽيم جي ڪوششن مان فائدو وٺن ٿا ته سائيڪل جي وقت کي گهٽائڻ ۽ تعیناتي کي تيز ڪرڻ. هن آرٽيڪل ۾ اسان انهن ٻنهي طريقن جي وچ ۾ هڪجهڙائي ۽ فرق جي وضاحت ڪنداسين. مسئلا، ۽ اسان اهو به بيان ڪنداسين ته اسان جي ترسيل ٽيم سائيٽ تي هلندڙ صارفين لاءِ پيچ ڪيئن تيار ڪري ٿي، ۽ ڪيئن اسان gitlab.com کي خودڪار طريقي سان استعمال ڪندي تازه ڪاري رکون ٿا.

رليز مينيجر ڇا ڪندو آهي؟

ٽيم ميمبر مھينا رليز مينيجر جي ڪردار کي منتقلي اسان جي رليز صارفين کي انهن جي سهولتن تي، بشمول پيچ ۽ سيڪيورٽي رليز جيڪي رليز جي وچ ۾ ٿي سگهن ٿيون. اهي ڪمپني جي منتقلي کي خودڪار، مسلسل تعیناتي جي اڳواڻي لاء پڻ ذميوار آهن.

خود تنصيب رليز ۽ gitlab.com رليز ساڳيو ڪم فلوز استعمال ڪن ٿيون پر مختلف وقتن تي هلن ٿيون، مارين وضاحت ڪري ٿي.

سڀ کان پهريان ۽ سڀ کان اهم، رليز مئنيجر، رليز جي قسم جي پرواهه ڪرڻ کان سواء، انهي ڳالهه کي يقيني بڻائي ٿو ته GitLab موجود آهي ۽ محفوظ آهي ان وقت کان جڏهن ايپليڪيشن شروع ڪئي وئي آهي gitlab.com، انهي کي يقيني بڻائڻ ته اهي ساڳيون مسئلا گراهڪن جي انفراسٽرڪچر ۾ ختم نه ٿين. ذاتي صلاحيتون.

GitLab ۾ هڪ ڀيرو بگ يا نقصان جو نشان لڳايو ويو آهي، رليز مئنيجر کي اهو اندازو لڳائڻ گهرجي ته اهو انهن جي تنصيب سان استعمال ڪندڙن لاءِ پيچ يا سيڪيورٽي اپڊيٽ ۾ شامل ڪيو ويندو. جيڪڏهن هو فيصلو ڪري ٿو ته هڪ بگ يا نقصان هڪ تازه ڪاري جو مستحق آهي، تياري وارو ڪم شروع ٿئي ٿو.

رليز مئنيجر کي اهو فيصلو ڪرڻ گهرجي ته ڇا هڪ فيڪس تيار ڪرڻ، يا ان کي ڪڏهن ترتيب ڏيڻ - ۽ اهو انتهائي منحصر آهي صورتحال جي حوالي سان، "ساڳئي وقت ۾، مشينون ماڻهن جي حوالي سان انتظام ڪرڻ ۾ سٺو نه آهن"مارين چوي ٿو.

اهو سڀ ڪجهه fixes جي باري ۾ آهي

پيچ ڇا آهن ۽ اسان کي انهن جي ضرورت ڇو آهي؟

رليز مئنيجر فيصلو ڪري ٿو ته ڇا بگ جي شدت جي بنياد تي فيڪس جاري ڪرڻ گهرجي.

غلطيون مختلف آهن انهن جي شدت جي لحاظ کان. تنهن ڪري S4 يا S3 غلطيون اسٽائلسٽڪ ٿي سگھن ٿيون، جهڙوڪ پکسل يا آئڪن جي بي گھرڻ. اهو گهٽ اهم ناهي، پر ڪنهن جي ڪم جي فلو تي ڪو خاص اثر نه آهي، جنهن جو مطلب آهي ته ممڪن آهي ته اهڙي S3 يا S4 غلطين لاء هڪ حل پيدا ڪيو ويندو ننڍڙو آهي، مارين بيان ڪري ٿو.

جڏهن ته، نقصانڪار S1 يا S2 جو مطلب آهي ته صارف کي جديد ورزن تي تازه ڪاري نه ڪرڻ گهرجي، يا اتي هڪ اهم بگ آهي جيڪو صارف جي ڪم جي فلو کي متاثر ڪري ٿو. جيڪڏهن اهي ٽريڪٽر ۾ شامل ڪيا ويا آهن، ڪيترن ئي صارفين انهن سان منهن ڪيو آهي، تنهن ڪري رليز مينيجر فوري طور تي هڪ حل تيار ڪرڻ شروع ڪري ٿو.

هڪ دفعي هڪ پيچ لاءِ پيچ تيار ٿئي ٿو S1 يا S2، رليز مينيجر پيچ کي جاري ڪرڻ شروع ڪري ٿو.

مثال طور، GitLab 12.10.1 پيچ ٺاهي وئي ڪيترن ئي بلاڪنگ مسئلن جي نشاندهي ڪرڻ کان پوء ۽ ڊولپرز ان بنيادي مسئلي کي طئي ڪيو جيڪو انهن جو سبب بڻيل هو. رليز مئنيجر مقرر ڪيل شدت جي سطحن جي درستگي جو جائزو ورتو، ۽ تصديق ڪرڻ کان پوء، فيڪس جاري ڪرڻ جو عمل شروع ڪيو ويو، جيڪو بلاڪنگ مسئلن جي دريافت ٿيڻ کان پوء XNUMX ڪلاڪن اندر تيار ڪيو ويو.

جڏھن گھڻا S4، S3 ۽ S2 گڏ ٿين ٿا، رليز مئنيجر ھڪ فڪس جاري ڪرڻ جي تڪميل کي طئي ڪرڻ لاءِ حوالي سان ڏسندو آھي، ۽ جڏھن انھن مان ھڪ خاص تعداد تائين پھچي ويندو آھي، اھي سڀ گڏ ڪري ڇڏيا ويندا آھن. پوسٽ رليز فيڪس يا سيڪيورٽي اپڊيٽس بلاگ پوسٽن ۾ اختصار ڪيا ويا آهن.

ڪيئن هڪ رليز مينيجر پيچ ٺاهي ٿو

اسان استعمال ڪريون ٿا GitLab CI ۽ ٻيون خاصيتون جهڙوڪ اسان جي ChatOps پيچ ٺاهڻ لاءِ. رليز مئنيجر اسان جي اندروني چينل تي ChatOps ٽيم کي چالو ڪندي فڪس جي ڇڏڻ شروع ڪري ٿو #releases سست ۾.

/chatops run release prepare 12.10.1

ChatOps Slack جي اندر مختلف واقعن کي متحرڪ ڪرڻ لاءِ ڪم ڪري ٿو، جيڪي پوءِ GitLab پاران پروسيس ۽ عمل ڪيا وڃن ٿا. مثال طور، ترسيل ٽيم سيٽ اپ ڪيو ChatOps مختلف شين کي خودڪار ڪرڻ لاءِ پيچ ڇڏڻ لاءِ.

هڪ دفعو رليز مينيجر ChatOps ٽيم کي Slack ۾ شروع ڪري ٿو، باقي ڪم CICD استعمال ڪندي GitLab ۾ خودڪار طريقي سان ٿئي ٿو. رليز جي عمل دوران Slack ۽ GitLab ۾ ChatOps جي وچ ۾ ٻه طرفي ڪميونيڪيشن آهي جيئن رليز مئنيجر عمل ۾ ڪجهه اهم مرحلن کي چالو ڪري ٿو.

هيٺ ڏنل وڊيو GitLab لاءِ پيچ تيار ڪرڻ جي ٽيڪنيڪل عمل کي ڏيکاري ٿي.

gitlab.com تي ڪيئن خودڪار لڳائڻ جو ڪم

gitlab.com کي اپڊيٽ ڪرڻ لاءِ استعمال ٿيندڙ عمل ۽ اوزار ساڳيا آهن جيڪي پيچ ٺاهڻ لاءِ استعمال ڪيا ويندا آهن. gitlab.com کي اپڊيٽ ڪرڻ لاءِ رليز مئنيجر جي نقطه نظر کان گهٽ دستي ڪم جي ضرورت آهي.

ChatOps استعمال ڪندي ڊيپلائيمينٽ هلائڻ بدران، اسان استعمال ڪريون ٿا CI خاصيتون مثال طور. مقرر ڪيل پائپ لائنون، جنهن سان رليز مئنيجر گهربل وقت تي ڪجهه عملن کي شيڊول ڪري سگهي ٿو. هڪ دستي عمل جي بدران، هڪ پائيپ لائين آهي جيڪا وقتي طور تي هڪ ڪلاڪ ۾ هڪ ڀيرو هلندي آهي جيڪا GitLab منصوبن ۾ ڪيل نئين تبديلين کي ڊائون لوڊ ڪري ٿي، انهن کي پيڪيجز ۽ شيڊول جي ترتيب کي ترتيب ڏئي ٿي، ۽ خودڪار طريقي سان جانچ، QA ۽ ٻين ضروري قدمن کي هلائي ٿو.

”تنهنڪري اسان وٽ ڪيتريون ئي ڊيپلائيمينٽيون مختلف ماحول ۾ هلنديون آهن gitlab.com کان اڳ، ۽ پوءِ اهي ماحول سٺي شڪل ۾ آهن ۽ جاچ سٺا نتيجا ڏيکاريندي آهي، رليز مئنيجر شروع ڪري ٿو gitlab.com جي مقرري واري عمل کي،“ مارين چوي ٿو.

CICD ٽيڪنالاجي کي سپورٽ ڪرڻ لاءِ gitlab.com اپڊيٽس پوري عمل کي خودڪار ڪري ٿو ان نقطي تي جتي رليز مئنيجر کي لازمي طور تي پيداوار جي ماحول جي ترتيب کي شروع ڪرڻ گهرجي gitlab.com تي.

مارين هيٺ ڏنل وڊيو ۾ gitlab.com تازه ڪاري جي عمل بابت تفصيل ۾ وڃي ٿي.

ترسيل ٽيم ٻيو ڇا ڪندو؟

gitlab.com اپڊيٽ جي عملن جي وچ ۾ بنيادي فرق ۽ گراهڪ کي گهر ۾ پيچ جاري ڪرڻ اهو آهي ته بعد ۾ پروسيس وڌيڪ وقت ۽ رليز مينيجر کان وڌيڪ دستي ڪم جي ضرورت آهي.

”اسان ڪڏهن ڪڏهن گراهڪن کي پيچ جاري ڪرڻ ۾ دير ڪندا آهيون انهن جي تنصيب سان رپورٽ ٿيل مسئلن جي ڪري ، ٽولنگ جا مسئلا ، ۽ ڇاڪاڻ ته اتي ڪيتريون ئي نونسون آهن جن کي هڪ پيچ جاري ڪرڻ وقت ڌيان ۾ رکڻ جي ضرورت آهي ،“ مارين چوي ٿو.

ترسيل ٽيم جي مختصر مدت جي مقصدن مان هڪ آهي ڇڏڻ جي رفتار کي تيز ڪرڻ لاءِ رليز مينيجر جي حصي تي دستي ڪم جي مقدار کي گهٽائڻ. ٽيم ڪم ڪري رهي آهي آسان ڪرڻ، اسٽريم لائن، ۽ رليز جي عمل کي خودڪار ڪرڻ لاءِ، جيڪا مدد ڪندي گهٽ شدت واري مسئلن کي حل ڪرڻ ۾ (S3 ۽ S4، لڳ ڀڳ مترجم). رفتار تي ڌيان ڏيڻ هڪ اهم ڪارڪردگي جو اشارو آهي: اهو ضروري آهي ته MTTP کي گھٽائڻ - ضم ڪرڻ جي درخواست حاصل ڪرڻ کان وٺي نتيجو کي ترتيب ڏيڻ تائين gitlab.com - موجوده 50 ڪلاڪن کان 8 ڪلاڪ.

ترسيل ٽيم پڻ ڪم ڪري رهي آهي gitlab.com کي Kubernetes-based infrastructure ڏانهن منتقل ڪرڻ تي.

ايڊيٽر جي n.b.: جيڪڏهن توهان اڳ ۾ ئي Kubernetes ٽيڪنالاجي جي باري ۾ ٻڌو آهي (۽ مون کي ڪو شڪ ناهي ته توهان وٽ آهي)، پر اڃا تائين توهان جي هٿن سان ان کي هٿ نه ڪيو آهي، آئون توهان کي آن لائن سخت ڪورسز ۾ حصو وٺڻ جي صلاح ڏيو. ڪبرنيٽس جو بنياد، جيڪو سيپٽمبر 28-30 تي منعقد ٿيندو، ۽ ڪبرنيٽس ميگا، جيڪو 14-16 آڪٽوبر تي ٿيندو. اهو توهان کي اعتماد سان نيويگيٽ ڪرڻ ۽ ٽيڪنالاجي سان ڪم ڪرڻ جي اجازت ڏيندو.

اهي ٻه طريقا آهن جيڪي هڪ ئي مقصد جي تعاقب ڪن ٿا: اپڊيٽ جي تيز ترسيل، ٻنهي لاءِ gitlab.com ۽ گراهڪن لاءِ انهن جي سهولتن تي.

اسان لاء ڪي خيال يا سفارشون؟

GitLab ۾ حصو وٺڻ لاءِ هرڪو ڀليڪار آهي، ۽ اسان پنهنجي پڙهندڙن جي موٽ ۾ ڀليڪار ڪيون ٿا. جيڪڏھن توھان وٽ اسان جي ترسيل ٽيم لاءِ ڪي خيال آھن، سنکوڪ نه ڪريو هڪ درخواست ٺاهيو نوٽيس سان team: Delivery.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو