إزاي تربط فروع Git بـ sandboxes الخاصة بـ Salesforce

ربط فروع Git بـ sandboxes الخاصة بـ Salesforce معناه إنك تقرر أنهي فرع هو مصدر الحقيقة لكل بيئة، عشان التغيير يتحرك من التطوير للإنتاج عن طريق merges متراجَعة بدل نشر من org لـ org. الفروع طويلة العمر بتترّبط بالـ sandboxes الدائمة؛ وفروع الميزات قصيرة العمر بتترّبط بـ scratch orgs وdeveloper sandboxes. لو الربط صح، الترقية بتبقى مجرد merge. ولو غلط، بترث دمج فوق دمج وانحراف صامت.

الدليل ده عن ميكانيكا الربط، مش عن اختيار النموذج. لو لسه بتقرر بين trunk-based وGitFlow وفرع لكل بيئة، ابدأ بـ استراتيجيات فروع Git لفرق Salesforce: قاعدة اختيار واضحة، وبعدين ارجع هنا تربطه بالـ orgs بتاعتك.

أنهي نوع sandbox بيسند أنهي فرع؟

الفرع مبيبقاش حقيقي إلا لما يكون فيه org تنشره وتختبره فيها. طابق كل فرع بنوع الـ sandbox اللي يناسب غرضه وإيقاع تحديثه:

• فرع الميزة بـ scratch org أو Developer sandbox. قابل للرمي، بيتعمل مع كل تذكرة، وبيترمي عند الدمج.
• فرع integration بـ Developer Pro sandbox، اللي شغل الميزات بينزل فيها ويتختبر سوا.
• فرع UAT بـ Partial Copy أو Full sandbox، عشان مستخدمي الأعمال يختبروا على بيانات ممثِّلة.
• فرع main بالإنتاج، محمي دايمًا ومبيتحدّثش إلا عن طريق merge متراجَع.

إيقاع التحديث بيحدّد كام فرع طويل العمر تقدر تسنده فعلًا. Salesforce بتحط حدود دنيا للتحديث: يوم واحد لـ Developer وDeveloper Pro، وخمس أيام لـ Partial Copy، و29 يوم لـ Full، فالفرع اللي مش قادر تحدّثه هو فرع مش قادر تثق فيه.

إزاي الترقية بتتحرك بين الفروع؟

الترقية merge، مش إعادة نشر. التغيير بيبدأ على فرع ميزة، وبعدين بيطلع في السلسلة كل ما يعدي بوابة:

1. اعمل فرع ميزة، وطوّر على الـ scratch org أو الـ Developer sandbox بتاعته.
2. افتح pull request للـ integration branch؛ وعند الدمج انشر على الـ integration sandbox.
3. ادمج integration في فرع UAT عشان اعتماد الأعمال في الـ Partial Copy أو Full sandbox.
4. ادمج UAT في main؛ والنشر للإنتاج بيبقى نفس الميتاداتا اللي عدّت UAT خلاص.

القاعدة اللي بتوفر أكبر وجع: ماتخليش فرع مرتبط بالإنتاج يقبل commit مباشر أبدًا. كل حاجة بتوصله عن طريق merge متراجَع، فتاريخ الفرع بيبقى كمان تاريخ النشر بتاعك.

إزاي source tracking بيخلي الفرع وأورجه متزامنين؟

الـ source tracking بيسجّل أنهي ميتاداتا اتغيرت في الـ sandbox، فبتسحب التغييرات دي في الفرع بدل ما تخمّن retrieve كامل. انشر من git للأورج المرتبطة، وسيب source tracking يعلّم على أي حاجة الأدمن غيّرها مباشرة في الأورج دي. اللوب ده بيخلي الفرع مصدر الحقيقة ويمنع الأورج والفرع إنهم ينحرفوا عن بعض في صمت.

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

إيه أخطاء الربط الشائعة؟

• فرع طويل العمر لكل developer sandbox. كل فرع طويل العمر زيادة هو هدف دمج تاني بينحرف. خلي فروع الميزات قصيرة وقابلة للرمي.
• النشر من org لـ org وتسميته ترقية. لو الفرع مش هو اللي بتنشره، تاريخ الفرع بيبطل يطابق اللي حي.
• إسناد فرع UAT بـ Developer sandbox. من غير بيانات ممثِّلة، الاعتماد بيختبر الحاجة الغلط وبيفوّت الأخطاء المرتبطة بشكل البيانات.
• السماح للأدمن بتغيير الإنتاج مباشرة. نقرة في الإنتاج عمرها ما دخلت git بتحوّل ربطك لخيال في النشرة الجاية.

خلّي الربط يفرض نفسه

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

FAQ

محتاج فرع لكل sandbox؟

لأ. اربط الفروع طويلة العمر بس بالبيئات الدائمة زي integration وUAT والإنتاج. واستخدم فروع ميزات قصيرة العمر للـ scratch وdeveloper orgs.

أنهي sandbox المفروض تسند فرع UAT؟

Partial Copy أو Full sandbox، عشان مستخدمي الأعمال يختبروا على بيانات ممثِّلة بدل org developer فاضية.

إزاي التغيير بيترقّى بين البيئات؟

عن طريق merge متراجَع من فرع للي بعده، وبعده نشر من git للأورج المرتبطة. الترقية merge، مش إعادة نشر من org.

إيه اللي بيمنع الفرع وأورجه إنهم يبعدوا عن بعض؟

source tracking مع النشر من git. الفرع بيفضل مصدر الحقيقة، وأي تغيير مباشر في الأورج بيظهر كـ diff متتبَّع تصالحه.

أنهي نموذج فروع أربطه الأول؟

اختار النموذج قبل الربط. بُص على قاعدة الاختيار بتاعتنا عشان تختار حسب حجم الفريق وتوزيع بيئات الاختبار.