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 एक पूर्ण pipeline शुरू करता है: बिल्ड, यूनिट टेस्ट, इंटीग्रेशन टेस्ट, लिंटर्स, स्थैतिक विश्लेषण, कोड कवरेज जाँच। यदि कम से कम एक चरण विफल होता है, तो लेखक अगले कमिट से पहले कोड ठीक करता है। “टूटा हुआ trunk — रुका हुआ डेवलपमेंट” TBD का मुख्य नियम है।

Jez Humble, Continuous Delivery, 2024 के अनुसार, Trunk-Based Development के लिए CI pipeline की आवश्यकता है जो 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 pipeline चलाता है, और केवल हरी स्थिति के बाद कमिट trunk तक पहुँचता है। GitLab में, यह “Merge when pipeline succeeds” विकल्प के साथ Merge Request pipelines के माध्यम से कार्यान्वित किया जाता है। 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 pipeline में 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 उपयोगकर्ताओं तक की मुफ़्त सीमा के कारण सबसे लोकप्रिय विकल्प है।