Trunk-Based Development — یہ کیا ہے، اصول اور ایک برانچ میں کام کرنا

Trunk-Based Development کیا ہے؟

Trunk-Based Development (TBD) ایک ورژن مینجمنٹ طریقہ کار ہے جس میں تمام ڈویلپرز دن میں کئی بار اپنی تبدیلیوں کو ایک واحد مرکزی برانچ (trunk، main یا master) میں ضم کرتے ہیں۔ طویل المدتی فیچر برانچز والے 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 میں قلیل مدتی فیچر برانچز استعمال ہوتی ہیں، جو 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 فیچر برانچز کی جگہ لیتے ہیں: ڈویلپر نامکمل کوڈ 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 صارفین تک کی مفت حد کی وجہ سے سب سے مقبول انتخاب ہے۔