إزاي تأتمت النشر في سيلزفورس باستخدام الـ scratch orgs

الإجابة باختصار: أتمتة النشر في سيلزفورس بالـ scratch orgs معناها إن مهمة الـ CI بتنشئ مؤسسة مؤقتة من ملف تعريف، وتثبّت الاعتماديات، وتنشر الكود، وتشغّل الاختبارات، وبعدين تمسح المؤسسة. المكوّنات هي Dev Hub، وملف تعريف scratch org، وملف sfdx-project.json، وأربع أو خمس أوامر من الـ CLI. واللي بيحدد هل الحكاية دي هتصمد مع فريق حقيقي مش السكربت، لكن حدود الـ scratch orgs نفسها.

إمتى تستخدم scratch org بدل الساندبوكس؟

الـ scratch org مؤسسة مؤقتة بتتعمل من ملف إعدادات ومقادة بالمصدر، يعني شكلها عايش في المستودع مش في دماغ حد. استخدمها لما البيئة المفروض تتعرّف بالكود وترمى بعد كده: تطوير لكل ميزة، وتحقق لكل pull request، وبناء الحزم واختبار تثبيتها.

وخلّيك على الساندبوكس لو محتاج حجم بيانات قريب من الإنتاج أو نقطة تكامل طويلة العمر. الـ scratch orgs بتقف عند حوالي 200 ميجابايت من السجلات و50 ميجابايت من الملفات، وكمان بتنتهي صلاحيتها (Salesforce Ben).

إيه اللي بيتحط في ملف التعريف؟

ملف التعريف هو المخطط. المطلوب إجبارياً هو edition بس، بقيم زي Developer وEnterprise وGroup وProfessional ونظائرها للشركاء. والمفاتيح اللي تستاهل تعرفها (دليل مطوّري Salesforce DX):

• features: مصفوفة بالمزايا الإضافية اللي عايز تفعّلها.
• settings: تفضيلات المؤسسة والمزايا بصيغة Metadata API. وفي قدرات، منها Experience Cloud، محتاجة feature و setting مطابق مع بعض.
• objectSettings: نماذج المشاركة وأنواع السجلات الافتراضية لكل كائن.
• release: يثبّت المؤسسة على إصدار سيلزفورس معيّن بدل ما تتبع الـ Dev Hub.
• sourceOrg وsnapshot: تبني من شكل مؤسسة قائمة أو من نسخة بتوقيت محدد بدل إصدار فاضي.
• hasSampleData وorgName وadminEmail وcountry وlanguage: التفاصيل الصغيرة اللي بتخلي أي عطل قابل لإعادة الإنتاج.

خلّي لكل غرض ملف تعريف لوحده. تعريف الـ CI لازم يكون أقل ما يمكن وأسرع ما يمكن، وتعريف العرض التوضيحي ممكن يشيل بيانات عيّنة. وخلط الاتنين هو بالظبط اللي بيحوّل فحص pull request لتلات دقايق انتظار.

الكود بيوصل للمؤسسة إزاي؟

الـ scratch orgs بتستخدم تتبّع المصدر، فأنت بتنشر مشروعك للمؤسسة وبتسحب التغييرات منها. في الـ CLI الحالي الأمر هو sf project deploy start للدفع وsf project retrieve start للسحب، والأوامر القديمة force:source:push وforce:source:deploy اتدمجت فيه (دليل مطوّري Salesforce DX).

والاعتماديات بتيجي من sfdx-project.json. مهمة الـ CI بتقرا منه الـ namespace واعتماديات الحزم وبتثبّتها قبل ما الكود بتاعك ينزل، وعشان كده البناء اللي بيشتغل محلياً ويفشل في الـ CI بيبقى غالباً مشكلة ترتيب اعتماديات، مش مشكلة ميتاداتا.

مهمة الـ CI بتنفّذ إيه بالظبط؟

1. سجّل الدخول للـ Dev Hub بمفتاح JWT متخزّن كسر في الـ CI. من غير أي تسجيل دخول تفاعلي.
2. أنشئ المؤسسة: sf org create scratch --definition-file config/project-scratch-def.json --alias ci، بأقصر مدة مفيدة.
3. ثبّت اعتماديات الحزم المعلَنة في sfdx-project.json.
4. انشر الكود بأمر sf project deploy start.
5. حمّل أقل بيانات الاختبارات محتاجاها، من ملف متتبَّع في المستودع.
6. شغّل اختبارات Apex وانشر النتايج، وخلّي المهمة تفشل لو التغطية أو التحققات وقعت.
7. امسح المؤسسة في خطوة بتشتغل دايماً، حتى لو الخطوات اللي قبلها فشلت.

الخطوة السابعة هي اللي الفرق بتنساها، وهي اللي بتكسر خط النشر بهدوء بعد أسبوع.

ليه خطوط الـ scratch orgs بتقع أول ما الفريق يزحم؟

هنا بتقف معظم الأدلة، وهنا بالظبط بتتكسر الخطوط الحقيقية. أربع حاجات خطّط ليها:

• حدود التخصيص. الـ Dev Hub في إصدارات Developer وEnterprise وPerformance وUnlimited بيسمح بـ6 scratch orgs في اليوم و3 نشطة في نفس الوقت (Salesforce Ben). عشر pull requests في اليوم بمؤسسة لكل واحد مش هيدخلوا في العدد ده. راجع حدودك بأمر sf org list limits قبل ما تصمم سير العمل، مش بعده.
• انتهاء الصلاحية. المدة الافتراضية 7 أيام والأقصى 30 يوم. أي بيئة هيراجعها إنسان لازم تتعمل بمدة صريحة، وإلا هتختفي في نص المراجعة.
• زمن الإنشاء. مؤسسة باردة زائد تثبيت الاعتماديات وقت ضايع في كل تشغيلة. تجمّعات المؤسسات المُسخّنة مسبقاً واللقطات موجودة بالظبط عشان تشيل التكلفة دي من المسار الحرج.
• البيانات. الـ scratch org بتبدأ فاضية. حمّلها من ملف متتبَّع بدل تصدير يدوي، وإلا اختباراتك هتنجح لأسباب محدش يقدر يعيد إنتاجها.

ولو بتوصل للسقف، الخيارات الصريحة إنك تحجز مؤسسة لكل PR للتغييرات اللي بتلمس ميتاداتا محزّمة بس، وتستخدم مؤسسة مشتركة طويلة العمر لباقي الحالات، أو تشغّل تجمّعاً جاهزاً. Serpent بيوفر scratch orgs في كل الخطط، وبيضيف تجمّع مؤسسات مُسخّنة مسبقاً في خطتَي Scale وEnterprise، فالمؤسسة بتبقى مستنية قبل ما خط النشر يطلبها.

FAQ

هل محتاج Dev Hub عشان أستخدم scratch orgs؟

أيوه. الـ scratch orgs بتتعمل مقابل Dev Hub مفعّل، وهو كمان المكان اللي بتتحسب فيه حصصك اليومية والنشطة.

هل شركات الـ ISV تقدر تبني حزمها بالطريقة دي؟

أيوه، وده المسار المعتاد. ابنِ وثبّت نسخة الحزمة في scratch org جديدة كل تشغيلة، عشان أخطاء التثبيت تظهر في الـ CI مش عند المشترك.

إيه الفرق بين org shape والـ snapshot؟

الـ shape بينسخ إعدادات مؤسسة قائمة لمؤسسة جديدة فاضية. أما الـ snapshot فبينسخ scratch org في لحظة زمنية محددة، وبما فيها اللي كان متنشر عليها.

هل كل pull request ياخد scratch org خاصة بيه؟

بس لو حصتك بتسمح. بـ3 مؤسسات نشطة، المستودع المزحوم محتاج تجمّعاً جاهزاً أو مؤسسة تحقق مشتركة.

تلاقي أدلة عملية أكتر خطوة بخطوة عن DevOps في سيلزفورس داخل مكتبة SF Guides.