إزاي تحوّل Salesforce CLI عمل الـ admin إلى كود قابل للتكرار

تكمن أهمية Salesforce CLI (sf) في أنها تنقل مصدر الحقيقة للـ org من النقرات داخل Setup إلى ملفات يستطيع الفريق قراءتها ومراجعتها وكتابة سكربتات لها. هذا التحول الواحد هو ما يفصل بين حل يعمل بالصدفة وحل يظل قابلًا للصيانة مع نمو الفريق والـ org.

تنحرف معظم الـ orgs عن مسارها لأن التغييرات لا توجد إلا في سجل نقرات من قام بها. يُعدَّل permission set يدويًا، وتُضبط validation rule، وبعد ستة أشهر لا أحد يتذكر السبب. الـ CLI لا تصلح الناس، لكنها تصلح السجل. كل أمر تشغّله يعمل على ملفات metadata داخل مجلد مشروعك، فيصبح كل تغيير قابلًا للمقارنة والمراجعة والتراجع، تمامًا مثل كود التطبيقات.

ما الذي يغيره التطوير القائم على المصدر فعلًا؟

التطوير القائم على المصدر يعني أن ملفاتك المحلية هي المرجع، وليس الـ org. تسترجع الـ metadata باستخدام sf project retrieve start، وتعدّلها في IDE مع فحص حقيقي للصياغة، ثم تعيدها باستخدام sf project deploy start. يصبح الـ org هدفًا تنشر إليه، لا مكانًا تتراكم فيه الإعدادات بهدوء. وبالنسبة لفريق هندسة المنتجات، هذا هو الفرق بين تتبع "ما الذي تغير" بسؤال الزملاء وتتبعه بقراءة commit.

إزاي تقلل scratch orgs المخاطر أثناء البناء؟

الـ scratch org بيئة Salesforce كاملة يمكن التخلص منها، تُعرَّف في ملف JSON وتُنشأ بأمر واحد. ولأنها مؤقتة، لا يعود المهندسون يخشون الاختبار فيها. أنشئ scratch org، وادفع إليها feature branch، وشغّل حالة الاختبار المدمرة التي كنت تخشاها، ثم احذفها، دون أي خطر على أي sandbox مشترك. الفرق التي تعتمد هذه العادة تكتشف حالات حدّية أكثر قبل أن يصل الكود إلى بيئة مشتركة، لأن الاختبار الشامل يكاد لا يكلف شيئًا.

تبدو الدورة المعتادة هكذا

• أنشئ scratch org من ملف تعريف مخصص للميزة التي تبنيها
• ادفع المصدر وحمّل مجموعة بيانات صغيرة وممثلة
• شغّل اختبارات Apex والفحوص اليدوية على هذا الـ org المعزول
• احذف الـ scratch org بعد دمج الـ branch

هل يمكن للـ CLI أن تحل محل عمل الـ admin اليدوي؟

جزء كبير منه بشكل مفاجئ، نعم. أي شيء تكرره يدويًا في Setup مرشح لسكربت مبني على أوامر sf: إعادة تعيين permission sets بعد الإصدار، أو تحميل مجموعة بيانات اختبار ثابتة باستخدام sf data import tree، أو مراجعة أي profiles لديها إعداد field-level security معين. كتابة سكربتات لهذه المهام تحقق أمرين لا تحققهما العملية اليدوية: تصبح الخطوة متطابقة في كل مرة، ويستطيع مهندس مبتدئ تشغيلها بأمان دون معرفة متوارثة.

هذا مفيد بشكل خاص في الحلول التي تخفي تعقيدًا حقيقيًا، مثل منطق التكامل المخصص أو حزمة مُدارة لها namespace تحتاج إلى حماية. تتيح لك scratch orgs ذات الـ namespace التحقق من سلوك الحزمة في بيئة تشبه الإنتاج فعلًا، بدلًا من اكتشاف تعارضات الـ namespace بعد الإصدار.

ماذا تضيف إضافات sf إلى الأدوات؟

الـ CLI قابلة للتوسعة عبر plugins، فلا تقتصر الفرق على الأوامر المدمجة. توجد plugins للتحليل الثابت للكود، ورسم الاعتماديات بين الحزم، وعمليات البيانات المجمعة التي كانت ستعني كتابة سكربتات لمرة واحدة يدويًا. والـ plugin الذي تتم صيانته جيدًا يكون عادةً أسرع وأكثر موثوقية من بناء أداة مكافئة داخليًا، كما يبقي سير العمل داخل عادة سطر الأوامر الموجودة لدى مهندسيك.

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

FAQ

هل أحتاج إلى خبرة DevOps لاستخدام Salesforce CLI؟

لا. الأوامر الأساسية، مثل إنشاء scratch org أو نشر المصدر، في متناول أي مطور أو admin تقني مستعد للعمل من سطر الأوامر.

هل الـ scratch org هو نفسه الـ sandbox؟

لا. الـ scratch orgs مؤقتة وتُعرَّف بملف إعدادات وتستمر عادةً لأيام، بينما الـ sandboxes نسخ أطول عمرًا من الإنتاج تُستخدم في staging وQA.

هل تستطيع Salesforce CLI إدارة الكود والإعدادات معًا؟

نعم. تسترجع وتنشر أي نوع من الـ metadata، بما في ذلك Apex ومكونات Lightning والـ flows وpermission sets وتعريفات الكائنات، وليس الكود فقط.

ما أسرع طريقة للبدء باستخدامها بشكل جيد؟

اختر مهمة يدوية متكررة واحدة، مثل تعيين permission sets بعد الإصدار، واكتب لها سكربتًا أولًا. الانتصارات الصغيرة الحقيقية تبني العادة أسرع من إعادة هيكلة سير العمل كله.