Hotfix Branch: এটি কী, মোবাইল ডেভেলপমেন্টে কীভাবে তৈরি এবং ব্যবহার করবেন

Hotfix Branch কী?

Hotfix Branch হল Git-এ একটি অস্থায়ী ব্রাঞ্চ যা সক্রিয় প্রোডাকশন পরিবেশে জটিল ত্রুটির দ্রুত সমাধানের জন্য তৈরি করা হয়। Feature ব্রাঞ্চের বিপরীতে, যা develop থেকে শাখা হয় এবং কয়েক দিন বা সপ্তাহ ধরে থাকে, hotfix main/master থেকে তৈরি করা হয় এবং বাগ ঠিক করার জন্য যতক্ষণ প্রয়োজন ততক্ষণ বিদ্যমান থাকে।

Hotfix-এর মূল লক্ষ্য হল একটি জটিল ত্রুটি আবিষ্কার এবং প্রোডাকশনে তা ঠিক করার মধ্যে সময় কমানো। টিম বর্তমান স্প্রিন্ট বা রিলিজ চক্র শেষ হওয়ার জন্য অপেক্ষা করে না, বরং তাৎক্ষণিকভাবে প্যাচ প্রকাশ করে। এটি মোবাইল অ্যাপ্লিকেশনের জন্য বিশেষভাবে গুরুত্বপূর্ণ, যেখানে একটি জটিল বাগ ব্যবহারকারীদের ব্লক করতে পারে এবং তাদের চলে যাওয়ার কারণ হতে পারে।

Google Play Console-এর মতে, Google Play-তে আপডেট পর্যালোচনার গড় সময় 2 থেকে 24 ঘন্টা। App Store-এর জন্য, এক্সপ্রেস পর্যালোচনায় 1 থেকে 4 ঘন্টা সময় লাগতে পারে। Hotfix ব্রাঞ্চগুলি পর্যালোচনা সম্পূর্ণ হওয়ার আগেই সমাধান প্রস্তুত করতে এবং অনুমোদনের পরপরই তা প্রকাশ করতে দেয়।

Hotfix কীভাবে কাজ করে

Hotfix প্রক্রিয়া তিনটি ধাপ নিয়ে গঠিত: main থেকে ব্রাঞ্চ তৈরি করা, সমাধান করা, এবং main এবং develop-এ ফিরে মার্জ করা। সাধারণ সমাধান থেকে মূল পার্থক্য হল যে hotfix সর্বদা উভয় ব্রাঞ্চেই মার্জ করা হয়, যাতে পরবর্তী রিলিজে সমাধানটি হারিয়ে না যায়।

টিমের hotfix-এ নতুন কার্যকারিতা বা রিফ্যাক্টরিং অন্তর্ভুক্ত করা উচিত নয়। শুধু লক্ষ্যযুক্ত সমাধান, যা জটিল সমস্যা সমাধানের জন্য ন্যূনতম প্রয়োজনীয়। এই নিয়ম থেকে কোনো বিচ্যুতি রিগ্রেশনের ঝুঁকি বাড়ায় এবং প্যাচ প্রকাশে বিলম্ব ঘটায়।

কখন Hotfix প্রয়োজন

Hotfix তিনটি পরিস্থিতিতে প্রয়োজনীয়: একটি জটিল বাগ ব্যবহারকারীদের ব্লক করে (ক্র্যাশ, ডেটা ক্ষতি), একটি নিরাপত্তা দুর্বলতা তাৎক্ষণিক বন্ধ করার প্রয়োজন, বা জটিল ব্যবসায়িক যুক্তি ভেঙে গেছে (পেমেন্ট, প্রমাণীকরণ)। যদি বাগটি জটিল না হয় — তবে এটি develop-এর মাধ্যমে নিয়মিত রিলিজ চক্রে ঠিক করা যেতে পারে।

মোবাইল অ্যাপ্লিকেশনের জন্য, hotfix-এ সার্ভার-সাইড পরিবর্তনও অন্তর্ভুক্ত থাকতে পারে যদি আর্কিটেকচার রিমোট ফিচার টগলিং (feature flags) অনুমতি দেয়। এই ক্ষেত্রে, hotfix ব্রাঞ্চ ন্যূনতম হতে পারে বা যদি সমাধান সার্ভার সাইডে করা যায় তবে একেবারেই প্রয়োজন নাও হতে পারে।

ব্রাঞ্চিং মডেল এবং Hotfix-এর অবস্থান

সব ব্রাঞ্চিং মডেল hotfix ব্রাঞ্চ সমর্থন করে না। ঐতিহ্যবাহী Git Flow hotfix-কে একটি পূর্ণাঙ্গ ব্রাঞ্চ ধরন হিসেবে অন্তর্ভুক্ত করে, যেখানে আরও আধুনিক পদ্ধতি (GitHub Flow, Trunk-based) জরুরি সমাধানগুলি ভিন্নভাবে পরিচালনা করে।

Git Flow এবং Hotfix

Git Flow হল একমাত্র মডেল যেখানে hotfix feature এবং release-এর মতো একটি অন্তর্নির্মিত ব্রাঞ্চ ধরন। Git Flow-তে, hotfix main থেকে তৈরি করা হয় এবং সম্পূর্ণ হওয়ার পরে main (সংস্করণ ট্যাগ সহ) এবং develop উভয়েই মার্জ করা হয়। এটি নিশ্চিত করে যে পরবর্তী রিলিজে সমাধানটি হারিয়ে না যায়।

GitHub Flow এবং Trunk-based

GitHub Flow hotfix-এর জন্য আলাদা ব্রাঞ্চ ধরন ব্যবহার করে না। পরিবর্তে, ডেভেলপার main থেকে একটি সাধারণ feature ব্রাঞ্চ তৈরি করে, সমাধান করে এবং একটি Pull Request খোলে। পর্যালোচনা এবং CI পরীক্ষার পরে, ব্রাঞ্চটি main-এ মার্জ হয় এবং তাৎক্ষণিকভাবে ডিপ্লয় হয়। সুবিধা হল সরলতা; অসুবিধা হল জরুরি সমাধানের জন্য একটি উত্সর্গীকৃত চ্যানেলের অভাব।

Trunk-based ডেভেলপমেন্ট hotfix-কে (জটিল ক্ষেত্রে) সরাসরি main-এ কমিটের মাধ্যমে পরিচালনা করে, বাধ্যতামূলক পোস্ট-ফ্যাক্টাম পর্যালোচনা সহ। এই পদ্ধতির জন্য উচ্চ টিম শৃঙ্খলা এবং নির্ভরযোগ্য স্বয়ংক্রিয় পরীক্ষার প্রয়োজন, কারণ পরিবর্তনগুলি তাৎক্ষণিকভাবে প্রোডাকশনে চলে যায়।

কীভাবে Hotfix Branch তৈরি করবেন

Hotfix তৈরি করা শুরু হয় প্রধান ব্রাঞ্চে সুইচ করে এবং hotfix/ উপসর্গ সহ একটি নতুন ব্রাঞ্চ তৈরি করে। একটি মোবাইল অ্যাপ্লিকেশনে জটিল বাগ ঠিক করার উদাহরণ সহ ধাপে ধাপে প্রক্রিয়াটি দেখি।

main থেকে ব্রাঞ্চ তৈরি করা

প্রথম ধাপ — main-এ সুইচ করুন এবং নিশ্চিত করুন যে ব্রাঞ্চটি আপডেটেড। তারপর একটি স্পষ্ট নাম সহ hotfix ব্রাঞ্চ তৈরি করুন যা সমাধানের প্রকৃতি প্রতিফলিত করে।

# main-এ সুইচ করুন এবং সর্বশেষ পরিবর্তন পান
git checkout main
git pull origin main

# একটি hotfix ব্রাঞ্চ তৈরি করুন
git checkout -b hotfix/crash-on-login

ব্রাঞ্চ তৈরি করার পরে, আপনি সমাধান করতে পারেন। মনে রাখা গুরুত্বপূর্ণ: hotfix-এ ন্যূনতম সংখ্যক পরিবর্তন থাকা উচিত। কোড রিফ্যাক্টর করবেন না বা নতুন বৈশিষ্ট্য যোগ করবেন না — শুধু লক্ষ্যযুক্ত সমাধান যা সমস্যা সমাধান করে।

সমাধান কমিট করা

Hotfix-এ কমিট-এ একটি তথ্যপূর্ণ বার্তা থাকা উচিত যা স্পষ্টভাবে সমস্যা এবং এর সমাধান বর্ণনা করে। বিন্যাস: ধরণ(এলাকা): সংক্ষিপ্ত বিবরণ + tracker-এ কাজের লিঙ্ক।

# পরিবর্তিত ফাইল যোগ করুন
git add src/ui/login/LoginActivity.kt

# বিবরণ সহ একটি কমিট তৈরি করুন
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

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

main এবং develop-এ মার্জ করা

চূড়ান্ত ধাপ — hotfix-কে main (নতুন প্যাচ সংস্করণ ট্যাগ সহ) এবং develop-এ ফিরে মার্জ করা (যাতে সমাধান পরবর্তী রিলিজে সংরক্ষিত থাকে)। প্রথমে main-এ ট্যাগ সহ মার্জ করুন, তারপর develop-এ মার্জ করুন।

# main-এ মার্জ করুন এবং একটি ট্যাগ তৈরি করুন
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# develop-এ মার্জ করুন
git checkout develop
git merge --no-ff hotfix/crash-on-login

# সার্ভারে পরিবর্তন পাঠান
git push origin main --tags
git push origin develop

--no-ff ফ্ল্যাগ নিশ্চিত করে যে একটি মার্জ কমিট তৈরি হয়, এমনকি যদি hotfix fast-forward-এর মাধ্যমে প্রয়োগ করা যেত। এটি তথ্য সংরক্ষণ করে যে একটি জরুরি সমাধান করা হয়েছিল এবং ভবিষ্যতে ইতিহাস বিশ্লেষণ সহজ করে।

Hotfix, Feature এবং Release ব্রাঞ্চের মধ্যে পার্থক্য

Hotfix উদ্দেশ্য, জীবনকাল এবং মার্জ নিয়মের দিক থেকে feature এবং release ব্রাঞ্চ থেকে মৌলিকভাবে আলাদা। এই পার্থক্যগুলি বোঝা টিমে Git প্রক্রিয়াগুলি সঠিকভাবে সংগঠিত করার জন্য গুরুত্বপূর্ণ।

Feature ব্রাঞ্চ নতুন কার্যকারিতা-র জন্য। এটি কয়েক দিন থেকে কয়েক সপ্তাহ পর্যন্ত স্থায়ী হয়, develop থেকে তৈরি হয় এবং develop-এ ফিরে মার্জ হয়। Feature-এ একাধিক কমিট থাকতে পারে, যার মধ্যে পরীক্ষামূলকও রয়েছে, যা পরে squash বা rebase-এর মাধ্যমে সংকুচিত করা হয়।

Release ব্রাঞ্চ রিলিজকে ডিপ্লয়মেন্টের জন্য প্রস্তুত করে। এটি develop থেকে তৈরি হয়, এতে স্থিতিশীলকরণের সময় পাওয়া বাগগুলি ঠিক করা হয় এবং এটি নতুন কার্যকারিতা গ্রহণ করে না। সম্পূর্ণ হওয়ার পরে, release main (ট্যাগ সহ) এবং develop-এ মার্জ হয়।

Hotfix অন্যদিকে, সরাসরি main-এর সাথে তৈরি এবং মার্জ হয়, develop-কে বাইপাস করে (যদিও সমাধানের পরে develop-এর সাথেও সিঙ্ক্রোনাইজ করা হয়)। এতে ন্যূনতম পরিবর্তন থাকে এবং ন্যূনতম সময়ের জন্য বিদ্যমান থাকে। যেখানে feature বা release ব্রাঞ্চ পরবর্তী চক্র পর্যন্ত স্থগিত করা যেতে পারে, hotfix স্থগিত করা যায় না।

মোবাইল ডেভেলপমেন্টের জন্য, এই পার্থক্য বিশেষভাবে গুরুত্বপূর্ণ: App Store এবং Google Play প্রধান রিলিজ থেকে আলাদাভাবে প্যাচ সংস্করণ প্রকাশের অনুমতি দেয়। Hotfix ব্রাঞ্চ নিশ্চিত করে যে একটি প্যাচ রিলিজ অসম্পূর্ণ বৈশিষ্ট্যের সাথে মিশ্রিত না হয়।

Hotfix নিয়ে কাজ করার সময় সাধারণ ভুল

Hotfix নিয়ে কাজ করার সময় ভুলগুলি জরুরি সমাধানের সুবিধাগুলি বাতিল করতে পারে। Git Flow ব্যবহার করে এমন টিমে দেখা পাঁচটি সবচেয়ে সাধারণ সমস্যা দেখি।

• develop থেকে hotfix তৈরি করা — যদি hotfix develop থেকে তৈরি করা হয়, তাহলে অসম্পূর্ণ বৈশিষ্ট্য প্যাচে আসতে পারে। Hotfix শুধু main থেকে তৈরি করা উচিত যাতে নিশ্চিত করা যায় যে সমাধানে শুধু স্থিতিশীল কোড অন্তর্ভুক্ত রয়েছে।
• একটি hotfix-এ একাধিক সমাধান — প্রতিটি সমাধান তার নিজস্ব hotfix ব্রাঞ্চে হওয়া উচিত। একটি ব্রাঞ্চে একাধিক বাগ মেশানো কোড পর্যালোচনা জটিল করে, রিগ্রেশনের ঝুঁকি বাড়ায় এবং প্রয়োজন হলে রোলব্যাক কঠিন করে।
• develop-এ মার্জ এড়িয়ে যাওয়া — যদি hotfix develop-এ মার্জ না করা হয়, তাহলে সমাধান পরবর্তী রিলিজে হারিয়ে যাবে। টিম দেখতে পাবে যে একই বাগ আবার দেখা দিয়েছে এবং এটি আবার ঠিক করতে বাধ্য হবে।
• ভুল সংস্করণ ট্যাগ — hotfix-এ প্যাচ বৃদ্ধি পাওয়া উচিত (v2.3.0 → v2.3.1), মাইনর (v2.4.0) বা মেজর (v3.0.0) নয়। সিম্যান্টিক ভার্সনিং লঙ্ঘন বিল্ড সিস্টেম ভেঙে দেয় এবং ব্যবহারকারীদের বিভ্রান্ত করে।
• CI পরীক্ষার অভাব — এমনকি জরুরি hotfix-ও স্বয়ংক্রিয় পরীক্ষা পাস করা উচিত। CI এড়িয়ে যাওয়া নতুন ত্রুটি প্রবর্তনের ঝুঁকি বাড়ায়। ত্বরিত পরীক্ষা সহ hotfix ব্রাঞ্চের জন্য আলাদা pipeline রাখার সুপারিশ করা হয়।

এই প্রতিটি ভুল প্যাচ রিলিজে বিলম্ব বা প্রোডাকশনে নতুন সমস্যা সৃষ্টি করে। টিমগুলির CONTRIBUTING.md-এ hotfix নিয়ে কাজ করার নিয়মগুলি নথিভুক্ত করা এবং CI/CD পরীক্ষার মাধ্যমে সেগুলি স্বয়ংক্রিয় করা উচিত।