استراتيجيات فروع Git لفرق Salesforce: قاعدة اختيار واضحة

باختصار: اختار نموذج الفروع بناءً على مدخلين بس: حجم الفريق وتوزيع بيئات الاختبار، ومافيش تالت. أقل من أربعة مساهمين وبيئات تطوير بس؟ فرع main واحد وفروع ميزات قصيرة العمر. من أربعة لعشرة مع بيئة Partial Copy للاختبار؟ ضيف فرع إصدار لكل إطلاق وقف عند كده. أكتر من كده، أو عندك Full sandbox ونافذة تغيير ثابتة؟ ساعتها GitFlow بيستاهل طقوسه. أما فرع لكل بيئة فده قرار امتثال مش قرار هندسي.

استراتيجية الفروع بتحدد إيه فعلًا؟

ثلاث حاجات بس: فين الشغل الجاري بيعيش، وإزاي التغيير بيترقّى للبيئة اللي بعدها، وإيه اللي لازم يكون متحقق قبل ما حاجة توصل للإنتاج. أي حاجة تانية زخرفة على الرسم البياني.

وفرق Salesforce بتغلط هنا لأن النصيحة الهندسية العامة بتفترض حاجة مش صحيحة على المنصة: إن الفرع بيديك مكان تشغّله فيه.

إيه النماذج الثلاثة بلغة بسيطة؟

Trunk-based بفروع ميزات قصيرة

فرع واحد طويل العمر، main، بيعكس دايمًا اللي المفروض يكون في الإنتاج. فروع الميزات بتعيش أيام مش أسابيع، وبترجع عن طريق طلب دمج. أقل أجزاء متحركة، وأقل تعارضات، وأصعب انضباط.

GitFlow

main للكود المُصدَّر، وdevelop للشغل المدمج، وفروع إصدار وإصلاح عاجل. مبني للإصدارات المجدولة ولصيانة نسخة حية وأنت بتبني اللي بعدها. تكلفته فرع دائم زيادة وشغل دمج كتير.

فرع لكل بيئة

فرع بيعكس كل مؤسسة: تطوير، واختبار قبول، وتجريبي، وإنتاج. غالبًا أول حاجة الفرق بتبنيها، لأنها شبه مشهد المؤسسات اللي عندهم أصلًا. الترقية بتبقى دمج بين فروع البيئات، وده بيبان مرتب وبيتحول لدمج فوق دمج مع انتقاء تغييرات بشكل روتيني.

أنهي قيود في Salesforce بتكسر نصيحة الكتب؟

هنا بتقف معظم المقالات عن الفروع، وهنا بالظبط بيتاخد القرار الحقيقي.

• الفرع ما بيديكش مؤسسة. البيئات نادرة وبطيئة. Salesforce بتحدد حدود دنيا للتحديث: يوم واحد لبيئات Developer وDeveloper Pro، وخمس أيام لـ Partial Copy، و29 يوم لـ Full. يعني عدد الفروع طويلة العمر اللي تقدر تختبرها فعلًا محدود بعدد بيئاتك، مش بمهارتك في Git.
• البيانات الوصفية بتتسحب مش بتتكتب. الإداريون بيغيروا في المؤسسة وحد بيسحب بعد كده. الفرع طويل العمر ما ينفعش يتصالح مع شغل تعريفي ما دخلش Git من الأساس.
• فيه حاجات مالهاش فرع خالص. إعدادات المؤسسة العامة، والتراخيص، وبعض التهيئة، وكل بيانات السجلات، كلها عايشة برة المستودع. أي نموذج بيفترض إن كل فرق بين البيئات موجود في Git هيكذب عليك بهدوء.
• مافيش feature flags للنقرات. الـ trunk-based في الهندسة العادية بيعتمد على مفاتيح تشغيل لدمج شغل مش خالص. التهيئة التعريفية غالبًا مالهاش مفتاح، فالمكافئ في Salesforce إنك تنشر البيانات الوصفية وتأجل إسناد مجموعة الصلاحيات لحد لحظة الإطلاق.
• تكلفة الدمج غير متماثلة. الـ Profiles ومجموعات الصلاحيات والتخطيطات بتتعارض أسوأ بكتير من Apex. وكل أسبوع زيادة في عمر الفرع بيضاعف التكلفة دي، وده بيدفع Salesforce ناحية الفروع القصيرة أكتر من البرمجيات العادية.

يبقى قاعدة الاختيار إيه؟

1. من واحد لثلاثة مساهمين، بيئات تطوير بس، ومافيش تاريخ إصدار ثابت. main وفروع ميزات قصيرة. أي حاجة زيادة طقوس هتسيبها في الشهر التالت.
2. من أربعة لعشرة، وبيئة Partial Copy للاختبار، وإصدار كل sprint. main، وفروع قصيرة، وفرع إصدار لكل إطلاق. قاوم إضافة develop دائم، عدد بيئاتك ما بيبررهوش.
3. أكتر من عشرة مساهمين، أو Full sandbox، أو نافذة تغيير ثابتة، أو محتاج تصلّح الإصدار الحي وأنت بتبني اللي بعده. ساعتها GitFlow، والطقوس بقت بتشتري حاجة حقيقية.
4. فرق الحزم والـ ISV. افرع حسب إصدار الحزمة مش حسب البيئة. وحدة الإصدار عندك هي نسخة الحزمة وبيئة الاختبار scratch org، فالفروع حسب البيئة بتنمذج الحاجة الغلط.
5. فرع لكل بيئة. مبرر لما الفرع لازم يكون مرآة قابلة للتدقيق لحالة المؤسسة، وده مطلب تنظيمي مش تفضيل تسليم. ادخل عليه وأنت عارف التكلفة: انتقاء التغييرات هيبقى روتين والانحراف هيبقى غير مرئي.

خد بالك إن إيقاع الإصدارات بالكاد ظهر. الإيقاع نتيجة لتوزيع بيئاتك مش مدخل مستقل، والفرق اللي بتختار على أساس الإيقاع المرغوب بتطلع بعملية بيئاتها مش قادرة تشيلها.

إزاي تخرج من نموذج فرع لكل بيئة من غير انفجار كبير؟

1. بطّل تنشئ فروع بيئات جديدة من النهارده. النموذج بيبطل ينمو قبل ما يبدأ يصغر.
2. صالح main مع الإنتاج وتعامل مع الفرق كقائمة شغل حقيقية مش فضول. غالبًا المفاجآت هناك.
3. حوّل فروع البيئات لأهداف نشر في الخط بدل ما تكون فروع Git. البيئة هتفضل موجودة، بس هتبطل تكون مكان يعيش فيه كود.
4. حدد عمر فرع الميزة بـ sprint واحد. اللي أطول من كده محتاج حد حزمة أو بوابة صلاحيات، مش فرع أطول.
5. احتفظ بفرع إصدار واحد بالظبط، وبس لو فعلًا بتدعم إصدارًا حيًا وأنت بتبني اللي بعده.

إزاي تخلي النموذج يثبت؟

النموذج اللي بينجو من الاحتكاك بفريق حقيقي هو اللي الخط بيفرضه، مش اللي مكتوب في وثيقة التعريف. لو الاستشاري لازم يفتكر قواعد الفروع، القواعد هتتكسر في أول أسبوع إصدار مزحوم. Serpent بتشتغل بنظام تذاكر وGit في الخلفية، فالفرع وطلب الدمج ومسار الترقية بييجوا من التذكرة مش من الذاكرة. فيه أدلة تانية عن خطوط التسليم في مكتبة SF Guides بتاعتنا.

FAQ

هل الـ trunk-based واقعي لفريق من الإداريين؟

أيوه، وغالبًا أسهل من GitFlow لأن فيه فرع واحد بس تفهمه. الانضباط المطلوب هو قصر عمر الفروع، مش إتقان Git.

محتاجين فرع Git لكل بيئة اختبار؟

لأ. البيئة هدف نشر. ربط فرع بكل مؤسسة هو السبب الرئيسي في الدمج فوق الدمج والانتقاء الدائم للتغييرات.

فرع الميزة في Salesforce يعيش قد إيه؟

أيام. الـ sprint هو الحد الأقصى. بعد كده انحراف البيانات الوصفية وتعارضات الـ Profiles بتكلف أكتر من فايدة الفرع.

الإصلاحات العاجلة بتشتغل إزاي في trunk-based؟

افرع من آخر commit اتصدّر، صلّح، تحقق، انشر، وبعدين ادمج فورًا في main علشان الإصلاح ما يضيعش في الإصدار الجاي.

هل النموذج بيتغير لفرق حزم 2GP؟

أيوه. افرع حسب إصدار الحزمة واختبر في scratch orgs. الفروع حسب البيئة بتنمذج مشهد مؤسسات فريق الحزم أصلًا مش بيصدّر ليه.