কিভাবে আমরা গিটল্যাবে সফ্টওয়্যার ফিক্স রিলিজ করি

গিটল্যাবে, আমরা দুটি উপায়ে সফ্টওয়্যার সংশোধন প্রক্রিয়া করি: ম্যানুয়ালি এবং স্বয়ংক্রিয়ভাবে। gitlab.com-এ স্বয়ংক্রিয় স্থাপনার মাধ্যমে গুরুত্বপূর্ণ আপডেটগুলি তৈরি এবং সরবরাহ করার রিলিজ ম্যানেজারের কাজ সম্পর্কে জানতে পড়ুন, সেইসাথে ব্যবহারকারীদের তাদের নিজস্ব ইনস্টলেশনে কাজ করার জন্য প্যাচগুলি।

আমি আপনার স্মার্টওয়াচে একটি অনুস্মারক সেট করার পরামর্শ দিচ্ছি: প্রতি মাসের 22 তারিখে, GitLab-এর সাথে কাজ করা ব্যবহারকারীরা আমাদের পণ্যের বর্তমান সংস্করণের আপডেট দেখতে পাবেন। মাসিক রিলিজে নতুন বৈশিষ্ট্য, বিদ্যমান বৈশিষ্ট্যগুলির বিকাশ রয়েছে এবং প্রায়শই টুলিং বা মার্জ করার জন্য সম্প্রদায়ের অনুরোধের শেষ ফলাফল দেখায়।

কিন্তু, অনুশীলন দেখায়, সফ্টওয়্যার বিকাশ খুব কমই ত্রুটি ছাড়াই হয়। যখন একটি বাগ বা নিরাপত্তা দুর্বলতা আবিষ্কৃত হয়, তখন ডেলিভারি দলের রিলিজ ম্যানেজার আমাদের ব্যবহারকারীদের জন্য তাদের ইনস্টলেশনের সাথে একটি প্যাচ তৈরি করে। সিডি প্রক্রিয়া চলাকালীন Gitlab.com আপডেট করা হয়। গিটল্যাবে সিডি বৈশিষ্ট্যের সাথে বিভ্রান্তি এড়াতে আমরা এই সিডি প্রক্রিয়াটিকে স্বয়ংক্রিয় স্থাপনা বলি। এই প্রক্রিয়াটি ব্যবহারকারীদের, গ্রাহকদের এবং আমাদের অভ্যন্তরীণ উন্নয়ন দলের দ্বারা জমা দেওয়া পুল অনুরোধ থেকে পরামর্শগুলিকে অন্তর্ভুক্ত করতে পারে, যাতে প্যাচগুলি প্রকাশ করার বিরক্তিকর সমস্যাটি দুটি ভিন্ন উপায়ে সমাধান করা হয়।

«আমরা নিশ্চিত করি যে বিকাশকারীরা যা কিছু তৈরি করে তা GitLab.com-এ রোল আউট করার আগে প্রতিদিন সমস্ত পরিবেশে স্থাপন করা হয়।", ব্যাখ্যা করে মারিন জানকোভকি, সিনিয়র টেকনিক্যাল ম্যানেজার, অবকাঠামো বিভাগ। "gitlab.com স্থাপনার স্ন্যাপশট হিসাবে আপনার ইনস্টলেশনের রিলিজগুলিকে ভাবুন, যার জন্য আমরা একটি প্যাকেজ তৈরি করার জন্য আলাদা পদক্ষেপ যুক্ত করেছি যাতে আমাদের ব্যবহারকারীরা তাদের ইনস্টলেশনে ইনস্টল করতে এটি ব্যবহার করতে পারে».

বাগ বা দুর্বলতা নির্বিশেষে, gitlab.com গ্রাহকরা প্রকাশের পরেই সমাধান পাবেন, যা স্বয়ংক্রিয় সিডি প্রক্রিয়ার একটি সুবিধা। ব্যবহারকারীদের নিজস্ব ইনস্টলেশন সহ প্যাচগুলির জন্য রিলিজ ম্যানেজার দ্বারা পৃথক প্রস্তুতির প্রয়োজন হয়।

ডেলিভারি দল কমাতে রিলিজ তৈরির সাথে জড়িত বেশিরভাগ প্রক্রিয়াগুলিকে স্বয়ংক্রিয় করতে কঠোর পরিশ্রম করছে এমটিটিপি (উৎপাদনের জন্য সময়, অর্থাত্ উত্পাদনে ব্যয় করা সময়), একজন বিকাশকারীর দ্বারা gitlab.com-এ স্থাপনার জন্য একটি মার্জ অনুরোধ প্রক্রিয়াকরণের সময়কাল।

«ডেলিভারি টিমের লক্ষ্য হল নিশ্চিত করা যে আমরা একটি কোম্পানি হিসাবে দ্রুত অগ্রসর হতে পারি বা অন্তত ডেলিভারি লোকেদের দ্রুত কাজ করতে পারি, ঠিক?, মারিন বলেছেন।

gitlab.com গ্রাহক এবং তাদের ইনস্টলেশনের ব্যবহারকারী উভয়ই চক্রের সময় কমাতে এবং স্থাপনার গতি বাড়ানোর জন্য ডেলিভারি দলের প্রচেষ্টা থেকে উপকৃত হয়। এই নিবন্ধে আমরা এই দুটি পদ্ধতির মধ্যে মিল এবং পার্থক্য ব্যাখ্যা করব। সমস্যা, এবং আমরা আরও বর্ণনা করব যে কীভাবে আমাদের ডেলিভারি টিম তাদের সুবিধাগুলিতে কাজ করা ব্যবহারকারীদের জন্য প্যাচ প্রস্তুত করে, সেইসাথে আমরা কীভাবে নিশ্চিত করি যে gitlab.com স্বয়ংক্রিয় স্থাপনা ব্যবহার করে আপ টু ডেট আছে।

রিলিজ ম্যানেজার কি করে?

দলের সদস্যদের মাসিক রিলিজ ম্যানেজারের ভূমিকা হস্তান্তর করুন আমাদের রিলিজগুলি ব্যবহারকারীদের জন্য তাদের সুবিধাগুলিতে, প্যাচ এবং সুরক্ষা রিলিজ সহ যা রিলিজের মধ্যে ঘটতে পারে। তারা স্বয়ংক্রিয়, ক্রমাগত স্থাপনায় কোম্পানির রূপান্তরের নেতৃত্ব দেওয়ার জন্যও দায়ী।

স্ব-ইনস্টলেশন রিলিজ এবং gitlab.com রিলিজ একই ধরনের ওয়ার্কফ্লো ব্যবহার করে কিন্তু বিভিন্ন সময়ে চলে, মারিন ব্যাখ্যা করেন।

প্রথমত এবং সর্বাগ্রে, রিলিজ ম্যানেজার, রিলিজের ধরন নির্বিশেষে, Gitlab.com-এ অ্যাপ্লিকেশন চালু হওয়ার মুহূর্ত থেকে GitLab উপলব্ধ এবং সুরক্ষিত রয়েছে তা নিশ্চিত করে, যাতে গ্রাহকদের অবকাঠামোতে একই সমস্যাগুলি শেষ না হয় তা নিশ্চিত করা নিজস্ব ক্ষমতা।

গিটল্যাবে একটি বাগ বা দুর্বলতা চিহ্নিত করা হলে, রিলিজ ম্যানেজারকে অবশ্যই মূল্যায়ন করতে হবে যে এটি তাদের ইনস্টলেশন সহ ব্যবহারকারীদের জন্য প্যাচ বা নিরাপত্তা আপডেটগুলিতে অন্তর্ভুক্ত করা হবে। যদি তিনি সিদ্ধান্ত নেন যে একটি বাগ বা দুর্বলতা একটি আপডেটের যোগ্য, প্রস্তুতিমূলক কাজ শুরু হয়।

রিলিজ ম্যানেজারকে অবশ্যই সিদ্ধান্ত নিতে হবে যে একটি ফিক্স প্রস্তুত করতে হবে, বা কখন এটি স্থাপন করতে হবে - এবং এটি পরিস্থিতির প্রেক্ষাপটের উপর অত্যন্ত নির্ভরশীল, "ইতিমধ্যে, মেশিনগুলি মানুষের মতো প্রসঙ্গ পরিচালনায় ততটা ভাল নয়"মারিন বলেছেন।

এটা ঠিক করা সম্পর্কে সব

প্যাচ কি এবং কেন আমাদের তাদের প্রয়োজন?

রিলিজ ম্যানেজার বাগটির তীব্রতার উপর ভিত্তি করে একটি ফিক্স প্রকাশ করবেন কিনা তা সিদ্ধান্ত নেয়।

ত্রুটিগুলি তাদের তীব্রতার উপর নির্ভর করে পরিবর্তিত হয়। তাই S4 বা S3 ত্রুটি শৈলীগত হতে পারে, যেমন পিক্সেল বা আইকন স্থানচ্যুতি। এটি কম গুরুত্বপূর্ণ নয়, তবে কারও কর্মপ্রবাহের উপর কোনও উল্লেখযোগ্য প্রভাব নেই, যার অর্থ এই জাতীয় S3 বা S4 ত্রুটিগুলির জন্য একটি সংশোধন হওয়ার সম্ভাবনা কম, মারিন ব্যাখ্যা করেছেন।

যাইহোক, দুর্বলতা S1 বা S2 এর মানে হল যে ব্যবহারকারীর সর্বশেষ সংস্করণে আপডেট করা উচিত নয়, অথবা একটি উল্লেখযোগ্য বাগ আছে যা ব্যবহারকারীর কর্মপ্রবাহকে প্রভাবিত করে। যদি তারা ট্র্যাকারে অন্তর্ভুক্ত করা হয়, অনেক ব্যবহারকারী তাদের সম্মুখীন হয়েছে, তাই রিলিজ ম্যানেজার অবিলম্বে একটি ফিক্স প্রস্তুত করা শুরু করে।

একবার দুর্বলতার জন্য একটি প্যাচ S1 বা S2 প্রস্তুত হলে, রিলিজ ম্যানেজার প্যাচটি প্রকাশ করা শুরু করে।

উদাহরণস্বরূপ, গিটল্যাব 12.10.1 প্যাচ তৈরি করা হয়েছিল বেশ কয়েকটি ব্লকিং সমস্যা চিহ্নিত করার পরে এবং বিকাশকারীরা অন্তর্নিহিত সমস্যাটি ঠিক করেছে যা তাদের কারণ ছিল। রিলিজ ম্যানেজার নির্ধারিত তীব্রতা স্তরের সঠিকতা মূল্যায়ন করেছেন এবং নিশ্চিতকরণের পরে, একটি ফিক্স প্রকাশের প্রক্রিয়া চালু করা হয়েছিল, যা ব্লকিং সমস্যাগুলি আবিষ্কৃত হওয়ার XNUMX ঘন্টার মধ্যে প্রস্তুত ছিল।

যখন প্রচুর S4, S3 এবং S2 জমা হয়, তখন রিলিজ ম্যানেজার একটি ফিক্স রিলিজের জরুরীতা নির্ধারণের জন্য প্রেক্ষাপটটি দেখেন এবং যখন তাদের একটি নির্দিষ্ট সংখ্যায় পৌঁছে যায়, তখন সেগুলিকে একত্রিত করে ছেড়ে দেওয়া হয়। পোস্ট-রিলিজ সংশোধন বা নিরাপত্তা আপডেট ব্লগ পোস্টে সংক্ষিপ্ত করা হয়.

কিভাবে একটি রিলিজ ম্যানেজার প্যাচ তৈরি করে

আমরা প্যাচ তৈরি করতে GitLab CI এবং আমাদের ChatOps-এর মতো অন্যান্য বৈশিষ্ট্য ব্যবহার করি। রিলিজ ম্যানেজার আমাদের অভ্যন্তরীণ চ্যানেলে ChatOps টিম সক্রিয় করার মাধ্যমে ফিক্স রিলিজ শুরু করে #releases স্ল্যাকের মধ্যে

/chatops run release prepare 12.10.1

চ্যাটপস স্ল্যাকের মধ্যে বিভিন্ন ইভেন্ট ট্রিগার করতে কাজ করে, যেগুলি পরে গিটল্যাব দ্বারা প্রক্রিয়া করা হয় এবং কার্যকর করা হয়। উদাহরণ স্বরূপ, ডেলিভারি দল প্যাচ রিলিজ করার জন্য বিভিন্ন জিনিস স্বয়ংক্রিয় করতে ChatOps সেট আপ করেছে।

রিলিজ ম্যানেজার একবার Slack-এ ChatOps টিম শুরু করলে, বাকি কাজ CICD ব্যবহার করে GitLab-এ স্বয়ংক্রিয়ভাবে হয়ে যায়। রিলিজ প্রক্রিয়া চলাকালীন স্ল্যাক এবং গিটল্যাবের মধ্যে চ্যাটপসের মধ্যে দ্বিমুখী যোগাযোগ রয়েছে কারণ রিলিজ ম্যানেজার প্রক্রিয়াটির কয়েকটি প্রধান পদক্ষেপ সক্রিয় করে।

নীচের ভিডিওটি গিটল্যাবের জন্য একটি প্যাচ প্রস্তুত করার প্রযুক্তিগত প্রক্রিয়া দেখায়।

কিভাবে স্বয়ংক্রিয় স্থাপনা gitlab.com এ কাজ করে

gitlab.com আপডেট করার জন্য ব্যবহৃত প্রক্রিয়া এবং সরঞ্জামগুলি প্যাচ তৈরি করতে ব্যবহৃত একই রকম। gitlab.com আপডেট করার জন্য রিলিজ ম্যানেজারের দৃষ্টিকোণ থেকে কম ম্যানুয়াল কাজ প্রয়োজন।

ChatOps ব্যবহার করে স্থাপনা চালানোর পরিবর্তে, আমরা CI বৈশিষ্ট্যগুলি ব্যবহার করি যেমন নির্ধারিত পাইপলাইন, যার সাহায্যে রিলিজ ম্যানেজার প্রয়োজনীয় সময়ে সঞ্চালিত হওয়ার জন্য নির্দিষ্ট কর্ম নির্ধারণ করতে পারে। একটি ম্যানুয়াল প্রক্রিয়ার পরিবর্তে, একটি পাইপলাইন রয়েছে যা পর্যায়ক্রমে ঘন্টায় একবার চলে যা গিটল্যাব প্রকল্পগুলিতে করা নতুন পরিবর্তনগুলি ডাউনলোড করে, সেগুলিকে প্যাকেজ করে এবং স্থাপনার সময়সূচী করে এবং স্বয়ংক্রিয়ভাবে পরীক্ষা, QA এবং অন্যান্য প্রয়োজনীয় পদক্ষেপগুলি চালায়।

"সুতরাং gitlab.com এর আগে আমাদের বিভিন্ন পরিবেশে প্রচুর স্থাপনা চলছে, এবং সেই পরিবেশগুলি ভাল অবস্থায় থাকার পরে এবং পরীক্ষায় ভাল ফলাফল দেখানোর পরে, রিলিজ ম্যানেজার gitlab.com স্থাপনার ক্রিয়া শুরু করে," মারিন বলেছেন।

gitlab.com আপডেটগুলিকে সমর্থন করার জন্য CICD প্রযুক্তি সম্পূর্ণ প্রক্রিয়াটিকে এমন জায়গায় স্বয়ংক্রিয় করে দেয় যেখানে রিলিজ ম্যানেজারকে অবশ্যই gitlab.com-এ উত্পাদন পরিবেশের স্থাপনা ম্যানুয়ালি চালু করতে হবে।

মারিন নীচের ভিডিওতে gitlab.com আপডেট প্রক্রিয়া সম্পর্কে বিস্তারিতভাবে যান।

ডেলিভারি টিম আর কি করে?

gitlab.com আপডেট প্রক্রিয়া এবং ইন-হাউস গ্রাহকদের প্যাচ রিলিজ করার মধ্যে প্রধান পার্থক্য হল যে পরবর্তী প্রক্রিয়াটির জন্য রিলিজ ম্যানেজারের কাছ থেকে আরও বেশি সময় এবং আরও ম্যানুয়াল কাজ প্রয়োজন।

"আমরা কখনও কখনও গ্রাহকদের তাদের ইনস্টলেশনের সাথে প্যাচগুলি প্রকাশ করতে বিলম্ব করি কারণ রিপোর্ট করা সমস্যা, টুলিং সমস্যা এবং কারণ একটি একক প্যাচ প্রকাশ করার সময় অনেকগুলি সূক্ষ্মতা বিবেচনায় নেওয়া দরকার," মারিন বলেছেন৷

ডেলিভারি দলের স্বল্পমেয়াদী লক্ষ্যগুলির মধ্যে একটি হল রিলিজ ম্যানেজারের অংশে ম্যানুয়াল কাজের পরিমাণ হ্রাস করা রিলিজের গতি বাড়ানো। দলটি রিলিজ প্রক্রিয়াটিকে সরল, স্ট্রীমলাইন এবং স্বয়ংক্রিয় করার জন্য কাজ করছে, যা কম তীব্রতার সমস্যাগুলির সমাধান পেতে সাহায্য করবে (S3 এবং S4, প্রায়. অনুবাদক) গতির উপর ফোকাস করা হল একটি মূল কর্মক্ষমতা সূচক: এমটিটিপি কমাতে হবে - একটি মার্জ রিকোয়েস্ট পাওয়ার পর থেকে gitlab.com-এ ফলাফল স্থাপন করার সময় - বর্তমান 50 ঘন্টা থেকে 8 ঘন্টা।

ডেলিভারি দলটি কুবারনেটস-ভিত্তিক পরিকাঠামোতে gitlab.com স্থানান্তরিত করার জন্যও কাজ করছে।

সম্পাদকের n.b.: আপনি যদি ইতিমধ্যে কুবারনেটস প্রযুক্তি সম্পর্কে শুনে থাকেন (এবং আমার কোন সন্দেহ নেই যে আপনার কাছে আছে), কিন্তু এখনও আপনার হাত দিয়ে এটি স্পর্শ না করে থাকেন, আমি অনলাইন নিবিড় কোর্সে অংশ নেওয়ার পরামর্শ দিই কুবারনেটস বেস, যা 28-30 সেপ্টেম্বর অনুষ্ঠিত হবে, এবং কুবারনেটস মেগা, যা 14-16 অক্টোবর অনুষ্ঠিত হবে। এটি আপনাকে আত্মবিশ্বাসের সাথে নেভিগেট করতে এবং প্রযুক্তির সাথে কাজ করার অনুমতি দেবে।

এই দুটি পন্থা যা একই লক্ষ্য অনুসরণ করে: gitlab.com এবং ক্লায়েন্টদের সুবিধার জন্য উভয়ের জন্য আপডেটের দ্রুত ডেলিভারি।

আমাদের জন্য কোন ধারণা বা সুপারিশ?

GitLab-এ অবদান রাখার জন্য সবাইকে স্বাগত জানাই, এবং আমরা আমাদের পাঠকদের কাছ থেকে প্রতিক্রিয়া স্বাগত জানাই। আমাদের ডেলিভারি টিমের জন্য যদি আপনার কোন ধারনা থাকে তবে দ্বিধা করবেন না একটি অ্যাপ্লিকেশন তৈরি করুন নোটিশ সহ team: Delivery.

উত্স: www.habr.com