استراتيجية البيئات
خريطة sandbox وscratch orgs واختبار القبول بما يوافق وتيرة العمل الفعلية.
CI/CD وDevOps لـ Salesforce
يتوقف الإصدار عن كونه حدثًا مرهقًا حين يصبح له مسار واضح.
نبني مسار إصدار محوكمًا لـ Salesforce: مصدر حقيقة واحد في Git، بيئات محددة، اختبارات آلية، بوابات جودة ومسار تراجع — بحيث يصل كل تغيير إلى الإنتاج بصورة متوقعة وموثقة.
مسار الإصدار
كيف ينتقل التغيير من التطوير إلى الإنتاج
يعرض المخطط المسار الكامل، من البيئة التي كُتب فيها التغيير وحتى الضوابط التي تلي الإطلاق.
Governed Release Pipeline
المصدر
من أين يبدأ التغيير
- Scratch org / sandboxتطوير معزول
- بيانات وصفية في Gitمصدر حقيقة واحد
- فرع لكل مهمةقابل للتتبع حتى المتطلب
التكامل
ما يعمل تلقائيًا
- Pull requestمراجعة إلزامية
- تحليل ثابتPMD ومعايير الكود
- اختبارات Apexتغطية وجودة
بوابات الجودة
ما يمنع الترقية
- حد أدنى للتغطيةعتبة متفق عليها
- حزمة انحدارسيناريوهات حرجة
- موافقة الأعمالاختبار قبول موثق
الإصدار
كيف نصل إلى الإنتاج
- نشر آليالأداة نفسها في كل بيئة
- بيانات البيئاتبيئات متسقة
- نافذة إصدارمجدولة ومعلنة
الضبط
ما يحدث بعد الإطلاق
- تراجع مخطططريق عودة معروف
- مراقبة وتنبيهاتعتبات محددة
- ملاحظات الإصدارتوثيق لكل نسخة
الخلفية
ما الذي يحسم النتيجة فعليًا
في معظم المؤسسات لا تنتج حوادث الإصدار عن كود رديء بل عن غياب المسار المنظم. تُجرى التغييرات مباشرة في البيئة، ولا أحد يعرف بدقة ما الذي دُفع، ولا توجد طريقة منظمة للعودة.
CI/CD في Salesforce ليس أدوات فحسب. إنه اتفاق على ما يُعد تغييرًا معتمدًا، ومن يعتمده، وأي فحوص يجب أن تنجح، وماذا يحدث عند الإخفاق.
النتيجة الصحيحة ليست مزيدًا من الأتمتة لذاتها، بل وتيرة إصدار أعلى بمفاجآت أقل، مع نسخة يمكن شرحها وإعادة إنتاجها والتراجع عنها.
مجالات العمل
ما نقوم به عمليًا
بيانات وصفية في Git
بنية المستودع والتفريع وسياسة دمج يمكن للفريق الالتزام بها.
مسار آلي
بناء واختبار ونشر عبر GitHub Actions أو Azure DevOps أو Gearset.
بوابات جودة
تغطية الاختبارات والتحليل الثابت وموافقة الأعمال كشرط للترقية.
بيانات البيئات
مجموعات اختبار متسقة دون نسخ بيانات حساسة من الإنتاج.
الإصدار والتراجع
نوافذ إصدار وملاحظات نسخة ومسار عودة محدد مسبقًا.
نموذج النضج
أين تقف المؤسسة اليوم
تقع معظم المؤسسات بين المستوى الأول والثالث، وأهم قفزة هي اعتماد Git مصدرًا للحقيقة.
| المستوى | كيف يبدو | الخطر الأساسي | الخطوة التالية |
|---|---|---|---|
| 1 — يدوي | Change sets وتعديلات مباشرة في الإنتاج | لا توثيق ولا طريق للعودة | نقل البيانات الوصفية إلى Git |
| 2 — محوكم جزئيًا | Git موجود لكن النشر يدوي | تباعد بين البيئات | أتمتة النشر |
| 3 — مؤتمت | مسار يعمل مع كل pull request | اختبارات ضعيفة تُجيز كل شيء | تحديد بوابات جودة حقيقية |
| 4 — محوكم | بوابات الجودة تمنع الترقية | تأخر الإصدارات بسبب مسار ثقيل | تركيز حزمة الانحدار |
| 5 — مستمر | إصدارات متكررة مع تراجع معروف | تراخٍ تشغيلي | مراقبة ومراجعات دورية |
1 — يدوي
- كيف يبدو
- Change sets وتعديلات مباشرة في الإنتاج
- الخطر الأساسي
- لا توثيق ولا طريق للعودة
- الخطوة التالية
- نقل البيانات الوصفية إلى Git
2 — محوكم جزئيًا
- كيف يبدو
- Git موجود لكن النشر يدوي
- الخطر الأساسي
- تباعد بين البيئات
- الخطوة التالية
- أتمتة النشر
3 — مؤتمت
- كيف يبدو
- مسار يعمل مع كل pull request
- الخطر الأساسي
- اختبارات ضعيفة تُجيز كل شيء
- الخطوة التالية
- تحديد بوابات جودة حقيقية
4 — محوكم
- كيف يبدو
- بوابات الجودة تمنع الترقية
- الخطر الأساسي
- تأخر الإصدارات بسبب مسار ثقيل
- الخطوة التالية
- تركيز حزمة الانحدار
5 — مستمر
- كيف يبدو
- إصدارات متكررة مع تراجع معروف
- الخطر الأساسي
- تراخٍ تشغيلي
- الخطوة التالية
- مراقبة ومراجعات دورية
أسلوب العمل
مراحل التنفيذ
- 01
مسح الوضع القائم
البيئات والأدوات ووتيرة الإصدار ونقاط الإخفاق الفعلية.
- 02
تصميم المسار
تفريع وبيئات وبوابات جودة تناسب الفريق.
- 03
إقامة البنية
مستودع وأتمتة وفحوص أولى في بيئة اختبار.
- 04
تشغيل متوازٍ
المسار الجديد يعمل بجانب العملية الحالية حتى الاستقرار.
- 05
نقل الفريق
إجراءات وصلاحيات وتدريب بحسب الدور.
- 06
ضبط مستمر
قياس الوتيرة ونسبة الإخفاق وزمن التعافي.
تابع من هنا
خدمات وأدلة ذات صلة
الأسئلة الشائعة
أسئلة متكررة
هل نحتاج فريق تطوير كبيرًا لتبرير CI/CD؟
لا. حتى فريق من شخصين أو ثلاثة يستفيد، لأن القيمة الأساسية هي اليقين وقابلية التتبع لا الحجم. الفريق الصغير يحصل ببساطة على مسار أبسط.
نعمل أساسًا بـ Flow والإعدادات. هل هذا ملائم؟
بالتأكيد. تغييرات الإعداد والأتمتة بيانات وصفية كغيرها، وهي من الأسباب الشائعة لحوادث الإصدار. إدارتها في Git تمنح وضوحًا كاملًا.
ما الأدوات التي تستخدمونها؟
يعتمد الاختيار على المؤسسة. GitHub Actions أو Azure DevOps تناسب الفرق التقنية، بينما تناسب Gearset أو Copado الحالات التي يغلب عليها الإعداد.
كم يستغرق بناء هذا المسار؟
يعمل المسار الأساسي خلال أسابيع قليلة، ثم يجري توسيعه تدريجيًا إلى بوابات جودة كاملة واختبارات انحدار دون تعطيل التطوير الجاري.
الخطوة التالية
بناء مسار الإصدار
نرسم صورة واقعية لبيئاتكم وإصداراتكم اليوم، ونحدد المسار الملائم لوتيرة عملكم.
الخطوة التالية
بناء مسار الإصدار
نرسم صورة واقعية لبيئاتكم وإصداراتكم اليوم، ونحدد المسار الملائم لوتيرة عملكم.