Click Deploy من Git: النشر على Salesforce من فرع

باختصار: الـ click deploy من Git يستخدم فرعًا في مستودع، وليس sandbox، كمصدر لعملية نشر على Salesforce بالنقر. تقدم الأدوات عادة أربعة أوضاع: مكونات مختارة، أو الفرع كاملًا، أو الفروق بين فرعين، أو كل ما تم عمل commit له منذ آخر build ناجح. لإصدارات الفريق، انشر الفروق بين الفروع، وتحقق أولًا، ومرّر عمليات الحذف عبر pull request.

ما هو الـ click deploy من Git؟

الـ click deploy التقليدي يقارن بين منظمتين ويشحن المكونات التي تختارها، كما نشرح في كيف يعمل ClickDeploy وكم يكلف. أما الـ click deploy المعتمد على Git فيحتفظ بنفس الواجهة لكنه يغيّر المصدر: تقرأ الأداة الـ metadata من فرع في مستودع مثل GitHub أو GitLab أو Bitbucket أو Azure DevOps وتنشرها على المنظمة الهدف. ما زلت تنقر. الفرق أن كل تغيير تم عمل commit له قبل أن يُشحن.

لماذا تنشر من فرع بدلًا من منظمة؟

• سجل مشترك. النشر من منظمة إلى منظمة لا يحتفظ بسجل لمن غيّر ماذا، فقد يكتب النشر الثاني فوق الأول بصمت. الفرع يحتفظ بكل تغيير وصاحبه.
• مراجعة قبل الإصدار. تمر التغييرات عبر pull request قبل أن تصل إلى أي منظمة.
• مصدر حقيقة معروف. الفرع المرتبط بالإنتاج يوضح ما يفترض أن يحتويه الإنتاج، وهذا ما يجعل التراجع موثوقًا.

توقّع بعض الضوضاء. تشير وثائق Gearset إلى أن المنظمات تتغير باستمرار بسبب المهام الآلية وترقيات المنصة ونشاط المستخدمين، وأن Metadata API يعيد ترتيب الـ XML لبعض أنواع المكونات، وأن metadata الملفات الشخصية (profiles) تعتمد على ما يُسترجع معها. وتنصح بتتبع أنواع الـ metadata كثيرة التغيير وعالية التأثير بدلًا من تتبع كل شيء.

ما هي خيارات مصدر Git للـ click deploy؟

توثّق Copado Essentials، الأداة التي كانت تسمى ClickDeploy سابقًا، أربعة خيارات لمصدر Git، وهي تنطبق جيدًا على أدوات أخرى:

1. مكونات مختارة من فرع. يعمل مثل النشر من منظمة إلى منظمة: تختار المكونات من الفرع يدويًا. مناسب لإصلاح عاجل محدد.
2. كل محتوى الفرع. ينشر محتوى الفرع كاملًا دفعة واحدة. مناسب لبيئة جديدة أو معاد بناؤها، أما على الإنتاج فيشحن أكثر بكثير من التغيير المطلوب.
3. الفروق بين فرعين. يقارن فرع المصدر بفرع المقارنة وينشر ما يختلف فقط. تنصح Copado بأن يكون فرع المقارنة هو الفرع المرتبط بالمنظمة الهدف.
4. Build تزايدي. مهمة CI تنشر فقط الملفات التي تم عمل commit لها منذ آخر build ناجح، ويُتتبع ذلك بعلامة build تتقدم بعد كل نشر ناجح. مهمة CI للتحقق فقط لا تحرك العلامة حتى لو نجحت.

الخيار الثالث هو الصيغة الأصلية في Git لـ النشر التفاضلي (delta deployments)، وهو الاختيار الافتراضي الصحيح لترقية ميزة من فرع بيئة إلى الفرع التالي.

كيف تنفذ click deploy من فرع Git خطوة بخطوة؟

1. اربط المستودع والمنظمة الهدف. امنح الصلاحية للاثنين في أداتك، واحتفظ بالمستودع بصيغة metadata واحدة. تلاحظ Gearset أن مستودعات صيغة Metadata API وصيغة DX مبنية بشكل مختلف.
2. اربط الفروع بالبيئات. حدد أي فرع يمثل كل منظمة، مثلًا فرع لـ UAT وmain للإنتاج. جودة مقارنة الفروع من جودة هذا الربط.
3. اختر فرع المصدر وفرع المقارنة. خذ فرع الميزة أو الإصدار كمصدر، والفرع المرتبط بالمنظمة الهدف كمقارنة.
4. راجع الفروق. اقرأ ما تنوي الأداة نشره. لو في metadata متوقعة ناقصة، دوّر على ملف package.xml: فـ Gearset تفلتر المقارنات افتراضيًا حسب ملف صالح منه.
5. تعامل مع الحذف بوعي. في Copado Essentials، تحديد مكونات للحذف داخل مسار Git يزيلها من الفرع أولًا، فتعمل commit للتغيير وتدمجه عبر pull request قبل أن تتغير المنظمة.
6. تحقق ثم انشر. شغّل تحققًا دون حفظ (check-only) بمستوى اختبارات Apex تختاره عن قصد، ثم انشر. تغطي قائمة التحقق للـ click deploy مستويات الاختبار والـ quick deploy.
7. ادمج في الاتجاه العكسي. بعد نجاح النشر، ادمج المصدر في فرع المقارنة حتى يتطابق الفرع مع المنظمة من جديد.

ما الأدوات التي تدعم الـ click deploy من Git، وكم تكلف؟

• Copado Essentials: تكامل Git مع GitHub وBitbucket وGitLab وAzure DevOps موجود في Essentials Plus، بسعر $249 لكل مستخدم شهريًا مع الفوترة السنوية أو $289 شهريًا، مع تجربة لمدة 21 يومًا، حسب صفحة الأسعار. لا تذكر خطتا Free وBasic تكامل Git.
• Gearset: صفحة Compare and deploy تقبل فرعًا في source control كمصدر أو كهدف، حسب مركز المساعدة.
• DevOps Center: الخيار الأصلي من Salesforce، يعمل بالنقر ويعتمد على Git. يذكر Salesforce Ben أن الجيل الجديد يعمل أصليًا داخل منظمات الإنتاج منذ Spring '26، ويدعم GitHub وBitbucket، ويتيح عملياته عبر خادم Salesforce MCP الرسمي.
• مسار الـ CLI: الفرق المتعودة على الطرفية تستخدم إضافة المجتمع sfdx-git-delta، التي يبني أمرها sf sgd source delta ملفي package.xml وdestructiveChanges.xml من commitين. ويؤكد القائمون عليها أنها ليست أداة مدعومة رسميًا من Salesforce.

التسعير لكل مستخدم يرتفع بسرعة بمجرد دخول Git: خمسة أشخاص على Essentials Plus يكلفون $1,245 شهريًا مع الفوترة السنوية.

كيف تتعامل Tekunda مع الـ click deploy المعتمد على Git؟

Tekunda هي شركة استشارات ومنتجات Salesforce التي تقف وراء Serpent، منصة DevOps التي تستخدمها أيضًا في تسليم مشاريع عملائها. في Serpent يواصل المسؤولون النقر: يختارون التغييرات من واجهة، ويربطونها بتذكرة، ويرقّونها عبر الـ pipeline، بينما تعمل commits الـ Git والـ pull requests واختبارات Apex في الخلفية. نشرح هذا المسار في DevOps للمسؤولين من غير لمس Git. تسعّر Serpent لكل شركة وليس لكل مستخدم، فقارنها بالأدوات التي تسعّر لكل مقعد في صفحة الأسعار، ويمكن للفرق المنتقلة من Copado Essentials اتباع مسار الترحيل. تجد أدلة عملية أكثر في مكتبة SF Guides.

FAQ

هل يمكنني تنفيذ click deploy من GitHub إلى Salesforce من غير CLI؟

نعم. تنشر Copado Essentials Plus وGearset وDevOps Center جميعها من فرع Git عبر واجهة تعمل بالنقر.

ما الفرق بين نشر الفرع والنشر التفاضلي؟

نشر الفرع يشحن كل ما في الفرع. أما النشر التفاضلي فيشحن فقط ما يختلف بين فرعين أو commitين.

هل يحذف الـ click deploy من Git أي metadata؟

فقط لو طلبت ذلك. تنتقل عمليات الحذف كـ destructive changes، وفي Copado Essentials يتم عمل commit لها ودمجها عبر pull request أولًا.

لماذا يختلف فرعي عن منظمتي مباشرة بعد الإعداد؟

المنظمات تتغير باستمرار، وقد يعيد Metadata API ترتيب الـ XML أو يرجع محتوى مختلفًا للـ profiles، لذلك بعض الانحراف أمر طبيعي.