সাপ্তাহিক শিপিংয়ের জন্য ট্রাঙ্ক-ভিত্তিক উন্নয়ন বনাম GitFlow

সাপ্তাহিক শিপিং কেন ভুল ব্রাঞ্চিং মডেলে কখনো বিশৃঙ্খল হয়

সাপ্তাহিক শিপিং সহজ শোনায়—যতক্ষণ না আপনি সেটা মিস করেন। বৃহস্পতিবার বিল্ড "প্রায় প্রস্তুত", QA শুক্রবার দেরি করে সমস্যা খুঁজে পায়, এবং সোমবার পরিষ্কার শুরু না হয়ে ক্লিনআপে কেটে যায়।

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

যখন ওয়ার্কফ্লো আপনার বিরুদ্ধে কাজ করে, সাধারণত এরকম লাগে:

• মার্জগুলোর সময়টি ওই ফিচার কাজের চেয়ে বেশি লাগে।
• QA ভুল মিশ্রিত পরিবর্তনগুলো টেস্ট করে কারণ ব্রাঞ্চগুলো বিচ্ছিন্ন হয়ে পড়ে।
• রিলিজগুলো রুটিন নয়—এগুলো আলোচনার বিষয় হয়ে যায়।
• হটফিক্সগুলো প্যানিক ট্রিগার করে কারণ কেউ নিশ্চিত নয় আর কী শিপ হবে।
• লোকেরা QA-র উপর থেকে বিশ্বাস হারাতে শুরু করে এবং ব্যতিক্রম চাইতে শুরু করে।

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

এ কারণেই টিমগুলো সাপ্তাহিক রিলিজ রিদমে যাওয়ার সময় ট্রাঙ্ক-ভিত্তিক উন্নয়ন এবং GitFlow তুলনা করে। সরাসরি দরকারি প্রশ্নটি কোনটা জনপ্রিয় সেটা নয়—এটি কোনটা মার্জ ব্যথা কমায়, রিলিজগুলোকে পূর্বানুমেয় রাখে, হটফিক্সকে নিরাপদ ও দ্রুত করে, এবং QA-কে অর্থবহ রাখে।

ধরা যাক একটি ছোট থেকে মাঝারি আকারের টিম, একটি শেয়ারড রিপো, প্রতি পুশে CI চলছে। হতে পারে আপনি একটি ওয়েব অ্যাপ এবং একটি API শিপ করেন। অথবা টিমের কিছু অংশ ভিজ্যুয়ালি AppMaster-এ তৈরি করে, তবু উৎপন্ন কোড ও ডিপ্লয়ম্যান্ট অন্য যেকোন প্রোডাক্ট টিমের মতই পরিচালনা করে।

আপনার বর্তমান প্রসেস যদি সপ্তাহ শেষে বড় মার্জ তৈরি করে, আপনার সাপ্তাহিক কেডেন্স পিছিয়ে যেতে থাকবে। যদি এটি ছোট, ঘন ঘন ইন্টিগ্রেশন উৎসাহিত করে, সাপ্তাহিক রিলিজ বোoring (ভালভাবে) লাগে।

ট্রাঙ্ক-ভিত্তিক উন্নয়ন এবং GitFlow সহজ ভাষায়

দুই পদ্ধতিই কেবল ব্রাঞ্চ কিভাবে ব্যবহার করবেন তার নিয়ম—যাতে কাজ "চলছে" থেকে "রিলিজ"-এ বিশৃঙ্খলা ছাড়া আসতে পারে। প্রকৃত পার্থক্য হল আপনি কতগুলো দীর্ঘস্থায়ী ব্রাঞ্চ রাখেন, এবং কাজ কতক্ষণ আলাদা থাকে অন্যদের কোডের সাথে মেশার আগে।

• ট্রাঙ্ক-ভিত্তিক প্রায় সবকিছুকে main-এর কাছে রাখে।
• GitFlow চলমান কাজ ও রিলিজ স্থিতিশীলতার জন্য আলাদা লেন রাখে।

ট্রাঙ্ক-ভিত্তিক উন্নয়ন (সরল ভাষায়)

ট্রাঙ্ক-ভিত্তিক উন্নয়ন main (ট্রাঙ্ক) কে কেন্দ্র মনে করে। লোকেরা ছোট-স্থায়ী ব্রাঞ্চে কাজ করে (ঘণ্টা থেকে এক-দুই দিন), ঘনঘন মার্জ করে, এবং main-কে রিলিজযোগ্য অবস্থায় রাখে।

কিছু যদি প্রস্তুত না হয়, আপনি সেটা দ্রুত শেষ করার মতো ছোট রাখবেন, অথবা একটি ফিচার ফ্ল্যাগের পেছনে লুকিয়ে রাখবেন যাতে এটি নিরাপদে শিপ হয় কিন্তু দৃশ্যমান না হয়।

GitFlow (সরল ভাষায়)

GitFlow সাধারণত একটি দীর্ঘস্থায়ী develop ব্রাঞ্চ ব্যবহার করে যেখানে প্রথমে ফিচার কাজ ল্যান্ড করে, এবং develop থেকে ফিচার ব্রাঞ্চ তৈরি করা হয়। রিলিজের সময় কাছে এসে release/* ব্রাঞ্চ কাটা হয় স্থিতিশীল করার জন্য। প্রোডাকশন ভেঙে গেলে main থেকে hotfix/* শাখা কাটা হয় এবং তা ফিরে মার্জ করা হয়।

এই মডেলটি আলাদা রাখার জন্য অপ্টিমাইজ করে: চলমান কাজ develop-এ চলতে পারে যখন রিলিজ ব্রাঞ্চ টেস্ট ও প্যাচ করা হয়।

অনেক কষ্টই সাধারণ ভুল বোঝাবুঝি থেকে আসে:

• ট্রাঙ্ক-ভিত্তিককে "কোনো ব্রাঞ্চ নেই" মনে করা (এটি এখনও ব্রাঞ্চ ব্যবহার করে, সেগুলো শুধু স্বল্প-স্থায়ী)।
• GitFlow ব্যবহার করে কিন্তু কখনোই বাস্তবে একটি রিলিজ ব্রাঞ্চ না তৈরি করা, ফলে develop অস্থির স্টেজিং এরিয়া হয়ে যায়।
• ফিচার ব্রাঞ্চগুলো সপ্তাহের জন্য রেখে দেওয়া, যা যেকোন মডেলকে মার্জ সমস্যায় ফেলে।
• "রিলিজযোগ্য"কে "সবকিছু শেষ" হিসেবে ভুল বোঝা না করে বরং "ডিপ্লয় করার জন্য নিরাপদ" হিসেবে দেখা।

মার্জ ফ্রিকশন: বাস্তবে কী কারণে হয়

মার্জ কনফ্লিক্ট সাধারণত দুটি কারণ থেকে আসে: ব্রাঞ্চগুলো অনেকক্ষণ বাঁচে, এবং একাধিক লোক একই এলাকায় সমন্বয় না করে পরিবর্তন করে।

ট্রাঙ্ক-ভিত্তিক ও GitFlow-এর মধ্যে প্রধান ব্যবহারিক পার্থক্য হলো কাজ কতক্ষণ আলাদা থাকে অন্যদের কাজের সাথে মিলিত হওয়ার আগে।

ট্রাঙ্ক-ভিত্তিক উন্নয়নে পরিবর্তনগুলো প্রধান লাইনে ঘনঘন আসে। পুল রিকোয়েস্ট ছোট, ডিফ ছোট, এবং কনফ্লিক্টগুলো আগেই দেখা যায় যখন প্রসঙ্গ তাজা থাকে। কনফ্লিক্ট থাকে, কিন্তু সাধারণত সহজে সমাধানযোগ্য কারণ আপনি কয়েক লাইন মিলিয়ে নিচ্ছেন, দুই সপ্তাহের ড্রিফট নয়। এই বিনিময় হলো শৃঙ্খলা: বিল্ড সবসময় গ্রীন রাখুন, পরিবর্তন ইনক্রিমেন্টাল রাখুন, এবং main-কে প্রোডাক্ট হিসেবেই বিবেচনা করুন।

GitFlow-এ ফিচার কাজ দীর্ঘক্ষণ বসে থাকতে পারে অন্য ডেভেলপারদের ওপর প্রভাব না ফেলেই। খরচ পরে বড় মার্জ ইভেন্ট হিসেবে দেখা দেয়: ফিচার→develop, develop→release/*, এবং release/*→main। প্রতিটি মার্জ বড় মিশ্রণ, তাই কনফ্লিক্ট সম্ভাবনা বেশি এবং খুলতে কঠিন। সাপ্তাহিক শিপিং-এর জন্য ঐ বড় মার্জগুলো সাধারণত ঠিক তখনই পড়ে যখন টিম টেস্ট করতে চায়।

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

যে কোনো মডেলে মার্জ ফ্রিকশন কমাতে:

• PR ছোট ও সংক্ষিপ্ত রাখুন (একটি লক্ষ্য একবারে)।
• ঝুঁকিপূর্ণ এলাকাগুলোর মালিকানা সম্মত করুন (মাইগ্রেশন, শেয়ারড কনফিগ, কোর UI)।
• দৈনন্দিন আপস্ট্রিম পরিবর্তন টেনে নিন যাতে আপনি ড্রিফট না করেন।
• যদি কোনো ফাইল বারবার "হট" হয়, সেটায় যুগ্মভাবে কাজ করুন বদলাতে গিয়ে প্রতিদ্বন্দ্বিতা করার বদলে।

যদি কনফ্লিক্ট ক্রমাগত মনে হয়, সাধারণত এটা একটি লক্ষণ যে আপনি দেরিতে ইন্টিগ্রেট করছেন, Git সমস্যা নয়।

সাপ্তাহিক কেডেন্সে রিলিজ পূর্বানুমেয়তা

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

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

কয়েকটি গুণগত গেট সাধারণত সহজ হয় কারণ একটি জায়গায় ভ্যালিডেশন:

• main-এ অটোমেটেড টেস্টগুলো পাস করতে হবে।
• QA একটি স্থির ক্যান্ডিডেট বিল্ড টেস্ট করে, অথচ প্রতি ঘণ্টায় ল্যান্ড হওয়া কিছুই নয়।
• রোলআউট ও রোলব্যাক ধাপ লিখে রাখা আছে।
• একটি স্পষ্ট রিলিজ কাট-অফ টাইম আছে (যদিও কমিট ল্যান্ড হতে থাকে)।

GitFlow-এ, রিলিজ ব্রাঞ্চ ফ্রিজ জোন হিসেবে পূর্বানুমেয়তা দেয়। আপনি একটি কাট-অফ নেন, release/* কেটে দেন, এবং শুধুমাত্র শিপ করতে প্রয়োজন এমন পরিবর্তনগুলো erlaub করা হয়। সেই সীমানা সাহায্য করে, কিন্তু এটি সহযোগিতা বাড়ায় কারণ ফিক্সগুলো সাধারণত একাধিক জায়গায় (release এবং develop) অ্যাপ্লাই করতে হয়।

অসম্পূর্ণ কাজগুলো ভিন্নভাবে মোকাবিলা করা হয়:

• ট্রাঙ্ক-ভিত্তিক: নিরাপদ অংশগুলো মার্জ করুন এবং বাকিটা ফিচার ফ্ল্যাগের পেছনে রাখুন।
• GitFlow: অসম্পূর্ণ কাজ develop-এ রাখুন এবং রিলিজ ব্রাঞ্চ থেকে বাদ দেবেন।

উদাহরণ: যদি চেকআউট উন্নয়ন Wednesday-এ আংশিক অবস্থায় থাকে, ট্রাঙ্ক-ভিত্তিক নিরাপদ রিফ্যাক্টর মার্জ করতে পারে এবং নতুন UI লুকিয়ে রাখতে পারে। GitFlow সাধারণত এটাকে develop-এ রেখে দেয়, রিলিজ ছাড়া শিপ করে, এবং পরের সাপ্তাহিক রিলিজে শেষ করে।

হটফিক্স ফ্লো: প্রোডাকশনে দ্রুত ও নিরাপদ পথ

হটফিক্স স্বাভাবিক কাজ নয়। এতে দ্রুততা, কম ঝুঁকি এবং এমন একটি পথ দরকার যাতে টিম পুনরায় একই বাগ ঠিক করতে না পড়ে।

একটি প্রশ্ন দিয়ে শুরু করুন: ঠিক কোন কোডটি এখন প্রোডাকশনে চলছে? যদি আপনি সেকেন্ডে উত্তর না দিতে পারেন, হটফিক্সগুলো অনুমান-ভিত্তিক হয়ে যাবে।

ট্রাঙ্ক-ভিত্তিক উন্নয়নে হটফিক্স

ট্রাঙ্ক-ভিত্তিক হটফিক্সগুলো সহজ মনে হতে পারে কারণ main-কে সত্যিই নির্ভরযোগ্য উৎস মনে করা হয়।

একটি সাধারণ ফ্লো:

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

কারণ টিম main-এ ঘন ঘন ইন্টিগ্রেট করে, হটফিক্স পরবর্তীতে প্রাকৃতিকভাবে পরের সাপ্তাহিক রিলিজের অংশ হয়ে যায়। প্রধান ঝুঁকি হলো main-কে রিলিজযোগ্য রাখার নিয়ম ভেঙে ফেলা—অর্ধেক-সম্পন্ন কাজ main-এ রেখে দিলে। ফিচার ফ্ল্যাগ সাহায্য করে, কিন্তু ডিফল্টভাবে ফ্ল্যাগগুলো বন্ধ রাখুন এবং হটফিক্স যাচাই করার সময় অপ্রাসঙ্গিক ফিচারগুলো চালু করবেন না।

GitFlow-এ হটফিক্স

GitFlow-এ হটফিক্স সাধারণত main (প্রোডাকশন) থেকে শুরু করে, তারপর সেই ফিক্স develop-এও মার্জ করতে হয় যাতে ফিক্স হারিয়ে না যায়।

একটি নিরাপদ ফ্লো:

• প্রোডাকশনের ট্যাগ করা কমিট থেকে hotfix/* শাখা কাটা।
• ফিক্স করে রিলিজ (হটফিক্স ব্রাঞ্চ থেকেই বা main-এ মার্জের পরে)।
• হটফিক্স main-এ মার্জ করুন এবং পাশাপাশি develop-এ মার্জ করুন।
• যদি release/* ব্রাঞ্চ থাকে, সেগুলোর ক্ষেত্রেও মার্জ করুন।

সবচেয়ে সাধারণ ব্যর্থতা হল ওই মার্জগুলোর একটি ভুলে যাওয়া। এক সপ্তাহ পরে বাগ "ফেরত আসে" কারণ develop-এ প্যাচটি ছিল না।

একটি সহজ নিয়ম বেশিরভাগ বিষয় প্রতিরোধ করে: হটফিক্স তখনই শেষ নয় যতক্ষণ না এটি সব দীর্ঘস্থায়ী ব্রাঞ্চে মার্জ করা হয়েছে যা আবার শিপ করবে।

QA পরিবেশ কীভাবে স্থিতিশীল রাখবেন (টিমকে ব্লক না করে)

সাপ্তাহিক শিপিং তখন ভেঙে যায় যখন "QA" মানে "যাই এখন ডিপ্লয় করা হয়েছে"। আপনার এনভায়রনমেন্টগুলোর নাম রাখুন এবং প্রতিটির একটি কাজ দিন: dev দ্রুত ফিডব্যাকের জন্য, QA টিম টেস্টিং-এর জন্য, staging রিলিজ চেকের জন্য, prod গ্রাহকের জন্য। যদি আপনি একটি এনভায়রনমেন্টের উদ্দেশ্য এক বাক্যে বলতে না পারেন, মানুষ সেটি ভুলভাবে ব্যবহার করবে।

চলন্ত লক্ষ্য প্রতিরোধ করার নিয়ম

স্থির QA ব্রাঞ্চিং মডেলের চেয়ে কম—এটা আসলে আপনি কি ডিপ্লয় করছেন তা নিয়ে।

ট্রাঙ্ক-ভিত্তিক কাজে, QA-তে এলোমেলো কমিট ডিপ্লয় করবেন না। একটি পিন করা ক্যান্ডিডেট (ট্যাগ করা বিল্ড, বিল্ড নম্বর, বা শর্ট-লাইভ রিলিজ-ক্যান্ডিডেট ব্রাঞ্চ) ডিপ্লয় করুন যা প্রতিবার একই চেক পাস করে। QA-কে টেস্ট করার জন্য কিছু স্থির দিন যা ডেভেলপমেন্ট চললেও পরিবর্তন হবে না।

GitFlow-এ QA সাধারণত রিলিজ ব্রাঞ্চকে ট্র্যাক করে। ফাঁদটি হচ্ছে রিলিজ ব্রাঞ্চ QA শুরু করার পরে বারবার পরিবর্তিত করার সুযোগ। QA শুরু হলে রিলিজ ব্রাঞ্চকে একটি চুক্তি হিসেবে বিবেচনা করুন: শুধুমাত্র অনুমোদিত ফিক্স গ্রহণ করুন, এবং একটি পরিষ্কার প্রক্রিয়ার মাধ্যমে।

কয়েকটি নিয়ম যেটা যে কোনো পদ্ধতিতে পূর্বানুমেয় রাখে:

• QA-তে কেবল পাস করা বিল্ডগুলো ডিপ্লয় করুন।
• ডিপ্লয় করা ভার্সন পিন করুন (ট্যাগ, বিল্ড নম্বর, বা রিলিজ ব্রাঞ্চ হেড) এবং সবাইকে জানান।
• QA পরিবর্তনগুলো সীমাবদ্ধ রাখুন শুধুমাত্র বাগ ফিক্স—নতুন ফিচার নয়।
• টেস্ট ডেটা নির্দিষ্ট সময়ে রিসেট করুন এবং কি মুছছে তা ডকুমেন্ট করুন।
• কনফিগারেশন কোড হিসেবে রাখুন (ভ্যারিয়েবল ও টেমপ্লেট) যাতে এনভায়রনমেন্ট ড্রিফট কমে।

আপনার টিম যদি AppMaster ব্যবহার করে অংশবিশেষ বিল্ডের জন্য, তখনও একই নীতি প্রযোজ্য: QA-র জন্য একটি নির্দিষ্ট বিল্ড তৈরি ও ডিপ্লয় করুন, কন্টিনিউয়াস এডিটগুলোর একটি স্ট্যাক নয়।

একাধিক টিম একটি QA শেয়ার করলে

যদি দুইটি টিম ভিন্ন ভার্সনের দরকার পড়ে তাহলে একটি শেয়ারড QA এনভায়রনমেন্ট বাধা হয়ে যায়। যদি আলাদা QA এনভায়রনমেন্ট ব্যয় করা না যায়, একটি হালকা রিসার্ভেশন নিয়ম যোগ করুন: একটি সময় উইন্ডোর জন্য একটি টিম QA-র মালিক, এবং অন্যরা dev বা staging ব্যবহার করে। ফিচার ফ্ল্যাগও সাহায্য করে কারণ অসম্পূর্ণ কাজ ডিপ্লয় করা যায় কিন্তু টেস্টারদের কাছে দৃশ্যমান করা যায় না।

উদাহরণ: টিম A সাপ্তাহিক রিলিজ ক্যান্ডিডেটটি ভ্যালিডেট করছে, তাই QA বিল্ড 1842-এ পিন থাকে সাইন-অফ পর্যন্ত। টিম B ফিক্স মার্জ করতে পারে, কিন্তু সেগুলো পরের ক্যান্ডিডেটে যায়, মাঝপথে QA টেস্টিং বদলাবে না।

ধাপে ধাপে: এমন একটি ওয়ার্কফ্লো বাছুন যা টিমটি প্রতি সপ্তাহে অনুসরণ করতে পারে

লিখে রাখুন আপনার কাছে "সাপ্তাহিক শিপিং" কী মানে। একটি রিলিজ দিন ও সময় বাছুন, ঝুঁকির স্তর নির্ধারণ করুন (উদাহরণ: "কোনো জানা P1 বাগ নেই"), এবং টিম সাইজ ও টাইমজোন লক্ষ্য করুন। এটা ব্রাঞ্চ বিতর্ককে অগ্রাধিক্য বিতর্কে পরিণত হওয়া থেকে রোধ করে।

একটি বেস মডেল বাছুন এবং এক মাস তা মানুন। প্রথম দিনেই মিশিয়ে ফেলবেন না—মিশানো সাধারণত নিয়ম বাড়ায় কিন্তু বিস্ময় কমায় না।

একটি সহজ সাপ্তাহিক ওয়ার্কফ্লো যা আপনি মানিয়ে নিতে পারেন:

• ব্রাঞ্চের আয়ুস্য সংক্ষিপ্ত রাখুন (ঘণ্টা থেকে ১-২ দিন) এবং অন্তত দৈনন্দিন মার্জ করুন।
• সেফটি রেইল যোগ করুন: দ্রুত CI, সংক্ষিপ্ত প্রয়োজনীয় রিভিউ, এবং একটি ছোট সেট অটোমেটেড টেস্ট যা বাস্তব বিরতি ধরে।
• সিদ্ধান্ত নিন আপনি কিভাবে স্কোপ নিয়ন্ত্রণ করবেন: ফিচার ফ্ল্যাগ, রিলিজের কাছে এক ক্ষণস্থায়ী রিলিজ ব্রাঞ্চ, বা সঠিক রিলিজ কমিটের জন্য ট্যাগ।
• হটফিক্স ধাপ সংজ্ঞায়িত করুন: কে ট্রিগার করতে পারে, কি চেক দরকার, এবং কিভাবে ফিক্স main লাইনে ফিরে যায়।
• QA স্থিতিশীল রাখুন: সিদ্ধান্ত নিন QA কি ট্র্যাক করবে (রিলিজ ব্রাঞ্চ না পিন করা ক্যান্ডিডেট) এবং টেস্ট চলাকালীন পরিবর্তন করবেন না যদি না আপনি টেস্ট সাইকেল রিস্টার্ট করেন।

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

উদাহরণ: উভয় মডেলে একটি বাস্তবসম্মত সাপ্তাহিক রিলিজ

ধরা যাক 6-জনের একটি প্রোডাক্ট টিম যা প্রতি শুক্রবার শিপ করে। দুই জন QA টেস্টার একটি স্টেজিং এনভায়রনমেন্ট শেয়ার করে, তাই স্টেজিং যদি অনিশ্চিত হয়, টেস্টিং সবাইয়ের জন্য বন্ধ হয়ে যায়।

GitFlow-এ একটি ব্যস্ত সপ্তাহ

সোমবার: তিনজন ডেভেলপার ফিচার শেষ করে এবং develop-এ পুল রিকোয়েস্ট খুলে। QA develop থেকে তৈরি স্টেজিং টেস্ট করতে শুরু করে।

বুধবার: টিম release/1.8 কেটে শুক্রবারের শিপ রক্ষা করে। নতুন কাজ develop-এ ল্যান্ড করে থাকে, কিন্তু QA এখন রিলিজ বিল্ডে ফোকাস করে।

বৃহস্পতিবার বিকেল: একটি দেরিতে বাগ দেখা যায়। ফিক্স প্রথমে release/1.8-এ ল্যান্ড করে যাতে QA দ্রুত পুনঃটেস্ট করতে পারে। তারপর কেউ সেই ফিক্স develop-এ মার্জ করে—এখানেই ভুলের সম্ভাবনা বেশি।

একটি সাধারণ রিদম:

• সোম-মঙ্গল: ফিচারগুলো develop-এ মার্জ, স্ট্যাজিং প্রায়ই পরিবর্তিত।
• বুধ: release/1.8 কাটা, স্ট্যাজিং রিলিজ বিল্ডে স্যুইচ করে।
• বুধ-শুক্র: release/1.8-এ বাগ ফিক্স, তারপর develop-এ মার্জ।
• শুক্র: release/1.8-কে main-এ মার্জ, ট্যাগ ও ডিপ্লয়।

একই সপ্তাহ ট্রাঙ্ক-ভিত্তিক উন্নয়নে

সপ্তাহটি ছোট, ঘন ঘন মার্জের দিকে গঠিত। ফিচারগুলো ফ্ল্যাগের পেছনে থাকে যাতে অসম্পূর্ণ কাজ মিশে গেলেও ব্যবহারকারীর কাছে দৃশ্যমান না হয়।

সোমবার থেকে বৃহস্পতিবার: ডেভেলপাররা দৈনন্দিন ছোট পরিবর্তন main-এ মার্জ করে। QA একটি পিন করা ক্যান্ডিডেট বিল্ড টেস্ট করে।

মঙ্গলবার: প্রোডাকশনে একটি সমস্যা দেখা দেয়। হটফিক্স main থেকে ছোট একটি শাখা কেটে, রিভিউ করে দ্রুত মার্জ ও প্রোমোট করা হয়। কারণ main-ই সত্যের উৎস, অতিরিক্ত ব্যাক-মার্জ ধাপ নেই।

উভয় ক্ষেত্রে টিমকে পরিষ্কার প্রমোশন নিয়ম দরকার:

• স্টেজিং সর্বশেষ পিন করা ক্যান্ডিডেট বিল্ড চালায়, প্রতিটি নতুন কমিট নয়।
• QA একটি নতুন ক্যান্ডিডেট তখনই অনুরোধ করে যখন তারা প্রস্তুত—স্বয়ংক্রিয়ভাবে নয়।
• শুধুমাত্র শুক্রবারের রিলিজের জন্য অনুমোদিত ফিক্স ক্যান্ডিডেট পরিবর্তন করতে পারে।
• বাকিটা ফিচার ফ্ল্যাগ বা পরের ক্যান্ডিডেটে থাকে।

এমন ভুলগুলো যা চূর্ণবিচূর্ণ ও অস্হির QA তৈরি করে

বেশিরভাগ টিম ব্যর্থ হয় কারণ তারা "ভুল" মডেল বেছে নিয়েছে না—তারা ব্যর্থ হয় কারণ দৈনন্দিন অভ্যাসগুলো মডেলের সাথে মেলে না, ফলে QA গোলমেলে এবং রিলিজগুলো এলোমেলো মনে হয়।

একটি সাধারণ সমস্যা: ব্রাঞ্চগুলো কয়েক দিন বসে থাকা অনুমতি দেয় কারণ "এটি প্রস্তুত নয়"। কোড main থেকে ড্রিফট করে, কনফ্লিক্ট জমে যায়, এবং QA এমন একটি মিশ্র কাজ টেস্ট করে যা কেউ পুনরুৎপাদন করতে পারে না।

আরেকটা হচ্ছে GitFlow ব্যবহার করে কিন্তু বাস্তবে ফ্রিজ না থাকা। রিলিজ ব্রাঞ্চ স্থিতিশীল করার জন্য, টিমরা ফলে "আরেকটা ছোট পরিবর্তন" গোপনে ঢুকিয়ে দেয়। এটি রিলিজ ব্রাঞ্চকে দ্বিতীয় main-এ পরিণত করে, এবং কেউ জানে না QA কি সাইন-অফ করলো।

QA তখনও অনিশ্চিত হয় যখন সেটাকে আধা-সমাপ্ত বিল্ডের ডাম্প এ প্রতিহত করা হয়। যদি প্রতিটি কমিট QA-তে যায় কোনো নিয়ম ছাড়াই, টেস্টাররা চলন্ত লক্ষ্য পেছন করে সময় নষ্ট করে বরং একটি রিলিজ ভ্যালিডেট করতে।

সবচেয়ে বেশি churn তৈরি করে এমন ভুলগুলো:

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

একটি নিয়ম সেট রাখুন যা সবাই পুনরাবৃত্তি করতে পারে:

• QA কেবল একটি পিন করা ক্যান্ডিডেট টেস্ট করে।
• QA থেকে প্রোডাকশনে একই আর্টিফ্যাক্ট প্রোমোট করা হয়।
• প্রতিটি এনভায়রনমেন্টের একটি মালিক এবং রিসেট ক্যাডেন্স আছে।
• হটফিক্স একই দিন মেইন লাইনে ফিরে যায়।

সাপ্টাহিক শিপিং ছাড়া বিস্ময় এড়ানোর দ্রুত চেকলিস্ট

সাপ্তাহিক শিপিং কাজ করে যখন আপনার টিম কয়েকটি বিরক্তিকর প্রশ্ন আত্মবিশ্বাসের সাথে উত্তর দিতে পারে। যদি আপনি দুই বা ততোধিক প্রশ্নে "না" বলতে পারেন, দেরি-লোকাল ফিক্স ও QA হুইপল্যাশ অপেক্ষা করুন।

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

যদি একটি পরিমাপযোগ্য লক্ষ্য চান: QA-কে একটি রিলিজ ক্যান্ডিডেটে পিন করুন এবং কেবল অভিপ্রেত ফিক্স ছাড়া সেটা অপরিবর্তিত রাখুন।

পরবর্তী ধাপ: আগামী সপ্তাহে এক পরিবর্তন ট্রাই করুন

আপনার টিম যদি ট্রাঙ্ক-ভিত্তিক বনাম GitFlow নিয়ে আটকে থাকে, সবকিছু একবারে রিডিজাইন করবেন না। সবচেয়ে বেশি সময় খাওয়া সমস্যা এক টুকরা বেছে নিন এবং পরের রিলিজের জন্য একটি ছোট পরীক্ষানিরীক্ষা চালান।

যদি মার্জ কনফ্লিক্ট সবচেয়ে বড় ব্যথা হয়, অবিলম্বে ব্রাঞ্চ আয়ু ছোট করুন। লক্ষ্য রাখুন দৈনন্দিন (বা প্রতিদিন পর পর) কাজ ল্যান্ড করা, প্রয়োজনে ফিচার ফ্ল্যাগ ব্যবহার করে।

যদি QA অস্থিরতা সবচেয়ে বড় সমস্যা হয়, QA-কে কি টেস্ট করতে হবে তা পিন করে একটি সরল প্রমোশন স্টেপ নির্ধারণ করে শুরু করুন।

একটি হালকা পাইলট:

• একটি রিপো এবং একটি টিম বেছে নিন।
• ব্রাঞ্চ বয়স সীমা সেট করুন (উদাহরণ: 2 দিনের বেশি কোনো ব্রাঞ্চ থাকবে না)।
• QA-কে একটি বিল্ডে পিন করুন এবং শুধুমাত্র স্পষ্ট প্রমোশনের মাধ্যমে বদলান।
• তিনটা সংখ্যা ট্র্যাক করুন: মার্জ-রেজোলিউশন সময়, QA รีওয়ার্ক ঘণ্টা, এবং হটফিক্স টাইম-টু-প্রোডাকশন।
• 2-4 সপ্তাহ পরে রিভিউ করুন এবং অ্যাডজাস্ট করুন।

আপনি যদি ইন্টারনাল টুলস বা কাস্টমার পোর্টালগুলোর রিলিজ চাপ কমাতে চান, একটি নো-কোড প্ল্যাটফর্ম যেমন AppMaster (appmaster.io) সাহায্য করতে পারে ভিজ্যুয়াল ডিজাইন থেকে প্রোডাকশন-রেডি backend, web, এবং native mobile অ্যাপ জেনারেট করে। তবুও উপরোক্ত অভ্যাসগুলি প্রযোজ্য: ছোট পরিবর্তন, পিন করা QA ক্যান্ডিডেট, এবং স্পষ্ট প্রমোশন পথ।