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٪. TBD إلزامي لـ Continuous Deployment.

Trunk-Based Development لا يعني أن المطورين يرتكزون مباشرة إلى trunk دون مراجعة. في TBD، تُستخدم فروع ميزات قصيرة العمر يتم دمجها في trunk بعد إنشاء MR ومراجعة سريعة للكود (في غضون ساعات). إذا استغرقت المراجعة أكثر من يوم، يجب تقسيم الميزة إلى أجزاء أصغر.

State of DevOps Report: بيانات عن TBD

State of DevOps Report السنوي (Puppet/DORA) يتتبع ممارسات الفرق عالية الأداء. منذ عام 2015، كان TBD ضمن أفضل 3 ممارسات مرتبطة بارتفاع تردد النشر (deploy frequency) وانخفاض وقت الاسترداد (MTTR). الفرق التي تطبق TBD تنشر الكود 2–3 مرات أكثر وتتعافى من الأعطال أسرع بنسبة 30٪ (DORA، 2023).

Feature Toggles: إدارة الكود غير المكتمل بدون فروع

Feature Toggles (أعلام الميزات، feature flags) هي آلية لتفعيل وتعطيل الوظائف دون تغيير الكود. في TBD، تحل feature toggles محل فروع الميزات: يرسل المطور كودًا غير مكتمل إلى trunk ولكنه يخفيه خلف علم شرطي. عندما تكون الميزة جاهزة للعرض، يتم تبديل العلم في التكوين دون إعادة نشر.

وفقًا لـ Martin Fowler، 2024، تنقسم feature toggles إلى أربعة أنواع: release toggles (إدارة رؤية الميزة)، experiment toggles (اختبار A/B)، ops toggles (إدارة المعايير التشغيلية)، و permission toggles (الوصول حسب الأدوار). في المشاريع المحمولة، release toggles مفيدة بشكل خاص: الوظيفة الجديدة مخفية حتى تاريخ الإصدار، لكن الكود موجود بالفعل في trunk ويمر عبر CI/CD.

// Feature Toggle في Android على Kotlin
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()
}

CI/CD في Trunk-Based Development: الممارسات الإلزامية

Continuous Integration (CI) هو العنصر الأهم في TBD. كل push إلى trunk (أو إلى فرع مؤقت قبل MR) يشغل pipeline كامل: بناء، اختبارات وحدة، اختبارات تكامل، أدوات تحليل، تحليل ثابت، فحص تغطية الكود. إذا فشلت مرحلة واحدة على الأقل، يقوم المؤلف بإصلاح الكود قبل الارتكاز التالي. «trunk مكسور — توقف التطوير» هي القاعدة الرئيسية لـ TBD.

وفقًا لـ Jez Humble، Continuous Delivery، 2024، Trunk-Based Development يتطلب pipeline CI يتم تنفيذه في 10–15 دقيقة. إذا استغرق البناء وقتًا أطول، يقل ارتكاز المطورين، مما يدمر معنى TBD. في المشاريع المحمولة، يمكن أن يستغرق بناء Android و iOS 20–30 دقيقة، مما يجعل TBD أقل ملاءمة. في هذه الحالات، تستخدم الفرق Short-Lived Feature Branches (فروع لمدة يوم واحد) مع CI فوري.

# GitHub Actions لـ TBD (Android)
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 حديث (لا يتجاوز عمره ساعة واحدة)، لا تتم مزامنته مع trunk عبر merge/rebase (إذا مر أكثر من 4 ساعات، يتم إنشاء فرع جديد)، يتم إنشاء MR/PR فورًا بعد أول ارتكاز (حتى لو كان العمل غير مكتمل — كـ Draft).

Pre-tested commits: ارتكازات بضمان

لـ Trunk-Based Development، تقنية pre-tested commits مهمة: يشغل المطور pipeline CI في فرعه قبل الارتكاز، وفقط بعد حالة خضراء يصل الارتكاز إلى trunk. في GitLab، يتم ذلك عبر Merge Request pipelines مع خيار «Merge when pipeline succeeds». في GitHub — عبر branch protection rules مع Required status checks. هذا يضمن أن 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 أو ضعف انضباط الارتكازات. الخطأ الأول هو تطبيق TBD بدون CI، والذي ينهار من أول ارتكاز فاشل. إذا تعذر إصلاح trunk في غضون 15 دقيقة، يفقد الفريق الثقة في العملية ويعود إلى الفروع الطويلة. الخطأ الثاني هو السماح بفروع طويلة العمر «فقط لهذه الميزة»، مما يدمر المفهوم بأكمله.

وفقًا لـ Paul Hammant، 2023، الخطأ الثالث هو ضعف نمطية الكود. Trunk-Based Development يتطلب أن يكون الكود مقسمًا إلى وحدات مستقلة. إذا كان تغيير في فئة واحدة يكسر ثلاث وحدات أخرى، لا يمكن للمطورين الارتكاز في أجزاء صغيرة. الخطأ الرابع هو تجاهل feature toggles: محاولة إرسال كود غير مكتمل دون علم يؤدي إلى كسر trunk للفريق بأكمله.

Trunk-Based Development في التطوير المحمول

Trunk-Based Development في المشاريع المحمولة له خصائص بسبب أوقات البناء الطويلة (20–30 دقيقة لنظامي Android و iOS) ومتطلبات الجودة الصارمة. Google و Spotify يستخدمان TBD في التطوير المحمول، مع تطبيق فروع قصيرة العمر مع CI إلزامي قبل الدمج. تتم إدارة Feature toggles عبر Firebase Remote Config أو LaunchDarkly.

وفقًا لـ LaunchDarkly Docs، 2024، في التطوير المحمول، يوفر TBD ميزة: يتم اختبار الوظائف في trunk مع بقية الكود قبل تاريخ الإصدار، مما يقلل من خطر مشاكل التكامل. إذا استغرق pipeline CI أكثر من 15 دقيقة، فإن الفروع قصيرة العمر لمدة يوم واحد مع CI تلقائي عند كل push هي الأمثل. بالنسبة لـ Apple App Store و Google Play، يتطلب TBD إعداد نشر تدريجي عبر feature toggles.

Feature Flags كخدمة: LaunchDarkly و Firebase

لإدارة feature toggles في TBD، تُستخدم منصات: LaunchDarkly (مؤسسي، كامل الميزات)، Firebase Remote Config (مجاني للمشاريع الصغيرة)، Split.io (مفتوح المصدر). توفر: تفعيل الميزات المستهدف حسب نسبة المستخدمين، اختبار A/B، مراقبة الاستخدام، وإيقاف التشغيل التلقائي عند الأخطاء. في المشاريع المحمولة، Firebase Remote Config هو الخيار الأكثر شيوعًا بسبب تكامله مع Firebase وحدوده المجانية حتى 1000 مستخدم.