استراتيجيات فروع Git لفِرَق Salesforce: دليل عملي

الإجابة باختصار: أغلب فِرَق Salesforce الأفضل تبدأ بنموذج feature branch، اللي فيه main بيعكس الإنتاج دايمًا وكل تغيير بيعيش على branch قصير العُمر خاص بيه. ما تضيفش branches للبيئات أو للـ release إلا لما الـ packaging، أو مسارات release متوازية، أو فريق كبير يفرضوا كده. الجزء الخاص بـ Salesforce مش رسمة الـ Git، لكنه ربط كل branch طويل العُمر بـ sandbox والتعامل مع تعارضات دمج الميتاداتا.

استراتيجية الـ branching هي المكان اللي فيه أغلب إعدادات Salesforce DevOps بتترتّب صح أو بتنهار تحت وزنها. انسخ نموذج معقّد مش محتاجه وكل مطوّر هيدفع ضريبة يومية؛ اختار واحد يناسب إيقاع الإصدار عندك وهتلاقي Git بيبعد عن طريقك.

يعني إيه استراتيجية branching في Git، وليه Salesforce مختلفة؟

استراتيجية الـ branching هي مجموعة القواعد اللي بيها فريقك بيعمل branches ويدمجها ويرقّيها. على Salesforce بتبقى أثقل لتلات أسباب: مصدر الحقيقة عندك ميتاداتا تصريحية (XML) جنب الـ Apex، وبيئاتك عبارة عن orgs وsandboxes مش سيرفرات، ومش هتقدر تعمل compile للمشروع كله محليًا، فالتحقق بيتم في مواجهة org. ده بيخلّي فيه سؤالين لا مفر منهم بتأجّلهم الأنظمة التانية: أنهي branch بيمثّل أنهي sandbox، وإزاي تحل التعارضات في ملفات زي الـ profiles والـ flows اللي ناس كتير بتلمسها. Salesforce DevOps Center، المتاح للجميع دلوقتي، بيعتمد على ده وبيتعامل مع GitHub أو Bitbucket كمصدر وحيد للحقيقة.

أنهي استراتيجيات branching في Git بتستخدمها فِرَق Salesforce فعلًا؟

أربع أنماط بتغطّي تقريبًا كل فريق:

• Feature branch (GitHub Flow). main جاهز للإصدار دايمًا؛ كل تغيير بيتفرّع من main ويرجع له عن طريق pull request. الأبسط في التشغيل، وأفضل خيار افتراضي لأغلب الفِرَق.
• Branch لكل بيئة. branch طويل العُمر لكل org (dev، uat، main)، بيترقّى بالدمج لأعلى. بديهي وسهل تتخيّله، بس معرّض للانحراف لما الـ hotfix يتخطى مرحلة.
• Release branch. release/x قصير العُمر متفرّع من main لتثبيت إصدار بينما الشغل الجديد مستمر. مفيد لما بتجمّع التغييرات في إصدارات مجدولة.
• Gitflow. branches للـ feature والـ develop والـ release والـ hotfix مع بعض. قوي للإصدارات المتوازية وحزم الـ ISV، وتقيل لفريق بإنتاج واحد.

إزاي تربط الـ branches بالـ sandboxes بتاعة Salesforce؟

اربط كل branch طويل العُمر بـ sandbox تناسب مهمته، وسيب حدود الـ refresh هي اللي تحدد الشكل. Salesforce بيحدّث sandboxes نوع Developer وDeveloper Pro يوميًا، وPartial Copy كل 5 أيام، وFull كل 29 يوم، فالـ Full sandbox اللي بتستخدمها للـ UAT النهائية ما تنفعش تبقى هدف التكامل السريع. ربط شائع وبأقل احتكاك:

1. branches الـ feature/* لـ sandboxes نوع Developer أو Developer Pro للبناء.
2. branch تكامل لـ sandbox نوع Partial Copy للاختبار المجمّع.
3. main بيتحقق في مواجهة Full sandbox قبل ما يوصل الإنتاج.

الميكانيكا الكاملة موجودة في إزاي تربط branches الـ Git بالـ sandboxes بتاعة Salesforce.

إزاي تتعامل مع تعارضات دمج الميتاداتا؟

هنا الـ branching في Salesforce بيوجع فعلًا. الـ profiles والـ permission sets والـ flows ملفات XML كبيرة بتلمسها تغييرات كتير، فالدمج الساذج بيفسدها. خلّي الـ branches قصيرة العُمر عشان تتباعد أقل، قسّم الـ profiles لـ permission sets، واستخدم merge driver واعي بـ Salesforce بيفهم الـ XML بدل ما يدمجه سطر بسطر. بنشرح ده في إزاي تعدّ merge driver لـ Git واعي بـ Salesforce.

أنهي استراتيجية branching المفروض فريقك يختارها؟

طابق النموذج مع إيقاع الإصدار عندك، مش مع الهيكل الإداري:

• org إنتاج واحدة، وإصدارات متكررة: feature branch من main. ما تضيفش حاجة تانية.
• إصدارات مجدولة مع فترة تجميد: feature branches زائد release branch.
• ISV أو أكتر من نسخة مدعومة: Gitflow، أو نموذج package لكل branch.

لما خيارين يبانوا متساويين في الصلاحية، اختار الأبسط؛ تقدر دايمًا تترقّى بعدين. قاعدة القرار بتاعتنا لاستراتيجيات branching في Git بتحوّل ده لسؤال واحد تقدر تجاوبه في اجتماع. وعشان أي نموذج هيسلّم في الآخر تغيير وحش، اربطه بخطة لـ التراجع عن عمليات نشر Salesforce الفاشلة.

الأدوات بتيجي فين؟

الاستراتيجية هي Git؛ والأداة بتأتمت الترقية على طولها. منصات زي Copado وGearset وAutoRABIT كل واحدة بتفترض نموذج branching، فاختيار نموذجك الأول بيمنعك إنك تتحشر في نموذج حد تاني. لو بتنقل إعداد branching موجود لـ pipeline جديد، دليل الهجرة بتاعنا بيشرح إزاي تنقل branches بتاعتك من غير إعادة كتابة. ولمزيد من إرشادات Salesforce DevOps، اتصفح SF Guides بتاعتنا.

FAQ

إيه أفضل استراتيجية branching في Git لـ Salesforce؟

لأغلب الفِرَق، نموذج feature branch بـ main جاهز للإصدار دايمًا. هو الأبسط في التشغيل وبيتوسّع لحد ما الـ packaging أو الإصدارات المتوازية يفرضوا حاجة أعقد.

هل كل sandbox في Salesforce لازم يبقى ليها branch خاص؟

بس الـ branches طويلة العُمر المفروض تترتبط بـ sandboxes. الـ feature branches قصيرة العُمر بتتشارك sandboxes نوع Developer؛ خلّي Partial Copy وFull للتكامل والتحقق النهائي.

هل Gitflow خيار كويس لـ Salesforce؟

Gitflow يناسب الـ ISVs والفِرَق اللي بتصون أكتر من نسخة في نفس الوقت. لـ org إنتاج واحدة، عادةً بيضيف branches أكتر مما يحتاجه إيقاع الإصدار.

إزاي أتجنّب تعارضات دمج الـ profiles؟

خلّي الـ branches قصيرة العُمر، وفضّل الـ permission sets على الـ profiles، واستخدم merge driver واعي بـ Salesforce عشان الـ XML يتدمج بالبنية مش بالسطر.