هل يجب أن يمتلك مسؤولو Salesforce خط النشر؟

باختصار: نعم، يجب أن يتولى مسؤولو Salesforce نشر تغييراتهم بأنفسهم من الـ sandbox حتى بيئة الإنتاج. لكن لا ينبغي أن ينفردوا بتصميم خط النشر نفسه. خلّي زر الترقية مع المسؤولين، وخلّي القواعد مع مسؤول إصدارات محدد بالاسم: نموذج الـ branching وبوابات الجودة وسياسة التراجع. بالتقسيم ده يبطل المسؤولون انتظار دورهم في الطابور، وتفضل الضوابط في مكانها داخل الـ org.

ما معنى امتلاك خط النشر فعليًا؟

امتلاك خط النشر يبدو كأنه مهمة واحدة، لكنه في الحقيقة ثلاث مهام مختلفة:

• امتلاك التغيير: بناء الـ flow أو الحقل أو الـ permission set، ومعرفة ما يعتمد عليه.
• امتلاك الترقية: نقل هذا التغيير من التطوير إلى الاختبار إلى الإنتاج، وإصلاحه لما مرحلة من المراحل ترفضه.
• امتلاك تصميم خط النشر: تحديد المراحل ونموذج الـ branching والاختبارات المطلوب نجاحها ومن يوافق على الإنتاج وطريقة التراجع.

غالبًا ما يتعطل النقاش حول دور المسؤولين لأن الناس بتخلط بين المهام الثلاث دي. المسؤولون يمتلكون الأولى بالفعل، والسؤال الحقيقي هو هل يمتلكون الثانية والثالثة كمان.

لماذا يُطرح هذا السؤال الآن؟

لأن الأدوات لم تعد تشترط مهارات Git. نسخة الجيل الجديد من DevOps Center أصبحت مدمجة في المنصة وتُفعَّل من Setup من غير managed package. فيها خطوط نشر مرئية وwork items واكتشاف للتعارضات، وبتدير التحكم في الإصدارات في الخلفية، فالمسؤول لا يتعامل أبدًا مع Git أو سطر الأوامر. والأدوات التجارية من Copado وGearset وFlosum وBlue Canvas وغيرها تقدم وعدًا مشابهًا لمن يبنون بالأسلوب التصريحي.

ومشاركة المسؤولين في ازدياد كمان. تقرير State of Salesforce DevOps 2024 من Gearset وجد أن المسؤولين يشاركون في عمليات DevOps أكثر فأكثر، وأن 21% فقط من الفرق تقسم سير عمل الإصدار. يعني أغلب الفرق بتمرر الجميع في عملية واحدة أصلًا، والسؤال المتبقي هو مين يتحكم فيها.

هل يجب أن يمتلك المسؤولون عمليات الترقية؟

نعم، وهنا تكمن أغلب القيمة. لما المسؤول يبني تغييرًا وبعدين يستنى مطورًا ينشره، الشغل يقعد في طابور، والسياق يضيع، واللي بينشر ما يكونش فاهم كويس هو بيطلق إيه. عند نقطة التسليم دي بالذات تظهر كثير من المخاطر الخفية في عملية نشر Salesforce: اعتماديات غير متتبعة، ومكونات منسية، واختلافات بين الـ sandboxes.

المسؤول اللي بيرقّي شغله بنفسه عبر المراحل يكتشف المشاكل دي في المكان اللي تكون فيه أقل تكلفة. الشرط إن خط النشر يعرض الأخطاء بلغة واضحة. أما stack trace خام من Metadata API فبيرجّع الشغل للمطور على طول، وعشان كده وحدة أخطاء النشر التي تحوّل الإخفاقات إلى حلول تهم المسؤولين أكثر من أي حد تاني.

هل يجب أن يمتلك المسؤولون تصميم خط النشر؟

غالبًا لا، مش لوحدهم. تصميم خط النشر قرار حوكمة: إيه اللي يُعتبر مُختبَرًا، ومين يقدر يوافق على الإنتاج، وإزاي الـ hotfixes تتخطى الطابور، وإيه اللي يحصل لما فريقين يعدلوا نفس الـ object. القواعد دي محتاجة مالك واحد مسؤول، والمالك ده لازم يكون الشخص اللي بيتحاسب على استقرار الإنتاج. في فرق كتير ده مدير الإصدارات أو المعماري، وفي الفرق الصغيرة ممكن يكون مسؤول أول.

المعيار هو المحاسبة، مش المسمى الوظيفي. المسؤول اللي بيصمم خط النشر وبيتصلوا بيه الساعة 9 الصبح لما نشر يكسر عملية المبيعات، هو المالك الحقيقي. أما اللي بيصممه وبيسلّم الحوادث لحد تاني، فلأ.

متى يستطيع المسؤولون امتلاك خط النشر بالكامل

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

متى لا ينبغي أن يمتلكوه وحدهم

• Apex وLWC والتكاملات تنزل جنب التغييرات التصريحية ومحتاجة بوابات لمراجعة الكود وتغطية الاختبارات.
• القطاعات الخاضعة للتنظيم تشترط الفصل بين من يبني التغيير ومن يوافق عليه للإنتاج.
• أكثر من فريق أو شريك بيرقّوا لنفس الـ org في نفس الوقت.

كيف تسلّم خط النشر للمسؤولين بأمان؟

1. اكتب القواعد الأول. المراحل والفحوصات المطلوبة ومن يوافق على الإنتاج تتحدد قبل ما أي حد ياخد زر الترقية.
2. خلّي كل تغيير work item متتبَّع. مفيش نشر من غير تسمية، عشان كل تغيير في الإنتاج يرجع لطلب محدد.
3. أتمت البوابات. التحقق والاختبارات وفحص التعارضات تشتغل تلقائيًا مع كل ترقية، والمسؤولون مش محتاجين يفتكروها.
4. اتدرب على التراجع. المسؤول لازم يقدر يرجّع إصدارًا من غير مساعدة مطور.
5. راجع كل شهر. شوف إيه اللي فشل وليه، وعدّل القواعد مش الأشخاص.

كيف تعرف أن تقسيم المسؤولية ناجح؟

قِسه بـ مقاييس DORA لتسليم البرمجيات. معدل النشر المفروض يزيد ومدة تنفيذ التغيير المفروض تقل أول ما المسؤولون يبطلوا انتظار دورهم في طابور النشر. ونسبة فشل التغييرات ووقت التعافي من النشر الفاشل بيوضحوا هل الضوابط صامدة ولا لأ. لو المعدل زاد والأخطاء زادت معاه، فالمشكلة في البوابات مش في المسؤولين. وغالبًا هي نفس الأسباب القليلة اللي بنشرحها في لماذا لا تزال عمليات نشر Salesforce تتعطل.

أين يأتي دور Serpent؟

Serpent مبني على التقسيم ده: سير عمل واحد للمسؤولين والاستشاريين والمطورين ومديري الإصدارات، من غير خبرة في Git ومع تراجع بنقرة واحدة. المسؤولون يرقّون شغلهم بنفسهم، ومسؤولو الإصدارات يحددون القواعد اللي لازم يعدّي منها. والتسعير مش لكل مستخدم ولا لكل org، فضم كل المسؤولين لخط النشر مش هيزود الفاتورة. اطّلع على أسعار Serpent وشوف المقارنة، أو اقرأ ليه بنينا Serpent.

FAQ

هل يحتاج مسؤولو Salesforce إلى تعلم Git للنشر؟

مع الأدوات الحديثة لأ. الجيل الجديد من DevOps Center وأغلب أدوات Salesforce DevOps التجارية بتدير التحكم في الإصدارات من خلال واجهة بالنقر.

من يجب أن يوافق على عمليات النشر إلى الإنتاج؟

مسؤول إصدارات محدد بالاسم ويتحاسب على استقرار الإنتاج. في الفرق الخاضعة للتنظيم، لازم يكون شخص غير اللي بنى التغيير.

هل يكفي DevOps Center لخط نشر يقوده المسؤولون؟

للفرق الصغيرة اللي شغلها في الغالب تصريحي، هو نقطة بداية مجانية معقولة. الفرق اللي عندها مسارات عمل متوازية كتير أو متطلبات امتثال صارمة غالبًا محتاجة بوابات وضوابط امتثال أكثر تقدمًا.

ما أكبر خطر في خطوط النشر التي يمتلكها المسؤولون؟

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