অনুমোদন / অনুমোদিত হওয়া: এটি কি, Git-এ অনুমোদন এবং code review

pull request অনুমোদন কি

অনুমোদন হল pull request-এর একটি ইয়াত্মক পর্যালোচনা, যার অর্থ রিভিউয়ার কোড পরীক্ষা করেছেন, কোনও গুরুতর সমস্যা পাউননি, এবং পরিবর্তনগুলিকে merge-এর জন্য প্রস্তুত মনে করেন। GitHub ইন্টারফেসে, এটি PR পাতায় সবুজ «Approve» বতন। অনুমোদনের পর, লেখক (বা লেখার অনুমতিপ্রাপ্ত যে কোনো সদস্য) merge করতে পারেন।

অনুমোদন প্রক্রিয়া Branch Protection Rulesএর অংশ। রিপোজিটরির মালিকরা বাধ্যতামূলক আবশ্যকতা কনফিগার করেন: সর্বনিম্ন অনুমোদন সংখ্যা (যেমন, 1 বা 2), কে অনুমোদন করতে পারে (কোড মালিক, দল সদস্য), এবং পরিবর্তনের পর PR পুনরায় অনুমোদিত করা প্রয়োজন কি না (Dismiss stale reviews)। নিয়ম কনফিগারেশন ছাড়া, অনুমোদন ঐচ্ছিক, তবে পেশাদার দলে এটি বাধ্যতামূলক।

GitLab একটি অনুরূপ প্রক্রিয়া ব্যবহার করে যাকে Approval Rules বলা হয়। GitLab-এ, আপনি কনফিগার করতে পারেন যে বিভিন্ন গ্রুপ থেকে কতটি অনুমোদন প্রয়োজন (যেমন, ব্যাকএন্ড ডিভেলপারদের থেকে 2 এবং DevOps থেকে 1)। সকল বাধ্যতামূলক অনুমোদন পাওয়ার পর, CI/CD পাইপলাইন সবুজ হলে PR merge-এর জন্য স্বচালিতভাবে আনলক হয়।

রিভিউর ধরন: Approve, Request Changes, Comment

GitHub এবং GitLab-এ তিন ধরনের রিভিউ আছে যা একজন রিভিউয়ার pull request-এ রাখতে পারেন। প্রতিটি ধরনের ভিন্ন স্থিতি এবং merge প্রক্রিয়ার জন্য ভিন্ন পরিণাম রয়েছে। Approve সবুজ, Request Changes লাল, Comment নিরপেক্ষ ধূসর। পঞ্চা নির্ভর করে কোডের গুণমান এবং গ্রহণের জন্য পরিবর্তনের প্রস্তুতির সাথে।

Approve — রিভিউয়ার নিশ্চিত করেন: কোড ঠিকভাবে লেখা হয়়েছে, মানক পূরণ করে, কোনও স্পষ্ট ত্রুটি নেই, এবং merge করা যেতে পারে। Approve এর অর্থ কোড নির্দোষ নয় — শুদ্ধমাত্র এটি উৎপাদনের জন্য যথেষ্ট ভালো। যদি ছোট মন্যতা থাকে (শৈলী, নামকরণ), সেগুলি PR অবরোধ করা ছাড়া মন্যতা হিসাবে রাখা যেতে পারে।

Request Changes — রিভিউয়ার সমস্যা খুঁজে পান যা merge-এর আগে সমাধান করা প্রয়োজন: যুক্তিগত ত্রুটি, দুর্বলতা, আর্কিটেক্চার লঙ্ঘন, পরীক্ষার অভাব। Request Changes-এর পর, PR অবরুদ্ধ হয়, এবং আনলকের জন্য একই রিভিউয়ারের কাছ থেকে পুনরায় অনুমোদন প্রয়োজন (যদি নতুন কমিটে Dismiss stale reviews বিকল্প সক্রিয় থাকে)।

• Approve — কোড merge-এর জন্য প্রস্তুত, CI পার করার পর merge করা যেতে পারে।
• Request Changes — বাধ্যতামূলক সংশোধন, পুনর্বিচারের আগে PR অবরুদ্ধ।
• Comment — PR অবরোধ ছাড়া সাধারণ মন্যতা বা পরামর্শ।

রিপোজিটরিতে অনুমোদন নিয়ম কনফিগার করা

Branch Protection Rules হল merge গুণমান নিয়ন্ত্রণের জন্য GitHub-এর প্রক্রিয়া। প্রতিটি সংরক্ষিত ব্রান্চের (main, develop, release/*) জন্য Settings → Branches-এ কনফিগার করা হয়। প্রধান প্যারামিটার: বাধ্যতামূলক অনুমোদনের সংখ্যা, কোড মালিক (CODEOWNERS), বাধ্যতামূলক CI/CD যাচাই, এবং PR ছাড়া push নিষেধ।

Dismiss stale pull request approvals প্যারামিটার স্বচালিতভাবে অনুমোদন সরিয়ে দেয় যদি PR-এ একটি নতুন কমিট যোগ করা হয়। এটি নিশ্চিত করে যে রিভিউয়াররা কোডের সেই সংস্করণকে অনুমোদন করেন যা merge করা হবে। এই সেটিং ছাড়া, লেখক অনুমোদনের পর নতুন কোড যোগ করতে পারেন এবং এটি অতিরিক্ত যাচাই ছাড়াই main-এ পৌঁছে যাবে।

CODEOWNERS — রিপোজিটরির মূলে একটি ফাইল যা বিভিন্ন ডিরেক্টরির জন্য দায়িত্বপ্রাপ্তদের নির্দিষ্ট করে। যদি PR কোড মালিকের ফাইলগুলিকে প্রভাবিত করে, তাহলে তার অনুমোদন বাধ্যতামূলক হয়ে যায়। CODEOWNERS দায়িত্বের ক্ষেত্র বন্টি করার অনুমতি দেয়: iOS ডিভেলপাররা Swift ফাইলের জন্য দায়ী, DevOps Docker কনফিগের জন্য, পরীক্ষকরা পরীক্ষণ পরিদৃশ্যের জন্য।

# রিপোজিটরি মূলে উদাহরণ CODEOWNERS ফাইল

# iOS ডিভেলপাররা Swift কোডের মালিক
*.swift @team/ios-developers

# DevOps CI/CD কনফিগারেশনের মালিক
.github/workflows/* @devops-team

# QA ইঞ্জিনিয়াররা পরীক্ষা পর্যালোচনা করেন
**/tests/* @qa-engineers

# অন্য সবকিছুর জন্য ডিফল্ট মালিক
* @tech-leads

অনুমোদনের আগে code review: কি চেক করবেন

Code review অনুমোদনের আগে একটি সুশৃঙ্খল কোড পরীক্ষা, diff-এর উপর এক দ্রুত নজ়র নয়। একটি মানসম্মত code review-এ আর্কিটেক্চার, যুক্তি, শৈলী, পরীক্ষা এবং নিরাপত্তা যাচাই অন্তর্ভুক্ত। এই যাচাই ছাড়া, অনুমোদন একটি গুণমান নিয়ন্ত্রণ সরঞ্জামের পরিবর্তে একটি প্রক্রিয়াগত আনুষ্ঠানিকতায় পরিণত হয়।

সবচেয়ে প্রথমে কি পরীক্ষা করা হয়: পরিবর্তনের যুক্তি — কোড কি কাজ সমাধান করে, কোনও পার্শ্ব প্রভাব আছে কি, সীমান্ত ক্ষেত্রের সাথে ব্যবহার কি সঠিক। পরীক্ষা — নতুন পরীক্ষাগুলি কি সকল পরিদৃশ্য আবরণ করে, পরিবর্তনের পর বর্তমান পরীক্ষাগুলি কি পাস করে। নিরাপত্তা — কোনও SQL ইঞ্জেকশন, XSS, সংবেদনশীল ডেটা ফাঁস নেই তো।

কি পর্যালোচনার বিষয় হওয়া উচিত নয়: ফর্মেটিং শৈলী (এর জন্য linters এবং formatters আছে), আগে থেকে নেওয়া আর্কিটেক্চার সিদ্ধান্ত (সেগুলি কোড লেখার আগে আলোচিত হয়)। যদি একটি পর্যালোচনা 400 লাইনের বেশি হয় অথবা এক ঘন্টার বেশি সময় নেয়, এটি একটি সংস্কার যে কাজটি বহুত বড় এবং বিখণ্ডিত করা প্রয়োজন। সর্বোৎত্তম পর্যালোচনা অভ্যাস — PR তৈরির 24 ঘন্টার মধ্যে 200–400 লাইনের অংশ।

• যুক্তি — সমাধানের শুদ্ধতা, ত্রুটি হ্যান্ডলিং, সীমান্ত ক্ষেত্র।
• পরীক্ষা — নতুন পরিদৃশ্যের আবরণ, বর্তমান পরীক্ষা পাস, কোনও flaky পরীক্ষা নেই।
• নিরাপত্তা — কোনও ইঞ্জেকশন নেই, আউটপুট এসকেপিং, ডেটা অ্যাক্সেস নিয়ন্ত্রণ।
• কর্মদক্ষতা — আলগোরিদমের দক্ষতা, অতিরিক্ত ক্যোরি, মেমরি ফাঁস।
• ডকুমেন্টেশন — ডকুমেন্টেশন হালনাগাদ কি, জটিল অংশে মন্যতা পরিষ্কার কি।

দলে অনুমোদন সহ কাজের ধারা

5–10 জন ডিভেলপারের একটি দলে অনুমোদন সহ একটি সাধারণ কর্মপ্রবাহ এইরকম: একজন ডিভেলপার PR তৈরি করেন, রিভিউয়ার নির্দিষ্ট করেন (সাধারণত দল থেকে 1–2 জন বা কোড মালিক), CI/CD স্বচালিত পরীক্ষা চালায়। সকল বাধ্যতামূলক অনুমোদন এবং সবুজ CI পাওয়ার পর, লেখক merge করেন। PR তৈরি থেকে merge পর্যন্ত সময় জটিলতার উপর নির্ভর করে গড় 2 ঘন্টা থেকে 2 দিন পর্যন্ত হয়।

GitHub Actions অনুমোদনের পর merge স্বচালিত করার অনুমতি দেয়। যদি ব্রান্চ নিয়ম কনফিগার করা হয়, তাহলে GitHub সব সর্তক পূরণ না হোর পর্যন্ত merge অবরুদ্ধ করে। কিছু দল bors-ng বা Mergify ব্যবহার করে — বোট যারা সকল অনুমোদন পাওয়ার এবং CI পার করার পর স্বচালিতভাবে PR merge করে। এটি প্রক্রিয়া তবরান্বিত করে এবং merge-এ মানবীয় কারক নিরাকরণ করে।

একটি আধুনিক পদ্ধতি হল trunk-based development স্বল্পজীবী শাখা সহ। এই কর্মপ্রবাহে, কয়েক ঘন্টার মধ্যে অনুমোদন পেতে হবে, অন্যথা কাজটি অপ্রচারিত মনে করা হয় এবং main-এর সাথে পুনরায় সিঙ্ক করা প্রয়োজন। উচ্চ পর্যালোচনা সংস্কৃতির দলগুলি 4 কার্য ঘন্টার বেশি নয়ের মধ্যে অনুমোদন সময়ের লক্ষ্য রাখে।

অনুমোদনে ভুল এবং কিভাবে এড়াবেন

সবচেয়ে সাধারণ ভুল হল বাস্তবিক কোড পরীক্ষা ছাড়া আনুষ্ঠানিক অনুমোদন। যখন PR বড় বা সময়সীমা ঘনিষ্ট, তখন রিভিউয়ার পরিবর্তনগুলি পরীক্ষা না করেই Approve টিপতে পারেন। এটি সম্পূর্ণ code review প্রক্রিয়াকে অবমূল্য করে। সমাধান: PR আকারের একটি সীমা নির্ধারণ করুন (400 লাইনের বেশি নয়) এবং স্বচালিত পরীক্ষার জন্য কোড বিশ্লেষণ সরঞ্জাম (SonarQube, CodeClimate) ব্যবহার করুন।

দ্বিতীয় ভুল হল অত্যন্ত কড়া অনুমোদন। নির্দোষ কোডের আশা উন্নয়নকে অবরুদ্ধ করে। রিভিউয়াররা কক্ষনো শৈলীগত মন্যতা সমাধানের দাবি করেন যা গুণমানকে প্রভাবিত করে না। সমাধান: বাধ্যতামূলক (blocking) এবং ঐচ্ছিক (মন্যতা) মধ্যে স্পষ্ট পার্থক্য করুন। GitHub আপনাকে স্পষ্টভাবে উল্লেখ করার অনুমতি দেয় যে একটি মন্যতা অবরোধকারী কি না।

তৃতীয় ভুল হল CI/CD যাচাই ছাড়া অনুমোদন। কোড ঠিক মনে হলেও, হোচ্ছে যে এটি কম্পাইল না-ও করতে পারে বা পরীক্ষায় বিফল হতে পারে। কনফিগার করা Branch Protection লাল CI-এ merge স্বচালিতভাবে অবরুদ্ধ করে, তবে কিছু দল দ্রুততার জন্য এই সুরক্ষা নিষ্ক্রিয় করে। সমাধান: অনুমোদনের আগে সবসময় CI স্থিতি পরীক্ষা করুন এবং লাল পাইপলাইন সহ PR কখনও অনুমোদন করবেন না।

• আনুষ্ঠানিক অনুমোদন — বাস্তবিক কোড পরীক্ষার অভাব। সমাধান: প্রতি PR 400 লাইনের সীমা।
• অত্যন্ত কড়ামি — শৈলীগত মন্যতার কারণে অবরোধ। সমাধান: blocking এবং optional-এ ভাগ করুন।
• CI উপেক্ষা — লাল পাইপলাইনে অনুমোদন। সমাধান: সবসময় পরীক্ষা স্থিতি পরীক্ষা করুন।
• লেখক নির্দিষ্টকরণ — PR লেখকের অনুমোদন। সমাধান: লেখকের বিরুদ্ধে Branch Protection কনফিগার করুন।