DevOps الخاص بـ Salesforce لـ Experience Cloud
تحتاج مواقع Experience Cloud إلى تفعيل يدوي بعد عملية النشر. إليك ما يعنيه ذلك لتخطيط الإصدارات.
إيه اللي صعب نشره
تُنشر البيانات الوصفية الخاصة بـ Network وExperienceBundle والقالب الخاصة بالموقع عبر الواجهة البرمجية القياسية، لكن الموقع نفسه لا يصبح فعّالًا إلا بعد أن يقوم أحدهم بتفعيله يدويًا لاحقًا في Setup، فعملية نشر البيانات الوصفية وحدها لا تنشره. كما ترتبط عناصر الهوية البصرية وقوائم التنقل ومكوّنات القالب ببعضها بطرق قد تتعطل إذا وصلت إلى الـ org المستهدفة بترتيب اعتمادية خاطئ. تعتمد واجهات المتاجر B2B وD2C على نفس أساس LWR، مع إضافة إعدادات Commerce Cloud فوقه.
فين بيصعب الموضوع
إزاي Serpent بتساعد
يتتبع Serpent كل تغيير في Experience Cloud، سواء استبدال القوالب أو تعديلات قوائم التنقل أو الهوية البصرية، كمهمة لها سجل كامل بدلًا من فرق بيانات وصفية خام، بحيث يستطيع المراجعون رؤية ما تغيّر ولماذا قبل أن يصبح الموقع فعّالًا. اطّلع على سير العمل القائم على المهام في Serpent لمعرفة كيفية مراجعة التغييرات قبل نشرها.

إصدار نموذجي لـ DevOps الخاص بـ Salesforce لـ Experience Cloud
- أنشئ مهمة لتغيير الموقعتُجمَع تغييرات استبدال القوالب وتعديلات التنقل وتحديثات الهوية البصرية في مهمة واحدة وتُراجَع معًا، بدلًا من إرسالها كفرق بيانات وصفية خام.
- نشر تفاضلي بترتيب الاعتماديةيحدد Serpent الترتيب الذي يجب أن تصل به مكوّنات القالب والتنقل والثيم، حتى لا ينتهي الأمر بموقع نصف الإعداد في الـ org المستهدفة.
- التفعيل والتحققتأكد من أن الموقع أصبح فعّالًا في Setup بعد عملية النشر؛ يوضح سجل المهام في Serpent بدقة ما الذي تغيّر ولماذا، حتى لا يضطر المراجعون للتخمين.
- التراجع عن مكوّن واحد فقطإذا تسبب تغيير في الهوية البصرية بمشكلة، تراجع عن ذلك الجزء فقط دون المساس ببقية الإصدار.
DevOps الخاص بـ Experience Cloud، بالتفصيل
ابدأ مجانًا. بدون بطاقة ائتمان، وبدون تثبيت، وبدون التزام.
يتم الإعداد في أقل من 15 دقيقة، دون الحاجة لتوظيف مختص DevOps.
