عندما يقرر خط الأنابيب من يوافق على النشر

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

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

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

لماذا لا يعمل نموذج الموافقة الواحد للجميع

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

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

كيف يمكن لخط الأنابيب تقييم المخاطرة تلقائيًا

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

قد تبدو مجموعة بسيطة من القواعد على هذا النحو:

إليك كيفية ترجمة هذا المنطق إلى تكوين خط أنابيب GitLab CI:

stages:
  - test
  - deploy

deploy:
  stage: deploy
  script:
    - echo "Deploying to production..."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "db/**/*"
        - "config/**/*"
      when: manual
      allow_failure: false
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "docs/**/*"
        - "README.md"
      when: on_success
    - when: on_success
  • تغييرات في ملفات docs/ أو README.md: 0 نقاط
  • تغييرات في ملفات التكوين (.env, config/): 3 نقاط
  • تغييرات في منطق الأعمال في src/: 7 نقاط
  • تغييرات في وحدات الدفع أو المصادقة: 20 نقطة
  • تغييرات في ملفات ترحيل قاعدة البيانات: 25 نقطة

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

ربط درجات المخاطرة بسياسات النشر

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

يوضح المخطط الانسيابي التالي كيفية ربط خط الأنابيب لدرجات المخاطرة بسياسات النشر:

flowchart TD A[تم تقديم التغيير] --> B{فحص الملفات المغيَّرة} B --> C[تعيين درجة المخاطرة] C --> D{الدرجة <= 5؟} D -->|نعم| E[مخاطرة منخفضة] E --> F[موافقة تلقائية] F --> G[نشر إلى الإنتاج] D -->|لا| H{الدرجة 6-15؟} H -->|نعم| I[مخاطرة متوسطة] I --> J[يتطلب موافقة زميل واحد] J --> G H -->|لا| K[مخاطرة عالية] K --> L[يتطلب موافقتين] L --> M[نشر إلى بيئة الاختبار] M --> N[تشغيل اختبارات التدخين والمراقبة] N --> O{الفحوصات ناجحة؟} O -->|نعم| G O -->|لا| P[حظر النشر]

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

مخاطرة متوسطة (درجة 6-15): يحتاج التغيير إلى موافقة واحدة من زميل أو مهندس أول. يتوقف خط الأنابيب بعد نجاح الاختبارات وينتظر توقيعًا يدويًا قبل المتابعة إلى الإنتاج.

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

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

الفائدة الحقيقية هي الاتساق، وليس الدقة المطلقة

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

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

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

كيف يغير هذا سلوك الفريق

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

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

قائمة ممارسة عملية لإعداد تسجيل المخاطرة

إذا كنت ترغب في تنفيذ هذا النهج، إليك قائمة ممارسة للبدء:

  • حدد المجلدات وأنماط الملفات التي تمثل مستويات مخاطرة مختلفة في قاعدة الشيفرات الخاصة بك
  • حدد نظام تسجيل بقيم نقاط واضحة لكل نمط
  • عيّن حدودًا للمخاطرة المنخفضة والمتوسطة والعالية في كل بيئة
  • حدد سياسة النشر لكل مستوى مخاطرة (الموافقات المطلوبة، وقت بيئة الاختبار، فحوصات المراقبة)
  • قم بتنفيذ منطق تسجيل المخاطرة في تكوين خط أنابيب CI/CD الخاص بك
  • قم بتشغيل التسجيل على كل طلب سحب وسجل النتائج للرؤية
  • راجع قواعد التسجيل بعد شهر واضبطها بناءً على ما تتعلمه

يصبح خط الأنابيب صانع قرار

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

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