إزاي تجهّز خط CI/CD لـ Salesforce باستخدام GitHub Actions

علشان تجهّز خط CI/CD لـ Salesforce باستخدام GitHub Actions، بتخزّن الميتاداتا بتاعتك في Git بصيغة source format، وبتصادق GitHub مع الـ org عن طريق Connected App قائم على JWT، وبتضيف workflow بيتحقّق من التغييرات عند كل pull request وبينشرها عند الدمج. الخط كله بيعيش في ملف YAML واحد جوه .github/workflows وبيشتغل على Salesforce CLI. الدليل ده بيمشي بالطريقة الحديثة (sf v2)، وبعدين بيحدد الأجزاء اللي بتتكسر بهدوء في الإنتاج. وهو جزء من مكتبة SF Guides بتاعتنا على /serpent/resources.

إيه اللي محتاجه قبل ما تبدأ؟

الخط الشغّال بيفترض إن كام حاجة موجودة أصلًا:

• مشروع بصيغة source format. الميتاداتا بتاعتك بتعيش تحت force-app بصيغة source format، ومعمولها commit في ريبو GitHub.
• Salesforce CLI v2 (sf). الأداة القديمة sfdx اتوقفت، فابنِ على sf.
• هدف للنشر. sandbox للتحقق و org إنتاج أو staging للإصدار.
• Connected App في الـ org الهدف والتوقيعات الرقمية مفعّلة، بالإضافة لمستخدم تكامل مصرّح له مسبقًا.

لو الميتاداتا بتاعتك لسه مش في Git، الهجرة دي بتيجي الأول. بنغطّي ميكانيكا الـ branching والبيئات في دليلنا المصاحب لبناء خط CI/CD لـ Salesforce باستخدام GitHub Actions.

إزاي تربط GitHub Actions بـ Salesforce بأمان؟

استخدم JWT Bearer Flow. ده headless، مش محتاج تسجيل دخول تفاعلي، وهو اللي Salesforce بترشّحه لـ CI. ولّد زوج مفاتيح، ارفع الشهادة لـ Connected App، وبعدين سجّل دخول من الـ runner بالمفتاح الخاص.

1. اعمل المفتاح والشهادة: openssl genrsa -out server.key 2048 وبعدين openssl req -new -x509 -nodes -sha256 -days 365 -key server.key -out server.crt.
2. اعمل Connected App في الـ org، فعّل Use digital signatures، وارفع server.crt.
3. خزّن server.key ومفتاح الـ consumer واسم المستخدم و instance URL كـ GitHub repository secrets، وأبدًا مش في الـ YAML.
4. صادِق على الـ runner: sf org login jwt --client-id $SF_CONSUMER_KEY --jwt-key-file server.key --username $SF_USERNAME --instance-url $SF_INSTANCE_URL --set-default-org.

الـ workflow في GitHub Actions شكله إيه؟

النمط الأساسي هو workflow واحد بسلوكين، حسب الـ event. اتحقّق عند pull request علشان مايتدمجش حاجة هتفشل؛ وانشر فعليًا لما التغيير يوصل لفرع main.

• المشغّلات: pull_request ضد main للتحقق، وpush لـ main للنشر.
• خطوة التحقق (PR): sf project deploy validate --source-dir force-app --test-level RunLocalTests --wait 30 --verbose. دي run للفحص بس، فمفيش حاجة بتتكتب في الـ org.
• خطوة النشر (الدمج): sf project deploy start --source-dir force-app --test-level RunLocalTests --wait 30 --verbose.

استخدم شرط if: على كل job علشان نفس الملف يتعامل مع الحدثين. تشغيل الاختبارات المحلية عند التحقق هو اللي بيخلّي ده بوابة حقيقية مش مجرد ختم، وهو العمود الفقري لأي خط أتمتة اختبارات Salesforce في CI جاد.

إزاي تنشر بس اللي اتغيّر؟

نشر مجلد force-app بالكامل كل مرة بطيء وبيبقى أسوأ كل ما الريبو يكبر. أداة المجتمع sfdx-git-delta بتحسب الفرق بين commit-ين وبتنتج حزمة فيها الميتاداتا اللي اتغيّرت بس:

sf sgd source delta --to HEAD --from HEAD~1 --output delta --generate-delta --source-dir force-app

بعد كده بتوجّه أمر النشر لمجلد الـ delta. بيقلل وقت النشر بشكل كبير، بس اقرأ القسم اللي جاي قبل ما تثق فيه بشكل أعمى.

إيه اللي بيكسر خط منزّل بإيدك بهدوء؟

أغلب الدروس بتنتهي عند نشر أخضر. المشاكل بتظهر بعدين، وهي السبب اللي بيخلينا نبني أدوات حوالين ده بدل ما نسيب الفرق بملف YAML خام:

• الحذف. الـ delta الساذج بينشر الإضافات والتعديلات لكن مش بيشيل المكوّنات المحذوفة. محتاج خطوة destructive-changes، وإلا الميتاداتا بتنحرف والمكوّنات القديمة بتتكدّس.
• ميتاداتا جزئية. الـ profiles وpermission sets وشوية أنواع تانية لسه بيعيشوا في ملفات كبيرة مشتركة مش بتعمل diff نضيف، فنشر الـ delta ممكن يفوّتهم أو يدهسهم.
• الصيانة عليك. كل تغيير في الـ CLI، وكل نوع ميتاداتا جديد، وكل حالة حافة بقت YAML على فريقك يصلّحها. التكلفة دي بتتراكم، وده بالظبط اللي الترقية العكسية بين البيئات بتخليه أسوأ لو كتبته بإيدك.

لو مش عايز تمتلك الخط ده للأبد، في منصة مُدارة بتتعامل مع الـ delta، والـ destructive changes، وحواف الميتاداتا الجزئية بدالك. شوف إيه اللي Serpent بيغطيه وسعره قبل ما تحط ربع وقت هندسي في واحد منزّل بإيدك.

FAQ

أستخدم sfdx ولا sf لخط Salesforce على GitHub Actions؟

استخدم sf (Salesforce CLI v2). الأداة القديمة sfdx اتوقفت ومينفعش تبقى أساس خط جديد.

ليه مصادقة JWT بدل اسم مستخدم وكلمة سر؟

JWT Bearer Flow هو headless ومش محتاج تسجيل دخول تفاعلي ولا مطالبة MFA، وهو اللي الـ CI runner بيحتاجه، وSalesforce بترشّحه للأتمتة.

إيه الفرق بين deploy validate وdeploy start؟

Validate هو run للفحص بس بيتأكد ويشغّل الاختبارات من غير ما يغيّر الـ org، مثالي عند الـ pull requests؛ وstart بيعمل النشر الفعلي عند الدمج.

محتاج sfdx-git-delta؟

لأ، بس بيستاهل أول ما النشر يبقى بطيء. بس اقرنه بخطوة destructive-changes علشان الحذف يتعالج، مش يتخطّى بهدوء.