كل أدوات Salesforce DevOps بتتجاهل تطوير الحزم

الإجابة باختصار: فئة Salesforce DevOps كبرت وهي بتحل مشكلة النشر من org لـ org، فبقت أدواتها الأساسية بيئات وmetadata، مش نسخًا مُصدَّرة برقم إصدار. تسليم الحزم، سواء 1GP أو 2GP أو الحزم المُدارة، جه متأخر كإضافة، ولسه بيتباع في أغلب الأحوال كترقية. وعشان كده، في 2026، معظم شركات الـ ISV والـ PDO لسه بتطلق منتجاتها بسكربتات كتبوها بنفسهم.

تسليم الحزمة بيتضمن إيه بالظبط؟

الإصدار من org لـ org قصير: تجمع التغييرات، تتحقق منها على الهدف، وتنشر. إصدار الحزمة شكله مختلف تمامًا:

1. حل الاعتماديات بين حزمك وأي حزم إنت بانٍ فوقها.
2. إنشاء إصدار على Dev Hub، جوه scratch org، بالسلف الصحيح عشان مسار الترقية يفضل سليم.
3. تثبيت الإصدار ده في بيئات اختبار، واحدة لكل نسخة وإعداد بتدعمه.
4. عبور البوابات: تغطية Apex، والتحليل الساكن، ولو المنتج منشور، مراجعة أمان الـ AppExchange.
5. ترقية الإصدار لحالة released، وده قرار ما بيترجعش فيه.
6. دفعه أو نشره لبيئات المشتركين، وبعدين متابعة مين على أنهي إصدار.
7. تحديث إصدار القائمة عشان اللي العملاء بيشوفوه يطابق اللي يقدروا يثبتوه.

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

ليه الفئة كبرت حوالين النشر من org لـ org؟

لأن ده مكان الحجم الأكبر. الغالبية العظمى من فرق Salesforce بتشغّل org إنتاج واحدة وحواليها مجموعة sandboxes، ومشكلة الإصدار عندهم بصراحة هي: "أنقل التغيير ده من UAT للإنتاج من غير ما أكسر حاجة". Copado وGearset وAutoRABIT وFlosum وSalto وBlue Canvas كلهم بنوا منتجات قوية للمشكلة دي، وبنفس النموذج: بيئات وفروع وmetadata وفروقات.

مفيش في العناصر دي حاجة اسمها رقم إصدار. الحزمة مش فرق بين org واتنين. الحزمة نسخة ثابتة ليها هوية وسلف ومجموعة عمليات تثبيت عايشة في بيئات إنت ما بتتحكمش فيها.

إيه اللي بيحتاجه pipeline الحزم وما بيحتاجهوش pipeline الـ org؟

• نسخة مُصدَّرة مش فرق. وحدة الإصدار هي معرّف نسخة، ولازم تعيش أطول بكتير من الفرع اللي طلعت منه.
• السلف. لو السلف غلط، إنت ما طلعتش إصدار سيء، إنت طلعت إصدار مستحيل تترقّى منه.
• ترتيب الاعتماديات. المنتج متعدد الحزم بيتثبت بترتيب محدد، والترتيب ده لازم يتحسب مش يتفتكر.
• الـ scratch orgs كوحدة اختبار. التحقق من الحزمة بيتم في org نضيفة، ومرات كتير، وده بيحوّل وقت التجهيز لتكلفة حقيقية في الـ CI.
• رؤية للمشتركين. مين على أنهي إصدار، وعند مين فشلت ترقية مدفوعة، ومين متأخر إصدارين رئيسيين وبيعطل إيقاف ميزة.
• بوابات مراجعة. مراجعة الأمان خطوة إصدار للمنتج المنشور، مش مهمة امتثال بتحصل في مكان تاني.

ليه شركات الـ ISV لسه بتكتب سكربتات إصدار بنفسها؟

لأن ده اللي المنظومة بتقوله لهم. دوّر على طريقة إطلاق حزمة 2GP، هتلاقي أدلة خطوة بخطوة لبناء pipeline بنفسك في Azure DevOps أو GitHub Actions، وربط sf package version create وsf package version promote بإيدك. ودليل Salesforce نفسه للحزم المُدارة من الجيل التاني بيقولها صريحة: عمليات التحزيم بتتنفذ عبر الـ CLI، أو بتأتمتها بسكربتات.

دي إجابة كويسة لمنصة. لكنها إجابة غريبة من فئة بتبيع أتمتة الإصدارات.

وفي نفس الوقت المنصة ماشية قدام. Package Migrations بقت متاحة للجميع في إصدار Summer '25، ومعاها sf package convert اللي بيحوّل نسخة 1GP لنسخة 2GP، وترقية مدفوعة بخيار --migrate-to-2gp بتنقل المشتركين من غير إعادة تثبيت. يعني ناشر 1GP بقى قدامه مسار انتقال حقيقي، وبقى محتاج فعلًا pipeline يفهم الجيلين مع بعض. ومعظم الأدوات لسه بتعامل التحزيم كتكامل بتركّبه من بره.

إيه اللي بيتكسر لما التحزيم يبقى إضافة؟

تلات حاجات، وبيتراكموا فوق بعض:

• الفرق اللي محتاجاه أكتر ما تقدرش تشتريه. شركة ISV من خمس أفراد عندها أصعب مشكلة إصدار في المنظومة وأقل ميزانية. لو دعم الحزم مقفول ورا باقة enterprise، الفريق ده هيكتب bash، والسكربتات دي بتبقى معرفة شفهية معتمدة على شخص واحد.
• حالة الإصدار بتنتهي في ملف Excel. لما الـ pipeline ما يقدرش يمسك نسخة، السلف وإصدارات المشتركين بيعيشوا في مستند محدش بيحدّثه يوم الجمعة.
• الاختبار بيضعف في صمت. لو الـ scratch org بتاخد دقايق للتجهيز والـ pipeline مش مبني على كده، في الآخر حد هيقلل عدد مرات التحقق من الحزمة في org نضيفة. وده بالظبط الاختبار اللي بيمسك أخطاء التحزيم.

دعم التحزيم من الدرجة الأولى شكله إيه؟

الاختبار بسيط: هل نفس الـ pipeline اللي بينشر تغيير org يقدر كمان يقطع نسخة، ويحل الاعتماديات، ويثبت في مصفوفة اختبار، ويرقّي ويتابع المشتركين، من غير ما تسيب المنتج؟ وعلى نفس الباقة، مش على باقة enterprise.

دي الفجوة اللي Serpent اتبنى حواليها، وطالعة من تجربة تشغيل شركة ISV في مجال الصحة الرقمية عبر حزم مُدارة ومراجعة أمان AppExchange. مسارات 1GP و2GP والحزم المُدارة، وحل الاعتماديات بين الحزم، وإدارة الإصدارات عبر بيئات المشتركين، ومسارات إصدار AppExchange كلها في كل الباقات، بما فيها المجانية، مع تجهيز مسبق لمجموعة scratch orgs في باقة Scale عشان التحقق في org نضيفة يفضل رخيص كفاية إنك تكمل بيه. شوف Serpent بيتعامل إزاي مع تسليم الحزم.

FAQ

هل 2GP إلزامي ولا أقدر أفضل على 1GP؟

تقدر تفضل، بس استثمار المنصة ماشي في اتجاه 2GP. وPackage Migrations، المتاحة للجميع من Summer '25، بتحوّل نسخة 1GP وبتنقل المشتركين بترقية مدفوعة.

ما أستخدمش GitHub Actions وخلاص؟

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

هل ده يخص شركات AppExchange بس؟

لأ. أي فريق بيستخدم حزم unlocked أو managed لتقسيم مشروعه داخليًا بيقابل نفس العناصر، من غير مراجعة الأمان.

إيه أصعب جزء في إصدار الحزمة؟

السلف والترقية لحالة released، لأن الاتنين ما بيترجعش فيهم. السلف الغلط بيكسر مسار الترقية لكل المشتركين، والنسخة اللي اترقّت ما ينفعش ترجعها.