كيفية بناء Salesforce CI/CD Pipeline باستخدام GitHub Actions

تطور Salesforce development كثيرا منذ أيام دفع التغييرات يدويا عبر Change Sets. ومع نمو الفرق وزيادة عدد releases، تتحول deployments اليدوية بسرعة إلى bottleneck.

هنا يأتي دور CI/CD (Continuous Integration and Continuous Delivery). فالـ pipeline الجيد يحقق validate وtest وpromote للتغييرات تلقائيا من development إلى production.

في هذا الدليل نوضح كيف تعمل Salesforce CI/CD، وكيف تبني pipeline باستخدام GitHub Actions، ومتى تبدأ DIY automation في أن تصبح صعبة الإدارة.

لماذا CI/CD مهم في Salesforce

فرق Salesforce لا تنشر تطبيقا compiled، بل metadata وconfiguration مثل:

• Apex classes وtriggers

• Lightning Web Components

• Flows وautomation

• Profiles وpermission sets وobjects وfields وlayouts

بدون automation تظهر مشكلات مثل drift بين البيئات، dependencies ناقصة، أخطاء يدوية وضعف traceability بين work items ومحتوى release.

تعالج CI/CD pipelines ذلك عبر:

• validate للتغييرات تلقائيا

• تشغيل tests قبل deployment

• استخدام Git كمصدر للحقيقة

• promote للتغييرات المعتمدة فقط

نماذج Salesforce development

1. Org-based development

هذا ما زال النموذج الأكثر شيوعا. يعمل developers داخل sandboxes، ثم يتم retrieve للـ metadata إلى Git، وبعدها تقوم CI/CD pipeline بترقيتها عبر البيئات.

Developer Sandbox
      ↓
QA
      ↓
UAT / Staging
      ↓
Production

2. Package-based development

يستخدم package-based development حزم modular بدلا من نقل metadata كاملة ككتلة واحدة. يناسب ذلك ISVs وAppExchange partners وenterprise teams ذات workstreams متعددة.

أنماط مقترحة حسب حجم الفريق

فرق صغيرة

Developer Sandbox
      ↓
Retrieve to Git
      ↓
Pull Request validation
      ↓
Build unlocked package version
      ↓
Install in Staging / QA Sandbox
      ↓
Install same package version in Production

يعمل هذا عندما يكون الفريق صغيرا ومتناسقا، وrelease frequency عالية، وبيئة staging أو QA واحدة كافية للـ signoff.

فرق نامية وكبيرة

الفرق الأكبر تحتاج غالبا إلى QA وUAT منفصلتين. QA تتحقق من integrated source changes، بينما UAT تتحقق من release artifact الذي سيصل إلى production.

Developer Sandbox
      ↓
Feature branch
      ↓
Pull Request validation
      ↓
Merge to develop
      ↓
Deploy source to QA
      ↓
Create release branch
      ↓
Build unlocked package version
      ↓
Install package in UAT
      ↓
Install same package version in Production

ISVs وmodular packages

تبدأ ISVs غالبا بنموذج package-led. أما orgs الكبيرة فتتجه إلى modular unlocked packages مثل sales package وservice operations وcustomer onboarding وcore automation.

Branching strategy

قبل بناء pipeline، اختر كيف يتحرك العمل داخل Git. الخياران الأكثر شيوعا هما GitFlow وtrunk-based development.

GitFlow

main      → production history
develop   → integration branch
feature/* → work item branches
release/* → release candidate branches
hotfix/*  → urgent production fixes

يناسب GitFlow الفرق التي لديها QA وUAT وscheduled releases. أما trunk-based development فيناسب الفرق الصغيرة الناضجة ذات automation قوية وdeployments متكررة.

معمارية pipeline المقترحة

لأغلب فرق Salesforce النامية، النموذج العملي هو:

Developer Sandbox
      ↓
Retrieve metadata to Git
      ↓
Feature branch
      ↓
Pull Request validation
      ↓
Merge to develop
      ↓
Deploy source to QA
      ↓
Create release branch
      ↓
Build unlocked package version
      ↓
Install package in UAT
      ↓
Regression testing and signoff
      ↓
Install same package version in Production

source deploy إلى QA سريع لاختبارات integration، بينما تتحول package version إلى release artifact ثابتة للـ UAT وproduction.

package.xml مقابل source tracking مقابل Serpent workflow

الفئة	Package.xml	Source tracking + unlocked packages	Serpent workflow
النموذج	Manifest-driven deployment	Git-driven development مع package promotion	Task-driven workflow حول Git والبيئات وrelease visibility
أفضل استخدام	Hotfixes والفرق legacy	فرق حديثة تريد versioned releases	فرق تريد سرعة ورؤية وتشغيل أسهل
Dependencies	يدوية	أفضل، لكنها تحتاج discipline	مدعومة بـ metadata analysis وworkflow logic
التعاون	يدوي غالبا	Git-centric ومناسب للمطورين	مناسب للمطورين وadmins وtesters وrelease managers

استخدام package.xml وsource tracking

package.xml هو manifest التقليدي الذي يحدد metadata المطلوب retrieve أو deploy لها.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <members>AccountService</members>
    <name>ApexClass</name>
  </types>
  <version>61.0</version>
</Package>

يمنحك تحكما صريحا، لكنه يدوي وسهل أن يفوّت dependencies ويصعب مع releases الكبيرة.

Source tracking يقارن تغييرات org مع local source:

sf project retrieve start
sf project deploy start

في أغلب الفرق الحديثة، استخدم source tracking أثناء development وunlocked packages أثناء release promotion.

اختيار feature-level changes بأمان

تحتوي sandbox غالبا على تغييرات متعددة. النمط الآمن هو retrieve لكل شيء، ثم اختيار components الخاصة بميزة واحدة فقط وcommit لها في feature branch.

sf project retrieve start
git status
git add force-app/main/default/classes/PricingService.cls
git add force-app/main/default/triggers/OpportunityTrigger.trigger
git commit -m "Feature: pricing approval flow"

مع Serpent يصبح ذلك أسهل لأن work items وmetadata selection وdependency analysis موجودة في workflow واحد.

Delta deployments مقابل full branch deployments

Delta deployments مفيدة لـ PR validation السريعة والميزات الصغيرة المعزولة.

sf sgd source delta \
  --to HEAD \
  --from origin/develop \
  --output-dir delta \
  --generate-delta

sf project deploy validate --source-dir delta --test-level RunLocalTests
sf project deploy start --source-dir delta

Full deployments أفضل مع destructive changes وrevert commits وإعادة ضبط drift في البيئات المشتركة.

sf project deploy start --source-dir force-app

Unlocked packages من أجل release versioning

تجعل unlocked packages releases أكثر وضوحا: يتم promote لـ versioned artifact بدلا من metadata متفرقة. هذا يحسن traceability وUAT-to-production promotion وخطة rollback.

sf package create --name SalesApp --package-type Unlocked --path force-app
sf package version create --package SalesApp --wait 20 --installation-key-bypass
sf package install --package 04tXXXXXXXXXXXX --target-org myUATOrg --wait 20
sf package install --package 04tXXXXXXXXXXXX --target-org myProdOrg --wait 20

بناء GitHub Actions pipeline

GitHub Actions خيار مناسب للفرق التي تريد فهم mechanics وبناء CI/CD foundation داخل repository. يتم تعريف workflows كملفات YAML بجانب الكود.

feature/*   → developer work item branches
develop     → deployed to QA
release/*   → package version build
main        → production history
hotfix/*    → urgent production fixes

name: Salesforce CI/CD

on:
  pull_request:
    branches: [develop]
  push:
    branches:
      - develop
      - 'release/*'
  workflow_dispatch:
    inputs:
      package_version_id:
        required: false

env:
  PROJECT_DIR: force-app
  QA_ALIAS: qa
  UAT_ALIAS: uat
  PROD_ALIAS: prod
  PACKAGE_NAME: SalesApp

jobs:
  pr-validate:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install @salesforce/cli --global
      - run: sf plugins install sfdx-git-delta
      - run: echo "${{ secrets.SF_JWT_KEY_QA }}" > server.key
      - run: |
          sf org login jwt \
            --client-id ${{ secrets.SF_CLIENT_ID_QA }} \
            --jwt-key-file server.key \
            --username ${{ secrets.SF_USERNAME_QA }} \
            --instance-url ${{ secrets.SF_INSTANCE_URL_QA }} \
            --alias $QA_ALIAS
      - run: |
          sf sgd source delta --to HEAD --from origin/develop --output-dir delta --generate-delta
          sf project deploy validate --source-dir delta --target-org $QA_ALIAS --test-level RunLocalTests

في production ستضيف عادة jobs منفصلة لـ deploy to QA وpackage version build وinstall in UAT ثم manual promotion إلى production.

Connected App وJWT authentication

1. أنشئ Connected App في Salesforce App Manager.

2. اضبط callback URL على http://localhost:1717/OauthRedirect.

3. اختر OAuth scopes مثل api وrefresh_token, offline_access.

4. ارفع certificate واحفظ private key في GitHub Secrets.

openssl genrsa -out server.key 2048
openssl req -new -x509 -days 1825 -key server.key -out server.crt

أخطاء شائعة وحلول

Error	السبب المحتمل	الحل
INVALID_LOGIN	JWT key أو client ID غير صحيح	راجع secrets وتأكد من عدم وجود trailing newlines.
INSUFFICIENT_ACCESS	Connected App permissions	راجع scopes وتفعيل التطبيق للـ integration user.
Tests failing on deploy	Code coverage أقل من 75%	شغّل sf apex run test محليا وحسّن coverage.

الخلاصة

Salesforce DevOps لا يتعلق بأداة واحدة أو pipeline مثالية واحدة. المهم هو عملية موثوقة تجعل Git source of truth، وتحقق validate تلقائي، وتجعل releases versioned وtraceable.

GitHub Actions يساعد الفرق على فهم automation من الداخل. ومع تعقّد Salesforce environments، تساعد أدوات مثل Serpent على الحفاظ على السرعة مع control وvisibility وrelease confidence.