لماذا تحتاج ملفات الإعدادات الخاصة بك إلى مخطط قبل وصولها إلى الإنتاج

تبدو سلسلة اتصال قاعدة البيانات غير ضارة. بضعة أسطر من YAML أو INI، اسم مضيف، رقم منفذ، قيمة مهلة. ما الذي يمكن أن يحدث خطأ؟

الكثير. قد يكتب شخص ما database.port = "5432" بدلاً من 5432. القيمة الآن سلسلة نصية، وليس عددًا صحيحًا. يتم حفظ ملف الإعدادات دون اعتراض. يبدأ التطبيق، ويقرأ المنفذ، ويحاول الاتصال، ويفشل. أو الأسوأ: يكتب شخص ما database.timout = 30 — خطأ إملائي في اسم الحقل. يتجاهل التطبيق الحقل غير المعروف بصمت ويستخدم المهلة الافتراضية، والتي قد تكون صفرًا. تنتهي مهلة الاتصالات فورًا. يرى المستخدمون أخطاء. لا أحد يعرف السبب حتى يبحث شخص ما في السجلات ويجد الخطأ الإملائي.

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

المشكلة: الإعدادات بلا حواجز حماية

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

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

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

ما يفعله المخطط (Schema)

المخطط هو مخطط تفصيلي لإعداداتك. يحدد:

  • الحقول المسموح بها
  • أنواع البيانات التي يتوقعها كل حقل
  • القيم الصالحة (النطاقات، التعدادات، الأنماط)
  • الحقول المطلوبة
  • شكل الهيكل (كائنات متداخلة، مصفوفات)

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

JSON Schema: مثال عملي

JSON Schema هو معيار واسع الاستخدام لوصف هياكل بيانات JSON. يعمل مع أي لغة ويتكامل مع العديد من الأدوات. إليك مخطط بسيط لإعدادات قاعدة بيانات:

{
  "type": "object",
  "properties": {
    "database.host": { "type": "string" },
    "database.port": { "type": "integer", "minimum": 1024, "maximum": 65535 },
    "database.timeout": { "type": "integer", "minimum": 1, "maximum": 300 }
  },
  "required": ["database.host", "database.port", "database.timeout"]
}

يقول هذا المخطط:

  • يجب أن يكون الإعداد كائنًا
  • database.host يجب أن يكون سلسلة نصية
  • database.port يجب أن يكون عددًا صحيحًا بين 1024 و 65535
  • database.timeout يجب أن يكون عددًا صحيحًا بين 1 و 300 ثانية
  • جميع الحقول الثلاثة مطلوبة

إذا قدم شخص ما إعدادًا بـ database.port = "5432"، يفشل التحقق لأن القيمة سلسلة نصية، وليس عددًا صحيحًا. إذا كتب شخص ما database.timout = 30، يفشل التحقق لأن timout ليس حقلًا معروفًا. إذا نسي شخص ما تضمين database.host، يفشل التحقق لأن الحقل مطلوب.

يحدث التحقق في CI. يتوقف خط الأنابيب. يحصل المطور على ردود فعل فورية. لا نشر، لا فشل في وقت التشغيل، لا حادث إنتاج.

مكتبات التحقق الخاصة بلغات البرمجة

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

  • Python: pydantic و cerberus تسمحان لك بتعريف المخططات كفئات أو قواميس Python. يحدث التحقق عند تحميل الإعدادات، قبل تشغيل أي منطق تطبيق.
  • Go: go-playground/validator يستخدم وسوم الهياكل (struct tags) لتحديد قواعد التحقق. يتم التحقق من هيكل الإعدادات عند بدء التطبيق.
  • Java: Hibernate Validator يستخدم التعليقات التوضيحية (annotations) على فئات الإعدادات. يتم تشغيل التحقق عند بدء التشغيل، قبل أن يتصل التطبيق بأي خدمة خارجية.

تكتشف هذه المكتبات أكثر من مجرد أخطاء الأنواع. يمكنها التحقق من النطاقات والأنماط وقواعد العمل المخصصة والتبعيات عبر الحقول. على سبيل المثال، يمكنك فرض أن connection.timeout يجب أن يكون أقل من query.timeout، أو أن retry.count يجب أن يكون بين 0 و 10.

متى يجب أن يحدث التحقق

القاعدة الذهبية: تحقق من الإعدادات قبل استخدامها، وليس عند بدء التطبيق.

يوضح الرسم البياني التالي خط أنابيب التحقق المثالي:

flowchart TD A[تحرير ملف الإعدادات] --> B[الإيداع في المستودع] B --> C[تشغيل خط أنابيب CI] C --> D[التحقق من المخطط] D --> E{صالح؟} E -->|نعم| F[النشر إلى البيئة] E -->|لا| G[الرفض مع رسالة خطأ] G --> H[يقوم المطور بإصلاح الإعدادات] H --> A

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

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

تقوم بعض الفرق أيضًا بالتحقق من الإعدادات في وقت طلب السحب (Pull Request). تقوم وظيفة CI بتشغيل التحقق من المخطط على كل تغيير في الإعدادات. يرى المطورون الأخطاء قبل الدمج. هذا يكتشف المشكلات حتى في وقت أبكر، عندما تكون تكلفة إصلاحها أقل.

قائمة مراجعة عملية للتحقق من الإعدادات

إذا كنت تضيف التحقق من المخطط إلى إعداداتك، إليك قائمة مراجعة سريعة لتوجيه تنفيذك:

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

ما بعد التحقق

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

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

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

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