كيف تملأ بيئة Salesforce sandbox ببيانات واقعية

الإجابة باختصار: تعبئة بيئة sandbox في Salesforce بشكل صح هي تلات مهام مش مهمة واحدة. اسحب شريحة من الإنتاج واعية بالعلاقات بدل ما تسحب عدد سجلات، حمّلها من الأب للابن باستخدام معرفات خارجية ثابتة عشان نفس المجموعة تتحمّل تاني، وأخفِ البيانات الحساسة بطريقة حتمية عشان البيانات تفضل تتصرف زي البيانات الحقيقية. وبعدين خزّن تعريف التعبئة في نظام الإصدارات جنب الـ metadata، لأن اللي بيقتل مجموعات التعبئة مش أول تحميل، ده تغيير المخطط بعد تلات دورات تطوير.

يعني إيه sandbox seeding؟

التعبئة هي نسخ مجموعة فرعية من سجلات الإنتاج لبيئة أدنى، عشان الـ org يكون فيها بيانات واقعية للتطوير والاختبار، مع إخفاء القيم الحساسة قبل ما تنزل. دي مشكلة بيانات مش مشكلة metadata: تحديث الـ sandbox بيجيب الإعدادات، وفي أغلب الحالات بيسيبك مع org فاضية أو غير قابلة للاستخدام.

أنهي بيئات محتاجة تعبئة فعلًا؟

اللي ما بتنسخش البيانات لك. حسب توثيق Salesforce عن تراخيص الـ sandbox وحدود التخزين: Developer (200 ميجابايت) وDeveloper Pro (1 جيجابايت) بينسخوا الـ metadata بس وبيتحدّثوا كل يوم، ودول اللي بتعبّيهم. Partial Copy (5 جيجابايت، كل 5 أيام) بتجيب عينة محددة بقالب وإنت بتسد الفراغات. Full (بحجم الإنتاج، كل 29 يوم) بتجيب كل حاجة، وعشان كده الإخفاء هناك بيبقى أهم. والـ scratch orgs بتبدأ فاضية دايمًا، فالتعبئة عليها إلزامية.

إزاي تختار شريحة واعية بالعلاقات؟

الغلطة الشائعة هي الاختيار بالحجم: خد 500 Account و500 Contact واتمنى إنهم مربوطين ببعض. مش هيبقوا كده، وفريق الاختبار هيقضي أسبوع بيبني السجلات اللي اتوعد بيها.

اختار بـالرسم البياني للعلاقات بدل كده، وابدأ من مجموعة صغيرة من السجلات الجذرية:

1. اختار الجذور بوعي. من عشرين لخمسين Account بيغطوا مع بعض أنواع السجلات والعملات والدول والمناطق والحالات الحدية. عميل ضخم، وعميل جديد تمامًا، وواحد عنوانه ناقص.
2. انزل للأبناء. Contacts وOpportunities وبنود الأسعار وCases والكائنات المخصصة وكائنات الربط بينهم.
3. اطلع تاني عبر الـ lookups. لو الـ Opportunity بتشاور على Pricebook أو Campaign أو عقد مخصص، الآباء دول لازم ييجوا، وإلا الإدخال هيفشل.
4. خد البيانات المرجعية لوحدها. المنتجات وبنود قوائم الأسعار وسجلات الإعداد نسخة كاملة من جدول صغير، مش شريحة من رسم بياني.

بضع مئات من السجلات المترابطة كويس بتغلب مئة ألف سجل مفكك في كل غرض ما عدا اختبار الأداء.

بأي ترتيب لازم السجلات تتحمّل؟

ترتيب اعتمادية صارم، الآباء قبل الأبناء، وكل كائن مفتاحه حاجة ثابتة.

• ما تنقلش معرفات Salesforce بين الـ orgs أبدًا. هي ما بتعيشش. حط حقل نصي كمعرف خارجي على كل كائن بتعبّيه، املاه من السجل الأصلي، واعمل upsert عليه. كده التحميل يبقى قابل للتكرار: تشغّله مرتين فيحدّث بدل ما يكرر.
• عالج المراجع الدائرية على مرحلتين. الـ lookups الذاتية زي Account.ParentId، والأزواج اللي كل واحد بيشاور على التاني، ما ينفعش تتحل في إدخال واحد. حمّل السجلات والـ lookup فاضي، وبعدين شغّل مرحلة تانية بتملا الـ lookup بس.
• اعمل mapping للملكية. حقل Owner وأي lookup على User مش هيتحل: أسماء المستخدمين في الـ sandbox بتتزود عليها لاحقة وممكن مستخدمي الإنتاج ما يكونوش موجودين. حوّلهم قبل التحميل.
• كائنات الربط في الآخر. ما تحمّلش كائن ربط غير لما يكون الاتنين الأساسيين موجودين.
• تجاوز الأتمتة بدل ما تعطّلها. الـ triggers والـ flows وقواعد التحقق والتكرار كلها بتشتغل أثناء التحميل. مفتاح تجاوز بتقراه الأتمتة أحسن من إنك تنشر تعطيلات جوه الـ org.

إزاي تخفي البيانات من غير ما تبوظ فايدتها؟

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

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

Salesforce بتوفر Anonymize for Salesforce، وGearset وOdaseva وFlosum بيقدموا أدوات تعبئة بإخفاء مدمج. أيًا كان اللي بتستخدمه، قواعد الإخفاء لازم يعتمدها مرة، كتابةً، المسؤول عن حماية البيانات.

إيه اللي بيحصل لما المخطط يتغير؟

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

تعامل مع مجموعة التعبئة كأنها كود مصدري:

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

في Serpent، عملية البيانات إجراء أصيل في الـ pipeline مش شغل يدوي، وده اللي بيخلي تشغيل التعبئة يعيش في نفس الـ pipeline بتاع النشر اللي بيدعمه.

وأخيرًا اربط الإيقاع بإصداراتك: كل دورة لبيئات التطوير، وكل جولة اختبار لبيئة القبول، ودايمًا بعد أي تحديث. ولأن التحميل قابل للتكرار ومخزن في نظام الإصدارات، دي تشغيلة pipeline مش مشروع. أدلة أكتر عن Salesforce DevOps.

FAQ

قد إيه من البيانات المفروض تبقى في sandbox معبّاة؟

القدر اللي يغطي كل نوع سجل وكل مسار وكل حالة حدية، وده عادةً بضع مئات من السجلات المترابطة. الحجم بيهم بس لما تختبر الأداء.

ما ينفعش أستخدم Data Loader وخلاص؟

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

هل تحديث الـ sandbox بيحافظ على البيانات المعبّاة؟

لأ. التحديث بيستبدل الـ sandbox، فأي حاجة عبيتها بتضيع. اعتبر إعادة التعبئة خطوة ثابتة بعد كل تحديث.