Trunk-Based Development — এটি কী, নীতি এবং একটি শাখায় কাজ করা

Trunk-Based Development কী?

Trunk-Based Development (TBD) হল একটি সংস্করণ পরিচালনা পদ্ধতি যেখানে সমস্ত ডেভেলপার দিনে কয়েকবার তাদের পরিবর্তনগুলি একটি একক প্রধান শাখায় (trunk, main বা master) একীভূত করে। দীর্ঘস্থায়ী feature-শাখার সাথে Git Flow-এর বিপরীতে, TBD শাখার জীবনকাল কয়েক ঘণ্টায় কমিয়ে আনে, খুব কমই 1–2 দিনে। মূল লক্ষ্য হল “মার্জ হেল” (merge hell) এড়ানো, যখন সপ্তাহের ডেভেলপমেন্টের পরে একটি বড় ফিচার trunk-এ মার্জ করা হয়।

Google Cloud DevOps, 2024 অনুসারে, Trunk-Based Development উচ্চক্ষমতাসম্পন্ন DevOps দলের মূল অনুশীলনগুলির মধ্যে একটি। State of DevOps Report (Puppet, 2023) দেখিয়েছে যে TBD ব্যবহারকারী দলগুলি ব্যর্থতা থেকে 30% দ্রুত পুনরুদ্ধার করে এবং উৎপাদনে সমালোচনামূলক ত্রুটির মুখোমুখি হয় 50% কম। Continuous Deployment-এর জন্য TBD বাধ্যতামূলক।

Trunk-Based Development মানে এই নয় যে ডেভেলপাররা পর্যালোচনা ছাড়াই সরাসরি trunk-এ কমিট করে। TBD-তে স্বল্পস্থায়ী feature-শাখা ব্যবহার করা হয়, যা MR তৈরি এবং দ্রুত কোড পর্যালোচনার (কয়েক ঘণ্টার মধ্যে) পরে trunk-এ মার্জ করা হয়। যদি পর্যালোচনা এক দিনের বেশি সময় নেয়, তাহলে ফিচারটিকে ছোট অংশে বিভক্ত করতে হবে।

State of DevOps Report: TBD-তে তথ্য

বার্ষিক State of DevOps Report (Puppet/DORA) উচ্চক্ষমতাসম্পন্ন দলের অনুশীলনগুলি ট্র্যাক করে। 2015 সাল থেকে, TBD উচ্চ ডিপ্লয় ফ্রিকোয়েন্সি (deploy frequency) এবং কম পুনরুদ্ধার সময় (MTTR) এর সাথে সম্পর্কিত শীর্ষ 3টি অনুশীলনের মধ্যে রয়েছে। TBD অনুশীলনকারী দলগুলি 2–3 গুণ বেশি বার কোড ডিপ্লয় করে এবং ব্যর্থতা থেকে 30% দ্রুত পুনরুদ্ধার করে (DORA, 2023)।

Feature Toggles: শাখা ছাড়াই অসম্পূর্ণ কোড পরিচালনা

Feature Toggles (ফিচার ফ্ল্যাগ) — কোড পরিবর্তন না করে কার্যকারিতা চালু এবং বন্ধ করার একটি প্রক্রিয়া। TBD-তে, feature toggles feature-শাখা প্রতিস্থাপন করে: ডেভেলপার অসম্পূর্ণ কোড trunk-এ কমিট করে কিন্তু এটি একটি শর্তসাপেক্ষ ফ্ল্যাগের পিছনে লুকিয়ে রাখে। যখন ফিচারটি প্রদর্শনের জন্য প্রস্তুত হয়, ফ্ল্যাগটি পুনরায় ডিপ্লয়মেন্ট ছাড়াই কনফিগারেশনে পরিবর্তন করা হয়।

Martin Fowler, 2024 অনুসারে, feature toggles চার প্রকারে বিভক্ত: release toggles (ফিচার দৃশ্যমানতা পরিচালনা), experiment toggles (A/B পরীক্ষা), ops toggles (পরিচালনাগত প্যারামিটার পরিচালনা) এবং permission toggles (ভূমিকা-ভিত্তিক অ্যাক্সেস)। মোবাইল প্রকল্পগুলিতে, release toggles বিশেষভাবে উপযোগী: নতুন কার্যকারিতা প্রকাশের তারিখ পর্যন্ত লুকানো থাকে, কিন্তু কোড ইতিমধ্যে trunk-এ থাকে এবং CI/CD-র মধ্য দিয়ে যায়।

// Android-এ Kotlin-এ Feature Toggle
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// কোডে ব্যবহার
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

Trunk-Based Development-এ CI/CD: বাধ্যতামূলক অনুশীলন

Continuous Integration (CI) TBD-র সবচেয়ে গুরুত্বপূর্ণ উপাদান। trunk-এ (বা MR-এর আগে অস্থায়ী শাখায়) প্রতিটি push একটি সম্পূর্ণ পাইপলাইন শুরু করে: বিল্ড, ইউনিট টেস্ট, ইন্টিগ্রেশন টেস্ট, লিন্টার, স্ট্যাটিক বিশ্লেষণ, কোড কভারেজ পরীক্ষা। যদি অন্তত একটি পর্যায় ব্যর্থ হয়, লেখক পরবর্তী কমিটের আগে কোড ঠিক করেন। “ভাঙা trunk — বন্ধ ডেভেলপমেন্ট” TBD-র প্রধান নিয়ম।

Jez Humble, Continuous Delivery, 2024 অনুসারে, Trunk-Based Development-এর জন্য একটি CI পাইপলাইন প্রয়োজন যা 10–15 মিনিটে সম্পন্ন হয়। যদি বিল্ড বেশি সময় নেয়, ডেভেলপাররা কম ঘন ঘন কমিট করে, যা TBD-র অর্থ নষ্ট করে। মোবাইল প্রকল্পগুলিতে, Android এবং iOS বিল্ড 20–30 মিনিট সময় নিতে পারে, যা TBD-কে কম সুবিধাজনক করে তোলে। এই ধরনের ক্ষেত্রে, দলগুলি তাৎক্ষণিক CI সহ Short-Lived Feature Branches (1 দিনের শাখা) ব্যবহার করে।

# TBD (Android)-এর জন্য GitHub Actions
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

স্বল্পস্থায়ী শাখা: TBD-তে কাজের নিয়ম

স্বল্পস্থায়ী শাখা (short-lived branches) হল খাঁটি TBD (সরাসরি trunk-এ কমিট) এবং Git Flow-এর মধ্যে একটি সমঝোতা। একটি শাখা 1–2 দিনের বেশি বাঁচে না, এতে 1–3 কমিটের পরিবর্তন থাকে এবং পর্যালোচনার (সর্বোচ্চ 4 ঘণ্টা অপেক্ষা) পরে trunk-এ মার্জ করা হয়। যদি কোনো ফিচারের আরও সময় প্রয়োজন হয়, তবে এটি উপ-কাজে বিভক্ত করা হয়, প্রতিটির নিজস্ব স্বল্পস্থায়ী শাখা থাকে।

TBD Documentation, 2024 অনুসারে, স্বল্পস্থায়ী শাখার নিয়ম: শাখাটি একটি তাজা trunk (1 ঘণ্টার বেশি পুরানো নয়) থেকে তৈরি করা হয়, merge/rebase-এর মাধ্যমে trunk-এর সাথে সিঙ্ক করা হয় না (যদি 4 ঘণ্টার বেশি হয়ে যায়, একটি নতুন শাখা তৈরি করা হয়), MR/PR প্রথম কমিটের সাথে সাথেই তৈরি করা হয় (এমনকি কাজ সম্পূর্ণ না হলেও — Draft হিসাবে)।

Pre-tested Commits: গ্যারান্টি সহ কমিট

Trunk-Based Development-এর জন্য, pre-tested commits কৌশল গুরুত্বপূর্ণ: ডেভেলপার কমিট করার আগে তার শাখায় CI পাইপলাইন চালায়, এবং শুধুমাত্র সবুজ অবস্থার পরে কমিট trunk-এ পৌঁছায়। GitLab-এ, এটি “Merge when pipeline succeeds” বিকল্পের সাথে Merge Request পাইপলাইনের মাধ্যমে বাস্তবায়িত হয়। GitHub-এ — Required status checks সহ branch protection rules-এর মাধ্যমে। এটি নিশ্চিত করে যে trunk-এ কখনও ভাঙা কোড থাকে না।

• 1–2 দিন — short-lived branch-এর সর্বোচ্চ জীবনকাল
• 1–3 কমিট — পরিবর্তনের সর্বোত্তম আকার
• 4 ঘণ্টা — কোড পর্যালোচনার জন্য সর্বোচ্চ অপেক্ষার সময়
• MR তৈরি করুন প্রথম কমিটের সাথে সাথেই, এমনকি Draft অবস্থায়ও

Branch by Abstraction: শাখা না করে কোড প্রতিস্থাপন

Branch by Abstraction একটি কৌশল যা দীর্ঘস্থায়ী ফিচার শাখা তৈরি না করেই সিস্টেমের একটি অংশ প্রতিস্থাপন বা উল্লেখযোগ্যভাবে পরিবর্তন করতে দেয়। Git-এ শাখা করার পরিবর্তে, ডেভেলপার একটি অ্যাবস্ট্রাকশন (ইন্টারফেস) তৈরি করে যার অধীনে পুরানো এবং নতুন উভয় বাস্তবায়ন কাজ করে। ধীরে ধীরে, সমস্ত ভোক্তা নতুন বাস্তবায়নে স্থানান্তরিত হয়, তারপরে পুরানোটি সরানো হয়।

Branch by Abstraction, 2024 অনুসারে, Branch by Abstraction-এর পর্যায়গুলি: 1) প্রতিস্থাপনযোগ্য উপাদানের জন্য একটি অ্যাবস্ট্রাকশন তৈরি করুন, 2) অ্যাবস্ট্রাকশনের অধীনে নতুন সংস্করণ বাস্তবায়ন করুন, 3) কনফিগারেশনের মাধ্যমে ভোক্তাদের নতুন বাস্তবায়নে স্থানান্তর করুন, 4) পুরানো বাস্তবায়ন সরান। সমস্ত ধাপ ছোট অংশে trunk-এ কমিট করা হয়, যার প্রতিটি CI/CD ভাঙে না।

TBD বনাম Git Flow: পদ্ধতির তুলনা

Trunk-Based Development এবং Git Flow শাখা পরিচালনার দুটি বিপরীত পদ্ধতি। Git Flow দীর্ঘস্থায়ী শাখা এবং কঠোর শ্রেণিবিন্যাস ব্যবহার করে, TBD একটি একক শাখা এবং ছোট একীকরণ চক্র ব্যবহার করে। তাদের মধ্যে পছন্দ দলের আকার, প্রকাশের ফ্রিকোয়েন্সি এবং CI/CD অটোমেশনের স্তরের উপর নির্ভর করে।

Trunk-Based Development বাস্তবায়নে সাধারণ ভুল

TBD ভুল প্রায়ই অপর্যাপ্ত CI/CD বা দুর্বল কমিট শৃঙ্খলার সাথে সম্পর্কিত। প্রথম ভুল হল CI ছাড়া TBD বাস্তবায়ন করা, যা প্রথম ব্যর্থ কমিটেই ভেঙে যায়। যদি trunk 15 মিনিটের মধ্যে ঠিক করা না যায়, দল প্রক্রিয়ায় বিশ্বাস হারায় এবং দীর্ঘ শাখায় ফিরে আসে। দ্বিতীয় ভুল হল “শুধুমাত্র এই ফিচারের জন্য” দীর্ঘস্থায়ী শাখার অনুমতি দেওয়া, যা পুরো ধারণাটি নষ্ট করে দেয়।

Paul Hammant, 2023 অনুসারে, তৃতীয় ভুল হল দুর্বল কোড মডুলারিটি। Trunk-Based Development-এর জন্য প্রয়োজন যে কোডটি স্বাধীন মডিউলে বিভক্ত হোক। যদি একটি ক্লাসে পরিবর্তন অন্য তিনটি মডিউল ভেঙে দেয়, ডেভেলপাররা ছোট অংশে কমিট করতে পারে না। চতুর্থ ভুল হল feature toggles উপেক্ষা করা: ফ্ল্যাগ ছাড়া অসম্পূর্ণ কোড কমিট করার প্রচেষ্টা পুরো দলের জন্য trunk ভেঙে দেয়।

মোবাইল ডেভেলপমেন্টে Trunk-Based Development

Trunk-Based Development মোবাইল প্রকল্পগুলিতে দীর্ঘ বিল্ড সময় (Android এবং iOS-এর জন্য 20–30 মিনিট) এবং কঠোর মানের প্রয়োজনীয়তার কারণে বৈশিষ্ট্য রাখে। Google এবং Spotify মোবাইল ডেভেলপমেন্টে TBD ব্যবহার করে, মার্জের আগে বাধ্যতামূলক CI পাস সহ স্বল্পস্থায়ী শাখা প্রয়োগ করে। Feature toggles Firebase Remote Config বা LaunchDarkly-র মাধ্যমে পরিচালিত হয়।

LaunchDarkly Docs, 2024 অনুসারে, মোবাইল ডেভেলপমেন্টে TBD একটি সুবিধা দেয়: ফিচারগুলি প্রকাশের তারিখের আগে trunk-এ বাকি কোডের সাথে পরীক্ষা করা হয়, যা একীকরণ সমস্যার ঝুঁকি হ্রাস করে। যদি CI পাইপলাইনে 15 মিনিটের বেশি সময় লাগে, তবে প্রতিটি push-এ স্বয়ংক্রিয় CI সহ 1 দিনের স্বল্পস্থায়ী শাখা সর্বোত্তম। Apple App Store এবং Google Play-র জন্য, TBD-কে feature toggles-এর মাধ্যমে ধাপে ধাপে রোলআউট সেটআপ করতে হবে।

একটি পরিষেবা হিসাবে Feature Flags: LaunchDarkly এবং Firebase

TBD-তে feature toggles পরিচালনার জন্য প্ল্যাটফর্ম ব্যবহার করা হয়: LaunchDarkly (এন্টারপ্রাইজ, পূর্ণ-বৈশিষ্ট্যযুক্ত), Firebase Remote Config (ছোট প্রকল্পের জন্য বিনামূল্যে), Split.io (ওপেন-সোর্স)। এগুলি প্রদান করে: ব্যবহারকারীর শতাংশ অনুসারে লক্ষ্যবস্তু ফিচার সক্রিয়করণ, A/B পরীক্ষা, ব্যবহার পর্যবেক্ষণ এবং ত্রুটিতে স্বয়ংক্রিয় নিষ্ক্রিয়করণ। মোবাইল প্রকল্পগুলিতে, Firebase Remote Config Firebase-এর সাথে একীকরণ এবং 1000 ব্যবহারকারী পর্যন্ত বিনামূল্যের সীমার কারণে সবচেয়ে জনপ্রিয় পছন্দ।