Delta Deployment
نشر البيانات الوصفية التي تغيّرت منذ آخر إصدار فقط، بدلاً من الحزمة بأكملها.
التعريف
ينقل delta deployment فقط البيانات الوصفية التي تغيّرت فعليًا منذ آخر إصدار، بدلاً من إعادة نشر حزمة كاملة أو كل مكونات الـ org في كل مرة. يهم هذا لأن عمليات النشر الكاملة تستغرق وقتًا أطول، وتحمل مخاطرة أكبر لأنها تمس مكونات لم يقصد أحد تغييرها، وتجعل من الصعب معرفة ما فعله الإصدار فعليًا.
لا تحسب Salesforce الفروقات (deltas) بشكل أصلي في معظم طرق النشر؛ عادةً ما تحصل الفرق على سلوك delta إما من تتبّع المصدر (source tracking) في scratch orgs وبيئات sandbox المدعومة، أو من أدوات خارجية تقارن التزامات Git (commits) لبناء manifest يحدد ما يجب تضمينه.
يُعد تنفيذ delta deployment بشكل خاطئ، إما بإغفال تبعية كان ينبغي أن تنتقل مع تغيير ما، أو بتضمين مكونات غير ذات صلة، سببًا شائعًا لفشل عمليات النشر والتغييرات غير المقصودة في بيئة الإنتاج، وقد يتطلب أحيانًا تراجعًا (rollback) للتراجع عنها. يُجسّد OmniStudio هذه المخاطرة: فإن OmniScript الذي يُشحن دون إصدارات DataRaptor التي يستدعيها ينهار أثناء التشغيل بدلاً من أن يفشل النشر نفسه. يقارن دليلنا لـ Salesforce DevOps بين كيفية تعامل الأدوات المختلفة مع delta deployment.
إزاي بيشتغل في Serpent
تنشر Serpent فقط البيانات الوصفية التي مسّتها المهمة فعليًا، وتُتابَع تلقائيًا بدلاً من حسابها لاحقًا من فرق Git، بحيث يبقى كل إصدار محصورًا في التغييرات المقصودة. يجلب اكتشاف التبعيات المكونات التي يعتمد عليها التغيير فعليًا دون جلب بيانات وصفية غير ذات صلة، ما يبقي عمليات النشر سريعة وقابلة للمراجعة. وبالجمع مع فحوصات preflight، يصبح delta deployment هو السلوك الافتراضي بدلاً من أن يكون شيئًا يجب على الفريق إعداده. راجع إدارة الإصدارات في Serpent لمعرفة كيف تندمج عمليات delta deployment ضمن خط الأنابيب الكامل.
Delta Deployment: الأسئلة الشائعة
ابدأ مجانًا. بدون بطاقة ائتمان، بدون تثبيت، وبدون التزام.
أنشئ الإعداد في أقل من 15 دقيقة. بدون الحاجة لتوظيف فريق DevOps.