انحراف البيئات: لماذا لم تعد بيئات Salesforce عندك تطابق الإنتاج

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

ما هو انحراف البيئة؟

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

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

من أين يأتي الانحراف فعلًا؟

معظمه يأتي من تغييرات كانت معقولة في وقتها:

• إعدادات تُنفَّذ مباشرة في الإنتاج. قيمة في قائمة اختيار أُضيفت يوم الجمعة لأن صفقة احتاجتها. قرار صحيح، لكنه غير مرئي لمستودعك.
• إصلاحات عاجلة لم تُدمج للخلف. الإصلاح وصل الإنتاج، أما الفرع الذي كان يجب أن يستقر فيه فلم يأخذه.
• حزم مثبّتة في بيئة واحدة. أحدهم يثبّت تطبيقًا في بيئة اختبار لتقييمه، أو في الإنتاج ليفكّ عائقًا أمام فريق.
• صلاحيات مُنحت بالاستثناء. الملفات ومجموعات الصلاحيات هي أسرع البيانات الوصفية انحرافًا في معظم البيئات، وأقلها وجودًا في إدارة الإصدارات.
• إعدادات خاصة بكل بيئة ولم يكن يُقصد تطابقها أصلًا. نقاط النهاية وبيانات الاعتماد المسماة وإعدادات البريد والمهام المجدولة. هذا انحراف مشروع، ومع ذلك يجب إعلانه، لأنك إن لم تميّز المشروع من العَرَضي فستتجاهل الاثنين معًا.
• جدول إصدارات Salesforce نفسه. النسخ تُحدَّث في أوقات مختلفة، فقد تعمل بيئتان فعلًا على إصدارين مختلفين من المنصة لفترة.

لا شيء من ذلك إهمال، بل هو نظام يسمح للتغيير بالدخول من أكثر من باب.

لماذا لا يحل التحديث الفصلي المشكلة؟

طقس التحديث يفترض أن الانحراف يمكن تصفيره دوريًا. انظر إلى الوتيرة التي تسمح بها Salesforce: بيئات Developer وDeveloper Pro يمكن تحديثها نحو مرة يوميًا، وPartial Copy كل خمسة أيام، والبيئات الكاملة كل 29 يومًا (راجع توثيق أنواع بيئات الاختبار).

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

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

ما التكلفة الحقيقية للانحراف؟

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

كيف يبدو الكشف المستمر عن الانحراف؟

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

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

هذه هي فكرة التصميم في Serpent: الكشف عن الانحراف يقف إلى جانب النشر التفاضلي والتراجع بنقرة واحدة ومراجعة الكود بالذكاء الاصطناعي التي ترصد انحراف الحوكمة في كل تغيير، ويعمل عبر واجهات برمجة قياسية دون تثبيت أي شيء داخل بيئتك. ووجود الكشف والنشر في مكان واحد يعني أن الإصلاح إجراء واحد لا تذكرة إلى فريق آخر.

ماذا تفعل هذا الأسبوع؟

اختر أهم بيئة اختبار لديك وقارنها بالإنتاج مرة واحدة. ثم افرز النتائج إلى "متوقع" و"كنا نعلم به" و"من فعل هذا؟". فإن كانت السلة الثالثة الأكبر، توقّف عن جدولة التحديثات وابدأ جدولة المقارنات.

FAQ

ما الذي يسبب انحراف بيئات Salesforce؟

تغييرات تصل إلى البيئة خارج عملية النشر: إعدادات مباشرة في الإنتاج، وإصلاحات عاجلة لم تُدمج للخلف، وحزم مثبّتة في بيئة واحدة، وتعديلات صلاحيات، وإعدادات مشروعة خاصة بكل بيئة لم تُوثَّق بهذه الصفة.

هل يعالج تحديث بيئة الاختبار الانحراف؟

مؤقتًا فقط. البيئات الكاملة يمكن تحديثها كل 29 يومًا في أفضل الأحوال، ومعظم الفرق تنجز ذلك فصليًا، بينما يتراكم الانحراف يوميًا.

كم مرة ينبغي فحص الانحراف؟

يوميًا للإنتاج ولأي بيئة تُستخدم في التحقق قبل الإصدار. وأي وتيرة أبطأ تُفقدك السياق اللازم لتفسير ما تغيّر.

هل كل انحراف سيئ؟

لا. نقاط النهاية وبيانات الاعتماد والمهام المجدولة يُفترض أن تختلف. المشكلة ليست وجود اختلافات، بل أن الاختلافات غير المعلَنة لا يمكن تمييزها عن الأخطاء.