قد تصل تغييرات خطرة في البنية التحتية إلى بيئة الإنتاج من دون أن تواجه الفحص نفسه الذي تخضع له شيفرة التطبيقات. يطرح مقال منشور في مدونة Qodana هذا السيناريو من خلال نشر إعداد Kubernetes بلا حدود للموارد، أو تشغيل حاوية بصلاحيات المستخدم الجذر، أو استخدام وسوم قابلة للتغيير في سير عمل GitHub Actions، ثم انتقال هذه التغييرات إلى الإنتاج من دون بوابة جودة أو تحذير داخل بيئة التطوير أو فشل في التكامل المستمر.
يتمثل اقتراح الكاتب في توسيع نطاق Qodana، وهي منصة لفحص جودة الشيفرة، بحيث تشمل ملفات DevOps وهندسة المنصات. لكن المقال لا يعلن إطلاق منتج أو ميزة متاحة؛ بل يقدم فكرة ما تزال في مرحلة الاستكشاف، ويدعو الممارسين إلى إبداء آرائهم بشأن الحاجة إليها والأدوات التي ينبغي دعمها أولاً.
مشكلة الأدوات المتفرقة
تعتمد فرق DevOps وهندسة المنصات غالباً على مجموعة من أدوات سطر الأوامر المنفصلة لتحليل مكونات البنية التحتية. ويذكر المقال أمثلة تشمل Kube-score لتحليل ملفات Kubernetes، وCheckov لفحص Terraform وCloudFormation، وHadolint لملفات Dockerfile، وAnsible-lint لدفاتر وأدوار Ansible، إضافة إلى Tfsec وTflint لممارسات Terraform وأمنه.
كما يشير إلى استخدام Trivy لفحص صور الحاويات والبنية التحتية كرمز، وConftest لتطبيق السياسات عبر OPA، وYamllint للتحقق العام من YAML، وActionlint لفحص سير عمل GitHub Actions. لكل أداة، وفق الطرح الوارد في المقال، صيغة إعداد ونموذج خطورة وتكامل مع CI وقصة صيانة خاصة بها.
النتيجة هي غياب معيار مشترك للجودة وحلقة تغذية راجعة داخل بيئة التطوير. كما لا يوجد تحليل عابر للمجالات؛ فلا يجري، مثلاً، تقييم وحدة Terraform التي تنشئ حاوية S3 عامة مع مخطط Helm الذي يعتمد عليها ضمن الصورة التحليلية نفسها.
ما الذي تقترحه الفكرة؟
يتصور المقال أداة لفحص DevOps تعمل ضمن تجربة Qodana المعروفة لفحص شيفرة التطبيقات، بحيث تعرض النتائج في واجهة موحّدة وبهيكل تقارير واحد ونموذج مشترك لدرجات الخطورة وبوابات الجودة. وبهذا يمكن لفرق التطوير الحصول على ملاحظات داخل بيئة التطوير، بينما تفرض عمليات CI معايير الجودة قبل الدمج أو البناء.
يقترح الطرح أيضاً أن تكون عملية التحليل قابلة للتوسعة، مع إمكانية إضافة موائمات تطورها المجتمعات لأدوات مثل Pulumi وCDK وGitLab CI عبر ملف qodana.yaml. كما يمكن لتقرير نظرة عامة أن يقدم صورة فورية عن حالة جودة البنية التحتية، من خلال إجمالي المشكلات، وعدد عمليات الفحص، وتوزيع النتائج حسب درجة الخطورة والفئة.
من فحص التطبيق إلى فحص المكدس بأكمله
يرى الكاتب أن القيمة الأعمق لا تكمن في اكتشاف إعداد خاطئ منفرد، بل في إنشاء معيار جودة مشترك لشيفرة البنية التحتية، على غرار المعيار المستخدم لشيفرة التطبيقات. ووفق هذا التصور، يمكن أن يغطي ملف إعداد واحد كلاً من شيفرة التطبيق وملفات DevOps، وأن تمتد القواعد عبر أكثر من طبقة، مثل العلاقة بين وحدة Terraform ومخطط Helm المرتبط بها.
هذا النهج يوسّع مفهوم التحول إلى اليسار ليشمل المكدس التقني بأكمله، بدلاً من حصره في طبقة التطبيق. كما يمكن أن يربط بصورة أوضح بين من يكتب البرمجيات ومن يشغّلها في الإنتاج، عبر وضع فحوص البنية التحتية ضمن سير العمل نفسه الذي تُراجع فيه الشيفرة وتُفرض فيه بوابات الجودة.
فكرة قيد الاستكشاف
يؤكد المقال أن Qodana DevOps Linter ليست منتجاً مطروحاً وفق المعلومات الواردة فيه، بل فكرة مبكرة تبحث Qodana في جدواها. لذلك يطلب من فرق الممارسة تحديد ما إذا كانت هذه الفجوة موجودة فعلاً في بيئاتها، وما المجال أو الأداة التي ترغب في تحليلها أولاً.
أهمية المقترح بالنسبة إلى فرق DevOps لا ترتبط بعدد الأدوات التي يمكن جمعها في واجهة واحدة فقط، بل بإمكانية وضع قواعد متسقة للموارد والأمان والسياسات والتشغيل قبل وصول التغييرات إلى الإنتاج. غير أن نجاح الفكرة سيعتمد عملياً على نطاق الأدوات المدعومة، ودقة التحليل العابر للمجالات، وقدرتها على الاندماج مع سير العمل القائم؛ وهي نقاط لم يحسمها المقال لأنها ما تزال ضمن مرحلة جمع الآراء.