ما الذي يُعتبر تكوينًا ولماذا هو أكثر أهمية مما تظن

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

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

ما هو التكوين فعليًا

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

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

لكن التكوين يتجاوز بكثير بيانات اعتماد قاعدة البيانات.

أنواع شائعة من التكوين

مفاتيح API والأسرار

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

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

أعلام الميزات

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

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

القيم الخاصة بالبيئة

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

المعاملات غير الوظيفية

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

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

أين ترسم الخط الفاصل بين الكود والتكوين

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

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

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

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

لماذا أخطاء التكوين أكثر خطورة من أخطاء الكود

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

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

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

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

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

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

إذا أجبت بـ "لا" على أي من هذه، فلديك دين تكوين سيؤدي في النهاية إلى حادث إنتاجي.

الخلاصة العملية

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