ফিচার ফ্রিজ এবং কোড ফ্রিজ অ্যাপ ডেভেলপমেন্টে: সারমর্ম, পার্থক্য এবং ভূমিকা

ফিচার ফ্রিজ কী?

Feature freeze পরিকল্পিত রিলিজের আগে কোডবেসে নতুন কার্যকারিতা যোগ করার উপর একটি অস্থায়ী নিষেধাজ্ঞা। টিম ফিচার মার্জ করা বন্ধ করে এবং বাগ ফিক্স, অপ্টিমাইজেশন এবং বিদ্যমান কোড পলিশিংয়ে স্যুইচ করে। ডেভেলপাররা অসম্পূর্ণ ফিচার শুধুমাত্র বাগফিক্সের সুযোগের মধ্যে সম্পূর্ণ করে, সুযোগ প্রসারিত না করে।

ফিচার ফ্রিজ কাজ-প্রগতির (work-in-progress) ফিচারের সমস্যা সমাধান করে যা রিলিজে পৌঁছায় না কিন্তু ইতিমধ্যে মূল ব্রাঞ্চে আংশিকভাবে মার্জ হয়ে গেছে। যদি নতুন ফিচার মার্জ হতে থাকে, রিগ্রেশনের ঝুঁকি বেড়ে যায়: প্রতিটি নতুন ইন্টিগ্রেশনের জন্য ইতিমধ্যে সম্পন্ন মডিউল পুনরায় পরীক্ষা প্রয়োজন। Feature freeze রিলিজের সুযোগ ফিক্স করে, এটিকে একটি চলমান লক্ষ্য থেকে কার্যকারিতার একটি স্থিতিশীল সেটে রূপান্তরিত করে।

একটি গুরুত্বপূর্ণ স্পষ্টীকরণ: feature freeze ≠ code freeze। ফিচার ফ্রিজের সময়, বাগ ফিক্স, রিফ্যাক্টরিং, ডিপেন্ডেন্সি আপডেট এবং ডকুমেন্টেশন অনুমোদিত। শুধুমাত্র নতুন user-facing ফিচার নিষিদ্ধ — যে কোন কোড যা ব্যবহারকারীর দৃষ্টিকোণ থেকে অ্যাপ্লিকেশনের আচরণ পরিবর্তন করে। কোড রিভিউ চেক: যদি PR একটি নতুন স্ক্রিন, বাটন বা API পদ্ধতি যোগ করে — ফ্রিজ তুলে নেওয়া পর্যন্ত এটি প্রত্যাখ্যান করা হয়।

কোড ফ্রিজ কী এবং এটি ফিচার ফ্রিজ থেকে কীভাবে আলাদা

Code freeze একটি কঠোর অনুশীলন যেখানে কোডের সমস্ত পরিবর্তন সম্পূর্ণরূপে নিষিদ্ধ। এমনকি বাগ ফিক্সও অনুমোদিত নয় যদি না সেগুলি গুরুতর হয়। কোড ফ্রিজ একটি সংক্ষিপ্ত সময়ের জন্য (সাধারণত 24-48 ঘন্টা) চালু করা হয় এবং গ্যারান্টি দেয় যে রিলিজ বিল্ড কমিটের একটি নির্দিষ্ট সেট থেকে তৈরি করা হয়েছে।

ফিচার ফ্রিজ এবং কোড ফ্রিজের মধ্যে পার্থক্য নিয়ন্ত্রণের স্তরে। ফিচার ফ্রিজ সুযোগ পরিচালনা করে: রিলিজে ঠিক কী অন্তর্ভুক্ত হবে। কোড ফ্রিজ গুণমান পরিচালনা করে: রিলিজের একদিন আগে একটি নতুন বাগ প্রবর্তনের ঝুঁকি দূর করে। বাস্তবে, অনেক টিম দ্বি-স্তরের মডেল ব্যবহার করে: রিলিজের 1-2 সপ্তাহ আগে — ফিচার ফ্রিজ, 24-48 ঘন্টা আগে — কোড ফ্রিজ। Code freeze বিশেষ করে মোবাইল অ্যাপ্লিকেশনের জন্য প্রাসঙ্গিক, যেখানে পরিকল্পিত রিলিজ তারিখের কয়েক দিন আগে বিল্ড স্টোরে আপলোড করতে হয়।

কোড ফ্রিজের ব্যতিক্রম হল গুরুতর দুর্বলতার জন্য নিরাপত্তা ফিক্স (CVE স্কোর 9+)। এই ধরনের পরিবর্তনগুলি বাধ্যতামূলক ফাস্ট-ট্র্যাক কোড রিভিউ এবং টিম নোটিফিকেশন সহ জরুরি প্রক্রিয়ার মাধ্যমে যায়। অন্যান্য সমস্ত পরিবর্তন পরবর্তী রিলিজ চক্র পর্যন্ত স্থগিত করা হয়।

Feature freeze বনাম code freeze: তুলনা

ফিচার ফ্রিজ এবং কোড ফ্রিজের মধ্যে নির্বাচন টিমের পরিপক্কতা এবং রিলিজ ফ্রিকোয়েন্সির উপর নির্ভর করে। CI/CD এবং ফিচার ফ্ল্যাগযুক্ত টিমগুলির শুধুমাত্র 24 ঘন্টার কোড ফ্রিজ প্রয়োজন হতে পারে, যেখানে মাসিক রিলিজযুক্ত টিমগুলি প্রায়শই উভয় ফ্রিজ ক্রমিকভাবে ব্যবহার করে।

ফ্রিজের প্রকার: সম্পূর্ণ, আংশিক এবং BAU-ফ্রিজ

সম্পূর্ণ ফিচার ফ্রিজ এবং কোড ফ্রিজ ছাড়াও, আরও নমনীয় বিকল্প রয়েছে। আংশিক ফিচার ফ্রিজ শুধুমাত্র নির্দিষ্ট মডিউলে নতুন কার্যকারিতা ব্লক করে — উদাহরণস্বরূপ, পেমেন্ট মডিউল বা অনুমোদন মডিউলে, অন্যান্য উপাদান পরিবর্তনের জন্য উন্মুক্ত রেখে।

BAU-ফ্রিজ (business as usual freeze) একটি আপস বিকল্প যেখানে শুধুমাত্র বড় ফিচার যার পরিবর্তনের আকার একটি নির্দিষ্ট সীমা (যেমন, 500 কোড লাইন) অতিক্রম করে, নিষিদ্ধ। ছোট উন্নতি, UI টুইক এবং বাগ ফিক্স মার্জ হতে থাকে। BAU-ফ্রিজ একটানা ডেলিভারি সহ প্রকল্পগুলির জন্য সুবিধাজনক, যেখানে এক সপ্তাহের সম্পূর্ণ বিকাশ বন্ধ অর্থনৈতিকভাবে লাভজনক নয়।

ডিপ্লয়মেন্ট ফ্রিজ (deployment freeze) ধারণাও রয়েছে — প্রোডাকশনে ডিপ্লয়মেন্টের সম্পূর্ণ বন্ধ, যা ছুটির মরসুমের (ক্রিসমাস ছুটি, ব্ল্যাক ফ্রাইডে) বৈশিষ্ট্য। এই সময়ের মধ্যে, হটফিক্সও ব্লক করা হয় যদি না সেগুলি নিরাপত্তা সম্পর্কিত হয়। ডিপ্লয়মেন্ট ফ্রিজ সাধারণত 1-2 সপ্তাহ স্থায়ী হয় এবং কোম্পানি স্তরে সমন্বিত হয়।

কখন ফ্রিজ চালু করবেন এবং এটি কতক্ষণ স্থায়ী হয়

ফিচার ফ্রিজ চালু করার সর্বোত্তম সময় কোড সম্পূর্ণ হওয়ার পরে, যখন সমস্ত পরিকল্পিত ফিচার মার্জ হয়েছে এবং QA এর মধ্য দিয়ে যাচ্ছে। সঠিক সময় রিলিজ চক্রের উপর নির্ভর করে: দুই-সপ্তাহের স্প্রিন্টের জন্য, ফিচার ফ্রিজ রিলিজ তারিখের 3-4 দিন আগে চালু করা হয়; মাসিক রিলিজের জন্য, 7-10 দিন আগে। Code freeze পরিকল্পিত রিলিজ বিল্ড সময়ের 24-48 ঘন্টা আগে চালু করা হয়।

ফ্রিজের সময়কাল কোড স্থিতিশীল করার জন্য ন্যূনতম যথেষ্ট হওয়া উচিত। খুব দীর্ঘ ফ্রিজ (2 সপ্তাহের বেশি) টিমকে নিরুৎসাহিত করে এবং অমার্জিত ফিচারের সঞ্চয় তৈরি করে, যার প্রতিটি ফ্রিজ তোলার পরে দ্বন্দ্বের ঝুঁকি বাড়ায়। খুব ছোট ফ্রিজ (ফিচার ফ্রিজের জন্য 24 ঘন্টার কম) সম্পূর্ণ পরীক্ষা এবং ফিক্সের জন্য পর্যাপ্ত সময় দেয় না।

প্রস্তাবিত অনুশীলন হল ক্যালেন্ডারের তারিখের পরিবর্তে কোডবেস অবস্থা দ্বারা ফ্রিজ নির্ধারণ করা। ফিচার ফ্রিজ চালু করা হয় যখন রিলিজের জন্য খোলা বাগের সংখ্যা একটি সীমা (যেমন, 10 গুরুতর বাগ) অতিক্রম করে। কোড ফ্রিজ — যখন বিল্ড সফলভাবে স্মোক টেস্ট এবং রিগ্রেশন স্যুট পাস করে। সময়-ভিত্তিক ফ্রিজ (নির্দিষ্ট তারিখ) নিয়ন্ত্রিত শিল্পের (ফিনটেক, মেডটেক) জন্য মানদণ্ড থাকে যেখানে রিলিজ তারিখ নিয়ন্ত্রক দ্বারা অনুমোদিত।

CI/CD এবং Git এর মাধ্যমে ফ্রিজের অটোমেশন

ম্যানুয়াল ফ্রিজ নিয়ন্ত্রণ ত্রুটির উৎস: একজন ডেভেলপার ভুলবশত সেই PR মার্জ করতে পারে যাকে ফ্রিজ তোলা পর্যন্ত অপেক্ষা করা উচিত। অটোমেশন Git ব্রাঞ্চ প্রোটেকশন নিয়ম এবং CI/CD পাইপলাইনের মাধ্যমে এটি সমাধান করে। Git প্রদানকারীতে (GitHub, GitLab, Bitbucket), নিয়ম কনফিগার করা হয় যা বিশেষ ট্যাগ বা রিলিজ ম্যানেজারের অনুমোদন ছাড়া রিলিজ ব্রাঞ্চে মার্জ ব্লক করে।

CI/CD পাইপলাইন বিল্ড তৈরির আগে ফ্রিজ অবস্থা পরীক্ষা করে। Jenkins, GitLab CI বা GitHub Actions-এ, একটি স্টেপ যোগ করা হয় যা ফ্রিজ শিডিউল সহ একটি কনফিগারেশন ফাইল পড়ে এবং বর্তমান তারিখ ফ্রিজ সময়ের মধ্যে পড়লে বিল্ড প্রত্যাখ্যান করে। একটি বিকল্প হল অ্যাডমিন প্যানেলে একটি ফিচার ফ্ল্যাগ যা প্রোডাকশনে ডিপ্লয়মেন্ট ব্লক করে।

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

উদাহরণ freeze-check.js স্ক্রিপ্ট রিপোজিটরি রুট থেকে ফ্রিজ শিডিউল সহ একটি JSON পড়ে। যদি বর্তমান তারিখ নির্দিষ্ট ব্রাঞ্চের জন্য start_date এবং end_date এর মধ্যে পড়ে, পাইপলাইন ফ্রিজ অবস্থা বার্তার সাথে ব্যর্থ হয়। Git ব্রাঞ্চ প্রোটেকশন একটি দ্বিতীয় বাধা যোগ করে: এমনকি পাইপলাইন চালু না হলেও, নিয়ম অনুমোদন ছাড়া PR মার্জ করার অনুমতি দেবে না।

ফ্রিজ প্রয়োগে সাধারণ ভুল

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

দ্বিতীয় ভুল হল ফ্রিজে খুব বেশি ব্যতিক্রম। প্রতিটি ব্যতিক্রম (“এই PR কোনো ফিচার নয়, এটি প্রযুক্তিগত ঋণ”) ফ্রিজের সীমানা অস্পষ্ট করে। যদি ব্যতিক্রম সাধারণ PR প্রবাহের 20% অতিক্রম করে, ফ্রিজ কাজ করে না। টিম ব্লক বাইপাস করতে ফিচারকে বাগ ফিক্স হিসেবে পুনঃনামকরণ করে।

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

চতুর্থ ভুল ম্যানুয়াল নিয়ন্ত্রণে মানবিক কারণ। একজন ডেভেলপার মার্জের আগে ফ্রিজ অবস্থা পরীক্ষা করতে ভুলতে পারে, একজন রিলিজ ম্যানেজার নোটিফিকেশন মিস করতে পারে। একমাত্র নির্ভরযোগ্য সমাধান হল Git প্রদানকারী বা CI/CD স্তরে স্বয়ংক্রিয় ব্লকিং, মানবিক ত্রুটি দূর করে।