النشر التفاضلي في سيلزفورس: إزاي تنشر اللي اتغير بس

النشر التفاضلي بيبعت البيانات الوصفية اللي اتغيرت بين مرجعين في Git بس، مش المشروع كله. بتحسبه عن طريق مقارنة الـ commits، وتوليد package.xml من الفرق ده، وبعدين نشر البيان ده. الطريقة دي أسرع وأقل خطورة من النشر الكامل في نقطة معينة، وأهش منه في نقطة تانية: الحزمة الجزئية ممكن تفشل بسبب اعتماديات كانت الحزمة الكاملة بتغطيها بالصدفة.

يعني إيه نشر تفاضلي في سيلزفورس؟

النشر التفاضلي هو نشر بيانات وصفية بيانه جاي من مقارنة Git مش من شجرة الكود كلها. تلات أجزاء متحركة:

• الفرق. مرجعين في Git، عادةً فرع الميزة والفرع اللي بتدمج فيه.
• البيان. ملف package.xml فيه المكونات المضافة والمعدّلة بس، ومعاه destructiveChanges.xml فيه المحذوف والمعاد تسميته.
• النشر. عملية نشر بيانات وصفية عادية في مواجهة البيان ده.

مفيش حاجة في ده حكر على موردي DevOps. كل أداة بتقدم نشر تفاضلي، ومنها Serpent، بتعمل نسخة من نفس التلات خطوات.

إزاي تحسب الحزمة التفاضلية؟

الطريق المفتوح المصدر الشائع هو sfdx-git-delta، الإضافة اللي مدونة مطوري سيلزفورس شرحتها للمصادر غير المُحزَّمة. خد بالك إنها إضافة غير رسمية بيصونها المجتمع، فتعامل معاها كاعتمادية إنت مسؤول عنها.

1. اتأكد إن نسخة الكود في خط التكامل عندها تاريخ Git كافي. النسخة السطحية بعمق واحد مش هتعرف تقارن بفرع الأساس، وده أشهر سبب لظهور حزمة تفاضلية فاضية أو غلط.
2. ولّد البيان: sf sgd source delta --from origin/main --to HEAD --output-dir .
3. ضيف --generate-delta لو عايز الملفات المتغيرة تتنسخ جنب البيان. استخدمه بس لما --to تكون HEAD.
4. احرس نفسك من بيان فاضي. النشر بـ package.xml فاضية بيفشل، فخط الإنتاج المفروض يتخطى خطوة النشر بدل ما يقع بخطأ.
5. انشر وطبّق الحذف بعد الإضافات: sf project deploy start -x package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml
6. تحقق الأول. شغّل نفس البيان كنشر تحقق فقط على الهدف قبل النشر الحقيقي.

إيه فخاخ الاعتماديات اللي بتوقّع النشر التفاضلي؟

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

الملفات التعريفية ومجموعات الأذونات

ضيف حقل في النشر التفاضلي، وهتلاقي صلاحية الوصول ليه عايشة في الملف التعريفي، وده ملف منفصل. لو الملف التعريفي ماتغيرش، يبقى مش موجود في الفرق، والحقل هينزل في المؤسسة الهدف من غير ما حد يشوفه. وجهة الاسترجاع بتزوّد الطين بلة: سيلزفورس بترجّع إعدادات الأمان الخاصة بأنواع البيانات الوصفية المذكورة في طلب الاسترجاع بس، مع إن أذونات المستخدم ونطاقات الـ IP وساعات الدخول بترجع دايمًا. اعتبر الملفات التعريفية حاجة بتنشرها بقرار، مش حاجة الفرق بيقررها بدالك.

قوائم الاختيار وأنواع السجلات والترجمات

حذف قيمة من قائمة اختيار بيمس أنواع السجلات والترجمات اللي بتشير ليها. sfdx-hardis ضاف النشر التفاضلي مع الاعتماديات للحالة دي بالظبط، لأن الفشل غالبًا مش بيظهر في النشر التفاضلي أصلاً. بيظهر في النشر الكامل اللي بعده، بأسابيع، وفي خط إنتاج تاني.

اختبارات Apex

لو بتنشر فئة معدّلة تحت RunSpecifiedTests، لازم فئة الاختبار بتاعتها تكون موجودة في الهدف ومذكورة في قائمة الاختبارات. النشر التفاضلي اللي فيه الفئة من غير الاختبار هو فشل تغطية مستني الإنتاج.

التدفقات

حذف التدفق عن طريق destructiveChanges.xml فجوة موثّقة في المنصة. الحل البديل إنك تعطّله الأول بنشر FlowDefinition بقيمة activeVersionNumber تساوي صفر.

البيانات الوصفية اللي ساكنة في ملف واحد

التسميات المخصصة وسير العمل وقواعد المطابقة بتحشر أعضاء كتير في ملف واحد. تغيير سطر واحد بيعلّم الملف كله كمتغيّر، وتضمينهم بالقوة بيحتاج تاريخ Git كامل، مش نسخة سطحية.

إعادة التسمية

Git بيشوف إعادة التسمية كحذف زائد إضافة. لو نشرتهم بترتيب غلط هتحذف مكون لسه مشار ليه، أو هتعمل نسخة مكررة. ترتيب الحذف المؤجل موجود عشان كده بالظبط.

إمتى تنشر كامل بدل تفاضلي؟

الافتراض المفيد، وهو اللي sfdx-hardis بيجي بيه، إن النشر التفاضلي يبقى لفروع الميزات اللي بتدمج في فرع مشترك، والنشر الكامل يبقى بين البيئات المشتركة. المنطق إنك كل ما تطلع لفوق في خط الإنتاج، كل ما احتمال إن الهدف بعد عن التحكم في الإصدار يزيد، والنشر التفاضلي بيفترض إن التحكم في الإصدار هو الحقيقة.

روح للنشر الكامل لو أي واحدة من دول صحيحة:

• المؤسسة الهدف اتعملها تعديلات يدوية من آخر نشر.
• التغيير بيمس الملفات التعريفية أو مجموعات الأذونات أو إعدادات المشاركة بشكل واسع.
• بتنقل بين بيئتين طويلتي العمر مش بتدمج ميزة.
• بتتعافى من نشر فشل أو اتطبّق نصه.

سيب لنفسك تجاوز يدوي. sfdx-hardis بيستخدم علامة NO_DELTA في عنوان الـ commit، ودي فكرة كويسة تقلدها مع أي أدوات: اللي عارف إن التغيير خطر لازم يقدر يفرض نشر كامل من غير ما يعدّل إعدادات خط الإنتاج.

خط الإنتاج التفاضلي الآمن شكله إيه؟

1. نسخة كاملة، أو على الأقل عمق يكفي للوصول لقاعدة الدمج.
2. ولّد البيان واطبعه في سجل البناء، عشان حد بني آدم يقرأ اللي هيتشحن.
3. تخطَّ بهدوء لما البيان يبقى فاضي.
4. نشر تحقق فقط، وبعدين النشر الحقيقي، والتغييرات المدمرة في الآخر.
5. نشر كامل بجدول، أسبوعي أو مع كل إصدار، عشان تمسك الانحراف اللي النشر التفاضلي عمره ما لمسه.

الخطوة الأخيرة دي هي اللي الفرق بتسيبها، وهي بالظبط اللي بتمسك فشل قوائم الاختيار والترجمات قبل ما يبقى فيه إصدار على المحك. فيه أدلة تسليم تانية لسيلزفورس في مكتبة SF Guides عندنا.

FAQ

النشر التفاضلي أأمن من النشر الكامل؟

هو أسرع وبيمس أقل، وده بيقلل نطاق الضرر. لكنه مش أأمن بطبيعته، لأن الحزمة الجزئية ممكن تفوّت اعتمادية كانت الحزمة الكاملة هتشيلها.

محتاج sfdx-git-delta عشان أعمل نشر تفاضلي؟

لأ. هو الطريق المفتوح المصدر الأشهر، وهو غير رسمي وبيصونه المجتمع. معظم منصات Salesforce DevOps التجارية بتحسب الفرق بالنيابة عنك.

ليه الحزمة التفاضلية فاضية في خط التكامل ومش فاضية محليًا؟

غالبًا نسخة سطحية. نسخة الكود في خط التكامل محتاجة تاريخ Git كافي توصل بيه للـ commit اللي بتقارن منه.

إزاي أحذف بيانات وصفية في نشر تفاضلي؟

عن طريق destructiveChanges.xml، ويتطبّق بعد الحزمة المضافة. التدفقات هي الاستثناء: عطّلها الأول بتغيير في FlowDefinition.

الملفات التعريفية المفروض تكون جزء من الفرق؟

انشرها بقرار مش بترك القرار للفرق. ملف الملف التعريفي بيحمل إعدادات أنواع البيانات الوصفية اللي كانت في الاسترجاع بس، فالملف التعريفي اللي جاي من فرق نادرًا يكون اللي إنت قاصده.