كيف تضبط بوابات الاعتماد وسجلات التدقيق لعمليات نشر Salesforce

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

ما الذي يجعل بوابة الاعتماد قابلة للتدقيق؟

البوابة الموجودة في عادات الأشخاص فقط ليست ضابطاً. أربع خصائص تحولها إلى دليل:

• مفروضة. الترقية مستحيلة تقنياً بدون الاعتماد، لا مجرد غير مستحبة.
• منسوبة. المعتمد هوية مُوثّقة، لا اسم مكتوب داخل تذكرة.
• مرتبطة. الاعتماد يشير إلى commit محدد و org هدف محدد، فلا يمكن إعادة استخدامه لمحتوى آخر.
• غير قابلة للتعديل. لا أحد، ولا حتى المسؤولون، يستطيع تعديل السجل لاحقاً.

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

من يعتمد ماذا، وفي أي بيئة؟

معظم الفرق إما لا تضع بوابات إطلاقاً أو تضعها في كل مكان، وكلا الطريقين يفشل. اضبط البوابات حسب المخاطر، ووثّقها:

• بيئة الميزة أو الـ scratch org: بلا بوابة. السرعة أهم هنا، ولا شيء لاحق يعتمد عليها.
• التكامل أو QA: فحوصات آلية فقط. الاختبارات والتغطية والتحليل الساكن أو مراجعة الكود بالذكاء الاصطناعي يجب أن تنجح. بلا توقيع بشري.
• UAT أو staging: معتمد بشري واحد، عادةً قائد الفريق التقني، مع الفحوصات الآلية. هنا تظل أخطاء التصميم رخيصة.
• الإنتاج: معتمدان. مراجع تقني غير الكاتب، بالإضافة إلى مالك العملية من جانب الأعمال. أضف نافذة إصدار حتى لا تُجمع الاعتمادات في الحادية عشرة مساء الخميس.
• إصلاح عاجل في الإنتاج: معتمد واحد، مع بند عمل لاحق إلزامي خلال 24 ساعة. عرّف المسار بدل التظاهر بأنه لن يُستخدم.

اعتمادان في الإنتاج ليسا بيروقراطية، بل أصغر إعداد يصمد أمام اختبار فصل المهام على طريقة SOX، وتكلفته خمس دقائق تقريباً.

كيف تضبط البوابات؟

1. اسحب صلاحيات النشر من الأشخاص في الإنتاج. هوية التكامل الخاصة بالـ pipeline وحدها تملك Modify Metadata و Modify All Data هناك. هذا التغيير وحده يجعل كل بوابة أخرى حقيقية، لأنه لا يوجد التفاف.
2. فعّل حماية الفروع على الفرع المرتبط بالإنتاج. اشترط الـ pull requests ومراجعة معتمدة واحدة على الأقل، وعطّل الاعتماد الذاتي.
3. اجعل الفحوصات إلزامية لا استرشادية. اختبارات Apex وحد التغطية والتحليل الساكن أو المراجعة الآلية للكود يجب أن تكون فحوصات مانعة. الفحص الذي يمكن تجاهله ليس بوابة.
4. أضف اعتماداً على مستوى البيئة للإنتاج. حماية الفروع تغطي الدمج، وبوابة البيئة تغطي النشر. تحتاج الاثنين، لأنهما يجيبان أسئلة تدقيق مختلفة.
5. ألغِ الاعتمادات القديمة عند أي commit جديد. وإلا أمكن تعديل الـ pull request بعد التوقيع، وهو ما يكسر خاصية الارتباط بهدوء.
6. سمِّ مجموعات المعتمدين بالأدوار لا بالأشخاص. الناس يغادرون، والأدوار هي ما يختبره المدقق.

كل منصات Salesforce DevOps المعروفة تدعم هذا النمط، ومنها Copado و Gearset و AutoRABIT و Flosum و Blue Canvas و Serpent، وكذلك GitHub أو GitLab أمام الـ CLI. الإعداد هو المهم، لا الشعار.

ماذا يجب أن يحتوي سجل النشر؟

حين يختار المدقق عشرة إصدارات، يجب أن ينتهي كل واحد إلى سجل يحمل:

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

احتفظ بذلك خارج الـ org. السجلات التي تعيش داخل Salesforce وحدها تنتهي صلاحيتها، ودورات التدقيق سنوية.

لماذا لا تكفي سجلات Salesforce الأصلية وحدها؟

تستحق التفعيل، لكن اعرف حدودها:

• Setup Audit Trail يحتفظ بـ 180 يوماً، ويعرض في الواجهة أحدث الإدخالات فقط، ولا يسجل القيم قبل وبعد. نزّل ملف الـ CSV وفق جدول أو استعلم عن كائن SetupAuditTrail.
• Field History Tracking محدود بعشرين حقلاً لكل كائن، ويحتفظ بنحو 18 شهراً في الواجهة و24 عبر الـ API، ولا يتتبع حقول الصيغ أو roll-up summary أو الترقيم التلقائي. وField Audit Trail مع Shield يمدد الاحتفاظ عبر سياسة.
• ولا واحد منهما يخبرك إن كان التغيير معتمداً. يسجلان أن شيئاً تغيّر، لا أنه كان مسموحاً.

هذا السطر الأخير هو سبب اعتبار سجل الـ pipeline الدليل الأساسي وسجلات الـ org دليلاً مساعداً.

كيف تمنع التغييرات التي تلتف حول البوابة؟

أكثر ملاحظة شيوعاً ليست اعتماداً سيئاً، بل تغييراً لم يمر بالـ pipeline أصلاً: مسؤول يعدّل قاعدة تحقق في الإنتاج ظهر يوم الثلاثاء. أغلق هذا بثلاث عادات.

1. شغّل كشف الانحراف وفق جدول وقارن org الإنتاج بالفرع. أي شيء موجود في الـ org وغائب عن Git هو إما تغيير غير معتمد أو ثغرة في التقاطك للتغييرات.
2. طابق أسبوعياً مع Setup Audit Trail. كل إدخال يجب أن يقابل عملية نشر أو استثناءً موثقاً.
3. تعامل مع الانحراف المتكرر كعطل في العملية. إذا استمر المسؤولون في الالتفاف حول الـ pipeline، فهو أبطأ من طبيعة عملهم. عالج الاحتكاك لا الأشخاص.

بتشغيل هذه الثلاث يتوقف التدقيق السنوي عن كونه مشروعاً. تجد أدلة إعداد أخرى مثل هذا الدليل في مكتبة SF Guides عندنا.

FAQ

كم معتمداً يحتاج النشر إلى الإنتاج؟

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

هل يمكن لكاتب التغيير أن يعتمده؟

لا. هذا يكسر فصل المهام وهو أول ما يختبره المدقق. عطّل الاعتماد الذاتي في حماية الفروع حتى تُفرض القاعدة لا أن تُتذكّر.

هل تبطئ بوابات الاعتماد الإصدارات؟

نادراً، إذا وزّعت البوابات حسب البيئة. البيئات الأدنى تبقى بلا بوابة وبفحوصات آلية فقط، فتحدث الخطوة البشرية مرة واحدة حيث يكون الخطأ مكلفاً فعلاً.

هل Setup Audit Trail دليل كافٍ وحده؟

لا. يحتفظ بـ 180 يوماً، ويغفل القيم قبل وبعد، ويبيّن أن تغييراً حدث لا أنه اعتُمد. استخدمه لتأكيد سجلات الـ pipeline لديك.