استراتيجيات فروع Git لفرق Salesforce: إزاي تختار

باختصار: استراتيجية فروع Git هي مجموعة القواعد اللي بتقرر فين تعيش تغييرات ميتاداتا Salesforce قبل ما توصل الإنتاج. أغلب الفرق الأفضل تبدأ بنموذج feature-branch بسيط على فرع main واحد قابل للنشر دايمًا، وتضيف التعقيد بس لما إيقاع الإصدار أو حجم الفريق يفرضه. مافيش إجابة واحدة صح، بس الأنسب لإيقاعك وفريقك وإزاي فروعك بتتطابق مع الـ sandboxes.

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

استراتيجية الفروع بتحدد إزاي الشغل بيتعزل ويتراجع ويتدمج. في السوفتوير الكلاسيكي دي أرض مطروقة. Salesforce بيضيف تعقيدين: مصدر الحقيقة عندك ميتاداتا تصريحية بتتسحب من الأورجات مش كود بتكتبه في مكان واحد، وSalesforce بينصح بالتخرّج من نموذج change-set أورج-لأورج ناحية إصدارات على Git. ده بيخلّي ربط الفرع بالـ sandbox، مش نمط التفريع نفسه، هو الجزء اللي الفرق بتغلط فيه أكتر.

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

إيه أهم استراتيجيات التفريع لـ Salesforce؟

أربع أنماط بتغطي تقريبًا كل فريق Salesforce. بتبادل البساطة بالتحكم كل ما تنزل في القايمة.

نموذج feature-branch

فرع main واحد طويل العمر بيحتوي آخر ميتاداتا قابلة للنشر. كل تغيير بياخد فرع قصير العمر، يفتح pull request، ويتدمج تاني بعد المراجعة.

• الأنسب لـ: الفرق الصغيرة والمتوسطة اللي عايزة تبدأ النهاردة.
• القوة: بسيط، سريع التبنّي، بيخلّي main قابل للإصدار دايمًا.
• التكلفة: هيكلة أقل لتنسيق أكتر من إصدار متوازي.

نموذج environment-branch (فرع لكل أورج)

كل فرع بيتطابق مع بيئة Salesforce: dev وuat وmain للإنتاج. التغييرات بتترقّى بدمج السلسلة لفوق.

• الأنسب لـ: الفرق اللي نموذجها الذهني أورج-أساسه وعايزة الفروع تعكس الـ sandboxes.
• القوة: خط الأنابيب واضح؛ كل دمج ترقية.
• التكلفة: فروع البيئة طويلة العمر بتنحرف، وسحب تغيير واحد من دفعة (cherry-pick) بيبقى موجع.

GitFlow

فروع مخصصة develop وrelease وfeature وhotfix بقواعد صارمة، اتعملت لإصدارات السوفتوير المجدولة في 2010.

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

Trunk-based development

الكل بيعمل commit لـ main ورا فروع قصيرة العمر جدًا، والأتمتة هي شبكة الأمان. ده الاتجاه اللي الفرق عالية التردد بتروح ناحيته.

• الأنسب لـ: الفرق اللي عندها CI ناضج، اختبارات مؤتمتة قوية، ومسار rollback حقيقي.
• القوة: أسرع تدفّق، أصغر دفعات، أقل انحراف دمج.
• التكلفة: مبيسامحش من غير تحقق مؤتمت وrollback متظبّطين الأول.

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

طابق النمط مع واقعك، مش مع مثالية مدوّنة:

• جديد على التحكم بالإصدارات؟ feature-branch على فرع main واحد. مافيش حاجة تانية بتستاهل تعقيدها لسه.
• بتفكر بالـ sandboxes؟ environment-branch، بس خلّي الفروع قصيرة العمر قد ما تقدر وأتمِت الترقيات.
• إصدارات منظّمة على تقويم؟ GitFlow بيديك التحكّم اللي المدقّقين عايزينه.
• بتشحن يوميًا بأتمتة متينة؟ trunk-based، بمجرد ما اختباراتك وrollback يبقوا موثوقين.

العامل الحاسم نادرًا ما يكون الرسم البياني. هو إذا كانت ميتاداتك بتتدمج نضيف وإذا كان كل فرع ليه بيت في sandbox حقيقي. بنتعمّق في الربط ده في إزاي تربط فروع Git بـ sandboxes بتاعة Salesforce، وبنحط قاعدة قرار بسيطة في دليل قاعدة القرار ده.

إيه الأفخاخ الخاصة بـ Salesforce اللي بتكسر استراتيجية التفريع؟

هنا نصيحة Git العامة بتبطل تكفي. خلّي بالك من:

• ميتاداتا مبتتدمجش نضيف. الـ profiles وبعض ميتاداتا الـ XML بتطلّع diffs مشوّشة؛ فضّل permission sets وتغييرات صغيرة ومركّزة.
• فروع بيئة طويلة العمر بتنحرف. كل ما الفرع يعيش بعيد عن main أكتر، الدمج النهائي بيبقى أصعب. خليهم قصيرين أو صالحهم بكتير.
• مافيش خطة rollback. استراتيجية تفريع من غير طريقة متختبرة لعكس دمج وحش هي استراتيجية لإصدارات بطيئة وخايفة. قرِنها بمسار تعافي حقيقي، زي ما بنغطي في استراتيجيات الـ rollback للنشرات الفاشلة.
• فروع من غير sandbox. أي فرع الترقية بتستهدفه محتاج أورج يتحقق منه، وإلا خط الأنابيب مجرد مسرحية.

تقدر تتصفّح باقي الـ playbooks العملية بتاعتنا في مكتبة SF Guides. ولما تبقى جاهز تنقل خط أنابيب حقيقي بعيد عن الـ change sets، مسار الهجرة بتاعنا متبني يكون تدريجي مش إعادة كتابة دفعة واحدة.

FAQ

إيه أحسن استراتيجية فروع Git لفريق Salesforce صغير؟

ابدأ بنموذج feature-branch على فرع main واحد قابل للنشر دايمًا. هو أبسط نمط وبرضه بيديك مراجعة وتتبّع وإصدارات نضيفة.

هل GitFlow كويس لـ Salesforce؟

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

هل فروع Salesforce المفروض تتطابق واحد-لواحد مع الـ sandboxes؟

نماذج environment-branch بتعمل ده بالظبط، وده حدسي، بس خلّي الفروع قصيرة العمر عشان تتجنّب الانحراف. أي فرع بتترقّى ليه محتاج أورج حقيقي يتحقق منه.

إيه علاقة استراتيجية التفريع بالـ rollback؟

علاقة مباشرة. الفروع بتقرر إزاي التغييرات بتوصل؛ والـ rollback بيقرر إزاي بترجع في الوحش منها. استراتيجية من غير مسار rollback متختبر بتودّي لإصدارات بطيئة وحذرة.