من الالتزام إلى النشر الكامل: بناء خط أنابيب توصيل تدريجي

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

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

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

يُظهر مخطط التدفق التالي مراحل خط الأنابيب في لمحة:

flowchart TD A[Commit / Merge] --> B[Build & Tests] B --> C[Canary Ring<br>1% traffic] C --> D{Monitor Metrics} D -- Pass --> E[Staged Rollout<br>10% → 25% → 50%] D -- Fail --> F[Auto Rollback] E --> G{Monitor & Gate} G -- Pass --> H[Full Rollout<br>100%] G -- Fail --> F H --> I[Flag Cleanup] F --> J[Notify Team]

البناء والاختبارات الأساسية

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

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

حلقة الكناري: أول اختبار حقيقي لك

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

فيما يلي مثال على GitLab CI يحدد خطوات حلقة الكناري والنشر المرحلي:

stages:
  - canary
  - staged-rollout
  - full-rollout

canary-deploy:
  stage: canary
  script:
    - kubectl set image deployment/my-app canary=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app --replicas=1
  environment:
    name: production/canary
    url: https://canary.example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

auto-promote:
  stage: staged-rollout
  script:
    - sleep 600  # 10-minute monitoring window
    - ./check-metrics.sh  # verify error rate, latency within SLO
    - kubectl set image deployment/my-app-10pct my-app=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app-10pct --replicas=2
  needs: ["canary-deploy"]
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

rollout-50pct:
  stage: staged-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app-50pct my-app=my-app:$CI_COMMIT_SHA
  needs: ["auto-promote"]
  when: manual  # requires manual approval

rollout-100pct:
  stage: full-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app my-app=$CI_COMMIT_SHA
  needs: ["rollout-50pct"]
  when: manual

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

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

النشر المرحلي: توسيع الجمهور

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

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

تنظيف أعلام الميزات

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

ما الذي يجعل خط الأنابيب هذا مختلفًا

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

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

قائمة التحقق العملية لخط الأنابيب الخاص بك

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

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

الخلاصة

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

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