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

إصدار نموذجي لـ Salesforce DevOps لـ Commerce Cloud
- أنشئ مهمة لتغيير واجهة المتجراجمع تغيير ExperienceBundle أو بيانات LWR الوصفية مع إعدادات Commerce التي يعتمد عليها، فئة جديدة، إعداد متجر، في مهمة واحدة.
- انشر البيانات الوصفية بشكل تفاضليينشر Serpent فقط مكونات LWR والبيانات الوصفية لـ Commerce التي تغيرت، وليس نشرًا لكامل المؤسسة.
- اربط خطوة إعادة الفهرسةتعيد خطوة في خط أنابيب بدون كود فهرسة البحث وتزرع بيانات الاختبار مباشرة بعد النشر، بحيث لا يتوقف الإصدار عند "تم نشر البيانات الوصفية".
- تحقّق مقابل بيئة تجريبية متزامنةيفحص المختبِرون واجهة المتجر في بيئة تُحافظ على تزامنها مع التغيير، وليست نسخة قديمة.
Commerce Cloud DevOps، تمت الإجابة
ابدأ مجانًا. بلا بطاقة ائتمان، بلا تثبيت، بلا التزام.
الإعداد في أقل من 15 دقيقة. لا حاجة لتوظيف DevOps.
