بوابات الجودة الآلية: كيف أنقذتنا من جحيم انتظار الموافقات اليدوية؟

يا جماعة الخير، السلام عليكم.

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

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

هذه الحادثة كانت الشرارة اللي خلتنا نتبنى مفهوم “بوابات الجودة الآلية” أو الـ Automated Quality Gates. ومن يومها، تغيرت طريقة شغلنا 180 درجة. تعالوا أحكيلكم القصة وما فيها.

ما هي بوابات الجودة (Quality Gates)؟ ولماذا هي ضرورية؟

ببساطة شديدة، بوابات الجودة هي نقاط تفتيش آلية (Automated Checkpoints) داخل خط أنابيب التكامل والنشر المستمر (CI/CD Pipeline). وظيفتها إنها تتأكد من جودة الكود بشكل تلقائي في كل مرحلة، وما تسمح للكود بالانتقال للمرحلة التالية إلا إذا استوفى مجموعة من المعايير المحددة مسبقًا. يعني بدل ما نضل نلاحق المدير الفلاني أو مسؤول الجودة العلاني عشان ناخذ موافقتهم، الروبوت (السكريبت) هو اللي بفحص وبعطي الضوء الأخضر أو الأحمر.

الفرق بين الموافقات اليدوية والبوابات الآلية

عشان الصورة تكون أوضح، خلينا نقارن بين الطريقتين:

• الموافقات اليدوية: بطيئة، عرضة للخطأ البشري والنسيان، تعتمد على شخص واحد (Single Point of Failure)، وتخلق حالة من “عنق الزجاجة” (Bottleneck) في عملية التسليم.
• البوابات الآلية: سريعة جدًا (تتم في ثوانٍ أو دقائق)، متسقة وموحدة (تطبق نفس المعايير على الكل)، موضوعية (لا تعرف فلان أو علان)، وتوفر تغذية راجعة (Feedback) فورية للمطور.

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

كيف تبدو بوابات الجودة على أرض الواقع؟

تخيل خط الـ CI/CD تبعك كأنه خط إنتاج في مصنع. كل مرحلة هي محطة، وكل بوابة جودة هي عامل آلي بفحص المنتج قبل ما يروح للمحطة اللي بعدها. هاي أشهر البوابات اللي بنستخدمها:

بوابة التجميع والبناء (Build Gate)

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

بوابة التحليل الساكن للكود (Static Code Analysis Gate)

هون بتبلش الجودة الحقيقية. بنستخدم أدوات مثل SonarQube أو linter عشان تفحص الكود بدون ما تشغله. هاي البوابة بتجاوب على أسئلة مهمة:

• هل هناك “روائح كريهة في الكود” (Code Smells)؟
• هل يوجد كود مكرر (Duplicated Code)؟
• هل هناك ثغرات أمنية محتملة (Potential Vulnerabilities)؟
• هل يتبع الكود معايير الكتابة المتفق عليها في الفريق (Coding Standards)؟

نصيحة من أبو عمر: لا تكن قاسيًا في البداية. ابدأ بمعايير بسيطة. مثلًا، يمكنك وضع شرط “يجب ألا يحتوي الكود الجديد على أي ثغرات أمنية حرجة (Blocker or Critical)” أو “نسبة الكود المكرر يجب أن تكون أقل من 5%”. مع الوقت، يمكنك تشديد هذه المعايير.

بوابة اختبارات الوحدة والتكامل (Unit & Integration Testing Gate)

بعد ما تأكدنا إن الكود مكتوب كويس، لازم نتأكد إنه بيشتغل صح. هاي البوابة بتقوم بتشغيل كل اختبارات الوحدة (Unit Tests) واختبارات التكامل (Integration Tests) بشكل آلي.

المعيار الأهم هنا هو “تغطية الكود” (Code Coverage). يعني كم نسبة الكود اللي تم اختبارها؟ بوابة الجودة ممكن تفشل إذا كانت التغطية أقل من نسبة معينة (مثلًا 80%). هذا الشرط بيجبر المطورين على كتابة اختبارات للكود الجديد تبعهم.

بوابة فحص الأمان (Security Scanning Gate)

هاي البوابة مهمة جدًا جدًا. بتقوم بفحص الاعتماديات (Dependencies) أو المكتبات الخارجية اللي بنستخدمها في المشروع بحثًا عن أي ثغرات أمنية معروفة. أدوات مثل OWASP Dependency-Check أو Snyk ممتازة لهي المهمة. ممكن البوابة تفشل إذا تم اكتشاف ثغرة حرجة في مكتبة ما، وتعطي المطور تنبيهًا لتحديثها فورًا.

مثال عملي: بناء بوابة جودة باستخدام Jenkins و SonarQube

خلينا نشوف كيف ممكن نطبق هذا الكلام بشكل عملي. لنفترض أننا نستخدم Jenkins كأداة CI/CD و SonarQube للتحليل الساكن للكود. ممكن نكتب الـ Jenkinsfile (وهو ملف يصف الـ pipeline) كالتالي:

الخطوة الأولى: إعداد الأدوات

طبعًا لازم يكون عندك Jenkins و SonarQube منصبين ومربوطين ببعض. في Jenkins، ستحتاج إلى إضافة SonarQube Scanner plugin.

الخطوة الثانية: كتابة الـ Jenkinsfile

هذا مثال مبسط لملف Jenkinsfile يوضح الفكرة:

pipeline {
    agent any
    
    tools {
        // تحديد نسخة الـ JDK والـ Maven المستخدمة
        maven 'Maven-3.8.5'
        jdk 'JDK-11'
    }

    stages {
        stage('Build') {
            steps {
                // خطوة بناء المشروع باستخدام Maven
                sh 'mvn clean install'
            }
        }
        
        stage('Unit Tests') {
            steps {
                // خطوة تشغيل اختبارات الوحدة وجمع نتائج التغطية
                sh 'mvn test'
            }
        }
        
        stage('SonarQube Analysis') {
            steps {
                // إعداد SonarQube Scanner
                withSonarQubeEnv('My-SonarQube-Server') {
                    // تشغيل التحليل
                    sh 'mvn sonar:sonar'
                }
            }
        }
        
        stage('Quality Gate Check') {
            steps {
                // هذه هي بوابة الجودة!
                // انتظر نتيجة التحليل من SonarQube
                // timeout يضمن أن الـ pipeline لا يبقى معلقًا للأبد
                timeout(time: 1, unit: 'HOURS') {
                    // waitForQualityGate سيفشل الـ build إذا كانت نتيجة البوابة FAILED
                    waitForQualityGate abortPipeline: true
                }
            }
        }
        
        stage('Deployment to Staging') {
            // هذه المرحلة لن يتم الوصول إليها إلا إذا نجحت كل البوابات السابقة
            steps {
                echo 'Quality Gate Passed! Deploying to Staging environment...'
                // هنا تضع أوامر النشر (Deployment commands)
            }
        }
    }
}

الخطوة الثالثة: تفسير النتائج

في هذا المثال، الـ pipeline سيمر بالمراحل التالية:

1. Build: يبني المشروع. إذا فشل، يتوقف كل شيء.
2. Unit Tests: يشغل الاختبارات.
3. SonarQube Analysis: يرسل الكود إلى سيرفر SonarQube ليقوم بتحليله في الخلفية.
4. Quality Gate Check: هنا مربط الفرس. الـ pipeline سيتوقف وينتظر من SonarQube نتيجته. في SonarQube نفسه، نكون قد عرفنا بوابة الجودة (مثلًا: Coverage > 80%, No new bugs, etc.). إذا كانت نتيجة البوابة “PASSED”، سيكمل الـ pipeline. إذا كانت “FAILED”، سيفشل الـ pipeline بالكامل ويمنع الكود من الوصول لمرحلة النشر.

بهذه الطريقة، حولنا عملية الفحص والموافقة من مهمة يدوية بطيئة إلى خطوة آلية سريعة وموثوقة ضمن الـ pipeline.

نصائح من خبرة “أبو عمر”

بعد سنين من تطبيق هاي المنهجية، تعلمت كم درس حابب أشارككم فيها:

• ابدأ صغيرًا وتدرّج: لا تحاول بناء نظام بوابات معقد من أول يوم. ابدأ ببوابة واحدة بسيطة (مثل Build ناجح). ثم أضف بوابة اختبارات الوحدة، ثم التحليل الساكن، وهكذا. التدرج هو مفتاح النجاح.
• لا تجعل البوابات عقابًا: الهدف هو مساعدة المطورين على كتابة كود أفضل، وليس معاقبتهم. تأكد أن رسائل الفشل واضحة، وأن الأدوات توفر تقارير سهلة الفهم تساعد المطور على إصلاح المشكلة بسرعة.
• اجعل المعايير منطقية ومرنة: لا تضع معيار “تغطية 95%” على مشروع قديم لم تكتب له اختبارات من قبل. ابدأ بمعايير منطقية للمشروع الحالي، وركز على “الجودة في الكود الجديد” (Quality on New Code).
• الثقافة أهم من الأدوات: الأدوات وحدها لا تكفي. يجب أن يؤمن الفريق بأكمله بأهمية الجودة. “الشغل مش بس كود يا جماعة، الشغل ثقافة وفريق”. عقد اجتماعات دورية لمناقشة معايير الجودة وتطويرها هو جزء لا يتجزأ من العملية.

الخلاصة: من الانتظار القاتل إلى الثقة الكاملة 🚀

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

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