Destructive Changes
عمليات نشر Salesforce التي تزيل بيانات وصفية، تُتابَع بشكل منفصل عن التغييرات الإضافية بحيث تبقى عمليات الحذف مقصودة.
التعريف
الـ destructive changes هي عمليات نشر في Salesforce تزيل بيانات وصفية، مثل الحقول والكائنات وفئات Apex وما شابه، باستخدام manifest باسم destructiveChanges.xml يُنشر جنبًا إلى جنب مع، أو بدلاً من، ملف package.xml العادي. لا يمكن أن يحدث الحذف عبر نشر بيانات وصفية عادي؛ تتطلب Salesforce هذا الـ manifest المنفصل تحديدًا حتى تكون عمليات الإزالة صريحة وقابلة للمراجعة بدلاً من أن تكون أثرًا جانبيًا عرضيًا لعملية نشر عادية. تعمل عمليات النشر التدميرية بوضعين، ما قبل (الحذف قبل نشر بيانات وصفية جديدة) أو ما بعد (الحذف بعده)، وإخفاق الترتيب يمكن أن يعطل المكونات التابعة في منتصف عملية النشر. ونظرًا لأن عمليات الحذف ليست قابلة للتراجع بسهولة، تتعامل معظم الفرق مع destructive changes باعتبارها أعلى خطورة من التغييرات الإضافية، وبعض الحقول أو السجلات التي لا تزال ترتبط ببيانات ستمنع الحذف حتى تتم معالجة تلك البيانات. وينطبق الأمر نفسه على flow deployment: تمنع Salesforce إلغاء تفعيل إصدار لا يزال يحتوي على تفاعلات (interviews) متوقفة مؤقتًا. يغطي دليلنا لـ Salesforce DevOps ممارسات الإصدار الآمنة بما في ذلك التعامل مع عمليات الإزالة.
إزاي بيشتغل في Serpent
تتبّع Serpent عمليات الإزالة بنفس الطريقة التي تتابع بها أي تغيير آخر، لذا فإن مهمة تحذف حقلًا أو فئة تنتج تلقائيًا manifest صحيح لـ destructive changes، مع حل ترتيب ما قبل أو ما بعد النشر نيابةً عنك. تُشير فحوصات preflight إلى وجود مكونات أو بيانات تابعة قد تعيق عملية حذف ما، قبل تشغيل النشر في الإنتاج، لا بعده. ولأن كل إصدار يتمتع بإمكانية التراجع بنقرة واحدة (one-click rollback)، يمكن التراجع عن destructive change يتضح أنه خاطئ دون جهد استرداد يدوي. راجع إدارة الإصدارات في Serpent لمعرفة كيف يعمل التراجع وdestructive changes معًا.
ابدأ مجانًا. بدون بطاقة ائتمان، بدون تثبيت، وبدون التزام.
أنشئ الإعداد في أقل من 15 دقيقة. بدون الحاجة لتوظيف فريق DevOps.