من change sets إلى source control

عندما قدمت Salesforce packaging لأول مرة، لم يكن يُنظر إليه كاستراتيجية تطوير. كان طريقة لتجميع المكونات للتوزيع، خاصة لـ ISVs الذين يبنون تطبيقات لـ AppExchange.

كانت معظم الفرق الداخلية لا تزال تعتمد على change sets، وعمليات النشر اليدوية، وأدوات metadata migration. وكان مفهوم التطوير المعياري ذي الإصدارات بعيدا عن الواقع.

لكن مع الوقت، تغيرت منظومة Salesforce بشكل كبير. ما بدأ كميزة اختيارية لفئة صغيرة من ISVs تحول إلى ركيزة أساسية في طريقة بناء فرق Salesforce engineering الحديثة للأنظمة ونشرها وصيانتها.

فهم هذه الرحلة يوضح لماذا لم يعد packaging مجرد “nice to have”؛ بل أصبح أساس التطوير القابل للتوسع.

البدايات: 1st generation managed packages

قبل وجود Salesforce DX، كان التطوير يحدث مباشرة داخل orgs. بنت الفرق الميزات في sandboxes، واستخدمت change sets أو ANT scripts لنشر metadata، وغالبا لم يكن لديها source of truth واحدة. أتاحت first-generation managed packages (1GP) لـ ISVs توزيع التطبيقات وحماية الملكية الفكرية، لكنها جاءت بقيود كبيرة.

كان إنشاء packages وإصداراتها مرتبطا بالpackaging org نفسها. كان الكود يعيش في org، وكان على المطورين إدارة الاعتماديات يدويا. لم يكن هناك اتصال حقيقي بـ Git أو CI/CD، مما جعل التعاون بطيئا ومعرضا للأخطاء.

بالنسبة لمعظم فرق Salesforce الداخلية، بدا packaging زائدا عن الحاجة. تمسكت بالنشر المباشر لأنه كان أسرع، على الأقل حتى كبرت الأنظمة بما يكفي ليصبح العكس واضحا.

التحول: Salesforce DX وعصر CLI

جاءت نقطة التحول مع Salesforce DX (SFDX) و Salesforce CLI. قدم ذلك نهجا يبدأ من المطور: source-driven development وscratch orgs وexternal version control. ولأول مرة، لم تعد org هي source of truth.

أعاد هذا التحول تعريف طريقة إنشاء packages وصيانتها. أصبح من الممكن استخراج metadata وتخزينها في Git ونشرها بثبات عبر pipelines مؤتمتة. قدمت Salesforce مفهوم unlocked packages للعملاء والشركاء، المصمم لتقسيم orgs الكبيرة الأحادية إلى مكونات أصغر ومعيارية يمكن أن تتطور باستقلالية.

تلت unlocked packages حزم org-dependent unlocked packages

وساعدت الفرق على الانتقال تدريجيا من تطوير org التقليدي دون الحاجة إلى refactor شامل دفعة واحدة.

إذا كنت تبني مباشرة داخل orgs طوال مسيرتك في Salesforce، فهنا يبدأ التحول في الاتضاح. لا تحتاج إلى نقل كل شيء بين ليلة وضحاها. يمكنك أن تبدأ صغيرا، بتغليف feature واحدة أو module أو business process، وتبدأ تتبعها في source control.

هل تمنيت يوما أن تتراجع عن تغيير دون خسارة ساعات من العمل؟ أو ترى بالضبط ما تغير بين الإصدارات؟ أو تنشر بثقة وأنت تعلم أن كل dependency محسوبة؟ هذا ما تتيحه org-dependent unlocked packages.

تسمح لك بتبني versioning والتطوير المعياري وممارسات CI/CD دون كسر بنيتك الحالية. لا refactor ضخم. لا metadata migration كاملة. فقط مسار عملي من البناء القائم على org إلى تطوير حديث source-driven.

حددت هذه الخطوات اتجاها واضحا: أرادت Salesforce أن يتحرك كل فريق، لا ISVs فقط، نحو delivery معيارية قائمة على source control وبوتيرة تناسب واقعه.

Second-generation managed packages: مصممة للتطوير الحديث

رسخ تقديم second-generation managed packages (2GP) هذا التطور. بدلا من بناء وإدارة كل شيء داخل packaging org واحدة، أصبح بإمكان المطورين إنشاء packages مباشرة من local source، وإصدارها عبر Git، وإطلاقها عبر CLI.

كان هذا تغييرا كبيرا. جعل packaging متوافقا مع أدوات CI/CD والاختبار المؤتمت وممارسات التطوير الحديثة. كما حسن 2GP إدارة الاعتماديات وnamespace management والأمان، مع توافقه الوثيق مع طريقة إدارة معظم SaaS platforms للإصدارات.

اليوم، second-generation packaging هو المسار الافتراضي لـ ISVs الجديدة ويتزايد استخدامه لدى فرق enterprise التي تريد workflows تطوير قابلة للصيانة والتوسع. تواصل Salesforce الاستثمار في تحسين هذه الأدوات، من DevHub model وscratch orgs إلى واجهة DevOps Center التي تبسط الكثير من عمل CLI للadmins.

من اختياري إلى أساسي

لسنوات، عومل packaging كخيار إضافي لا تتبناه إلا عندما تصل org إلى حجم أو تعقيد معين. هذه النظرة تصبح قديمة بسرعة. الحقيقة أن كل فريق Salesforce، سواء يبني للاستخدام الداخلي أو للتوزيع التجاري، يستفيد من source control وpackages ذات إصدارات.

تتجاوز الفوائد سرعة النشر. يضمن source-driven development قابلية إعادة الإنتاج، وتدقيقا أسهل، وإصدارات أكثر أمانا. كما يزيل مشكلة “يعمل في sandbox لكنه ينكسر في production” عبر فرض تعريفات metadata متسقة بين البيئات. ويقلل أيضا maintenance overhead عبر إدارة upgrades وdependencies بالإصدارات بدلا من patching اليدوي.

باختصار، نضج packaging من آلية توزيع AppExchange إلى العمود الفقري لتسليم Salesforce المستدام.

ما الذي يجب أن تسأله الفرق الآن

لم يعد الحوار “هل يجب أن نستخدم packages؟” بل “كيف نبدأ، وما سرعة الهجرة؟”

بعض الأسئلة المهمة:

• هل ما زال فريقك ينشر يدويا عبر change sets أو scripts؟

• هل لديك source of truth موثوقة للmetadata؟

• ما سرعة إعادة إنتاج بيئة كاملة من source؟

• هل dependencies والتكاملات لديك tracked وversioned وtestable؟

• هل يستطيع المطورون العمل بالتوازي دون الكتابة فوق عمل بعضهم؟

إذا كانت إجابتك على أي منها “ليس بعد”، فقد حان وقت التفكير في modernising. لا يجب أن تحدث الهجرة بين ليلة وضحاها، لكن كل خطوة تدريجية نحو source-driven, package-based delivery تؤتي ثمارها.

إليك كل ما تحتاج معرفته عن أهمية هذا التحول وتنفيذه. "The Secrets of Salesforce Second Generation Managed Package"

أين تأتي أدوات مثل Serpent

الأساس التقني أصبح قويا، لكن إعداد CI/CD وversion control وpackaging workflows لا يزال يحتاج وقتا. هنا تجعل حلول مثل Serpent by Tekunda الانتقال أسهل. يبسط Serpent Salesforce DevOps عبر أتمتة packaging وversion management وdeployment processes من خلال واجهة بسيطة مبنية حول Git وSalesforce CLI.

مع guided onboarding وautomated release pipelines وnative Git integration، يساعد Serpent الفرق على الانتقال من org development يدوي إلى delivery مؤتمتة بالكامل دون إضافة تعقيد غير ضروري. بالنسبة للفرق التي تفكر في خطوتها التالية في packaging evolution، إنها طريقة سريعة لرؤية الفوائد عمليا.

الخلاصة

قطع Salesforce package development شوطا طويلا. ما بدأ كـ أداة ISV متخصصة أصبح جزءا أساسيا من طريقة تنفيذ Salesforce engineering الاحترافية. لم يعد السؤال هل يجب أن يستخدم فريقك packaging، بل ما سرعة تبنيه.

الانتقال نحو source control وpackages معيارية ليس مجرد best practice؛ إنه الاتجاه الذي تبني نحوه Salesforce نفسها. كلما واءمت مبكرا، أصبحت إصداراتك أسرع، ومعمارك أنظف، وتوسعك أسلس.