sfdx-hardis وحزمة Salesforce DevOps مفتوحة المصدر: قراءة أمينة

حزمة Salesforce DevOps مفتوحة المصدر حقيقية وناضجة ومجانية، وبتغطي أكتر مما الناس فاكرة. sfdx-hardis بيحوّل واجهة أوامر سيلزفورس لخط إنتاج فعلي، و sfdx-git-delta بيحسب الفروق، و Code Analyzer بيعمل التحليل الساكن، ومنصة التكامل عندك هي اللي بتشغّل الكل. اللي مش بتديهولك: مسؤول، وسجل رسمي للحالة، وحد تكلمه الساعة اتنين بالليل. ودي هي النص اللي الفرق بتبنيه بنفسها في الآخر.

إيه هي حزمة Salesforce DevOps مفتوحة المصدر؟

تقريبًا خمس طبقات، كل واحدة بتتصان لوحدها:

• التنسيق. sfdx-hardis، طبقة مجانية ومفتوحة المصدر فوق واجهة أوامر سيلزفورس، بيقودها Nicolas Vuillamy وشركة Cloudity. بتعرّف خطوط CI/CD، ونسخ احتياطي يومي للبيانات الوصفية ومراقبة المؤسسات، وتوثيق مشروع مولَّد بالذكاء الاصطناعي. بتشتغل على GitHub و GitLab و Azure DevOps و Bitbucket، وبتتثبّت كإضافة sf أو امتداد VS Code أو صور Docker.
• حساب الفروق. sfdx-git-delta، إضافة المجتمع اللي بتحوّل فرق Git لملف package.xml وملف destructiveChanges.xml.
• بوابات الجودة. Salesforce Code Analyzer، مفتوح المصدر وأصيل في واجهة الأوامر، بيوحّد PMD و ESLint و CPD و RetireJS ومحرك تعبيرات نمطية وماسح للتدفقات ورا إعداد YAML واحد.
• البناء المعياري. sfp من flxbl، خليفة sfpowerscripts بتاعة DxAtScale، للفرق اللي بتنمذج مؤسستها كحزم.
• المنفّذ. GitHub Actions أو GitLab CI أو Azure Pipelines أو Jenkins، وهو اللي بينفّذ فعلاً.

لو اتجمّعت صح، دي خط إنتاج محترم. واللي بيقول إن Salesforce DevOps مستحيل من غير رخصة يبقى مابصّش من مدة.

sfdx-hardis بيغطي إيه بالظبط؟

أكتر من مجرد غلاف لواجهة الأوامر. تلات حاجات بارزة.

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

ثانيًا، بيتعامل مع المراقبة كشغلانة أصيلة مش أثر جانبي: النسخ الاحتياطي المجدول ومراقبة المؤسسات بيشتغلوا في مستودع منفصل بعيد عن التسليم.

ثالثًا، اتحرك بدري ناحية وكلاء الذكاء الاصطناعي. أكتر من 130 أمر عنده بيقبلوا راية --agent للتنفيذ غير التفاعلي بواسطة وكلاء البرمجة، وده قرار تصميمي استشرافي فعلاً بالنسبة لأداة مجانية.

المصدر المفتوح بيغطي إيه كويس؟

• نشر البيانات الوصفية بين المؤسسات، مع تعامل سليم مع الفروق والحذف.
• التحليل الساكن وبوابات الجودة في خط التكامل.
• النسخ الاحتياطي المجدول ومراقبة الانحراف.
• بناء الحزم للفرق اللي بتفكر بالحزم أصلاً.
• التكلفة. مفيش رخصة، ولفريق عنده مهندس متحمس ده فارق حقيقي.

لو عنق الزجاجة عندك واحدة من الخمسة دول، الإجابة الأمينة إنك غالبًا مش محتاج تشتري حاجة.

الفرق بتبني النص الناقص بنفسها فين؟

هنا الكلام بيبقى غير أمين في الاتجاهين. فخلينا نبقى محددين:

مسؤول

كل طبقة فوق دي اعتمادية إنت بتصونها. ترقيات Node، وتغييرات كاسرة في واجهة الأوامر، وإصدارات الإضافات، وصورة Docker بعدت عن الأصل. مش شغل كتير في أي شهر بعينه، وهو دايمًا نفس الشخص. ولما الشخص ده يمشي، خط الإنتاج بيبقى بيت مسكون.

سجل رسمي للحالة

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

تحكم في الوصول مش بتاع منصة التكامل

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

باب أمامي لغير المطورين

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

تسليم الحزم لشركات البرمجيات المستقلة بعد البناء

بناء حزمة 2GP مسألة محلولة. لكن معرفة أي إصدار شغال في كل مؤسسة مشترك، وحل الاعتماديات بين الحزم، وتأمين إصدار AppExchange، مش نفس المشكلة، والحزمة مفتوحة المصدر بتسيبهم لك في الأغلب.

حد تكلمه

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

مين المفروض يشغّل الحزمة مفتوحة المصدر، ومين لأ؟

شغّلها لو عندك مهندس عايز يمتلك أدوات التسليم، وفريقك مرتاح مع Git و YAML، والتدفق من مؤسسة لمؤسسة هو كل الشغل. ده وصف فرق كتير كويسة، ومش لازم يعتذروا عنه.

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

دي الفجوة اللي Serpent اتبنى عشانها: نشر قايم على التذاكر و Git شغال في الخلفية، ومراجعة كود بالذكاء الاصطناعي في كل الخطط، ومسارات إصدار أصيلة لـ 1GP و 2GP و AppExchange، وإدارة الإصدارات عبر مؤسسات المشتركين، وخادم MCP أصيل عشان الوكلاء يقودوا النشر عبر فحوصات مسبقة وموافقة بشرية. تسعير ثابت لكل شركة، وخطة مجانية لو عايز تختبر الكلام ده.

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

FAQ

sfdx-hardis مجاني؟

أيوه. مفتوح المصدر من غير تكلفة ترخيص، بتصونه Cloudity ومساهمو المجتمع، و Cloudity بتقدم خدمات احترافية مدفوعة حواليه.

sfdx-hardis يقدر يحل محل Copado أو Gearset؟

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

محتاج واجهة أوامر سيلزفورس عشان أستخدمه؟

أيوه. بيشتغل على Node.js وواجهة أوامر سيلزفورس، وبيتثبّت كإضافة sf أو امتداد VS Code أو صورة Docker.

Salesforce DevOps Center مفتوح المصدر؟

لأ. هو مجاني وأصيل في سيلزفورس، وده حاجة تانية. مفتوح المصدر معناه إنك تقدر تقرا الكود وتغيّره.

التكلفة الحقيقية للحزمة المجانية إيه؟

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