ثقافة DevOps وأساسياتها

كيف تُطلق شركات التقنية الكبرى برمجياتها

18 دقيقة الدرس 4 من 28

كيف تُطلق شركات التقنية الكبرى برمجياتها

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

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

لماذا تُعدّ تكرارية النشر مؤشراً قيادياً على الجودة

ثمة حقيقة مضادة للحدس تُقوّض ممارسات DevOps الحديثة كلها: كلما نشرت أكثر، كان كل نشر أكثر أماناً لا أكثر خطورة. إليك الآلية:

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

وجد تقرير DORA لحالة DevOps 2023 أن المؤدين المتميزين ينشرون عند الطلب (عدة مرات في اليوم) ولديهم معدل فشل تغيير أقل من 5٪ — وهو أقل من الفرق ذات الأداء المنخفض التي تنشر شهرياً. التكرارية والاستقرار مترابطان إيجابياً وليسا متعارضين.

التطوير القائم على الجذع (Trunk-Based Development)

تكرارية نشر الفرق المتميزة ممكنة فقط بسبب استراتيجية تفريع محددة: التطوير القائم على الجذع. يُودع كل مهندس مباشرةً في فرع مشترك واحد — يُسمى عادةً main أو trunk — مرة واحدة على الأقل يومياً، دون فروع ميزات ذات عمر طويل.

يبدو هذا مقلقاً في البداية. ألن يُخرب الجميع عمل بعضهم؟ الجواب لا — لأن هذا النهج يقترن بممارستين تكميليتين:

أعلام الميزات (Feature Flags) — يُدمج الكود في الجذع خلف علم مُغلق في الإنتاج، فيُفصل الكود عن إطلاقه. يمكنك دمج كود مظلم باستمرار وتشغيل العلم حين يصبح المنتج جاهزاً.
اختبارات آلية شاملة — مجموعة اختبارات سريعة وموثوقة (وحدة + تكامل، تُنفّذ في أقل من 10 دقائق) هي الشرط غير القابل للتفاوض. إنها شبكة الأمان التي تُبقي الجذع قابلاً للنشر دائماً.

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

يسار: فروع الميزات طويلة العمر تراكم ديون التكامل. يمين: التطوير القائم على الجذع بفروع قصيرة تُدمج يومياً يُبقي الجذع قابلاً للنشر دائماً.

الدُّفعات الصغيرة: الصلة بالتصنيع الرشيق

مبدأ الدُّفعات الصغيرة مستمد مباشرة من نظام تويوتا للتصنيع. في المصنع، إن ختمت 1,000 قطعة قبل اكتشاف أن القالب معطّل، أتلفت 1,000 قطعة. أما إن ختمت واحدة وفحصتها، فأنت تُتلف واحدة فقط. البرمجيات لها نفس الاقتصاد — لكن الفرق كثيراً ما تُكدّس أسابيع من العمل قبل الحصول على تغذية راجعة من الإنتاج.

عملياً، تعني الدُّفعات الصغيرة في البرمجيات:

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

في جوجل، المبدأ التوجيهي هو أن قائمة التغييرات (CL — مصطلحهم للـ PR) يجب أن تكون صغيرة بما يكفي لاستيعابها دفعة واحدة في ذهن المراجع. إن احتاج المراجع إلى التنقل الذهني بين أجزاء، فالـ CL أكبر مما ينبغي. الهدف الجيد هو أقل من 200 سطر متغير؛ أما الـ CL التي تتجاوز 400 سطر فينبغي التشكيك فيها.

مقاييس DORA بوصفها بوصلة

تُغطّى مقاييس DORA الأربعة (تكرارية النشر، وزمن الاستجابة للتغييرات، ومعدل فشل التغيير، والوقت المتوسط للاستعادة) بعمق في الدرس الخامس. هنا تظهر بوصفها طبقة قياس للممارسات المذكورة أعلاه — تجيب على سؤال: هل نحن نتحسن فعلاً؟

الفريق الذي يتجه نحو التطوير القائم على الجذع ودُفعات أصغر يجب أن يلاحظ هذه المسارات في المقاييس خلال 3-6 أشهر:

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

كيف يبدو خط أنابيب الإنتاج في النخبة

في شركات مثل Shopify وGitHub وNetflix، كل إيداع في الجذع يُطلق خط أنابيب آلي يعمل بالتوازي للحفاظ على حلقة التغذية الراجعة تحت 10 دقائق:

# خط أنابيب GitHub Actions المبسّط — يُشغّل عند كل push إلى main
name: CI/CD Pipeline

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run unit tests
        run: make test-unit
      - name: Run integration tests
        run: make test-integration
      - name: Static analysis
        run: make lint

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build & push container image
        run: |
          docker build -t registry.example.com/app:${{ github.sha }} .
          docker push registry.example.com/app:${{ github.sha }}

  deploy-canary:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to 5% of traffic (canary)
        run: |
          kubectl set image deployment/app \
            app=registry.example.com/app:${{ github.sha }}
          kubectl annotate deployment/app \
            traffic-weight=5

  promote-to-stable:
    needs: deploy-canary
    runs-on: ubuntu-latest
    steps:
      - name: Wait for canary health check
        run: ./scripts/wait-for-canary.sh --timeout 300
      - name: Promote to 100% traffic
        run: kubectl annotate deployment/app traffic-weight=100

خطوة الكناري هي آلية الأمان الأساسية في الإنتاج. بدلاً من تحويل كل الحركة دفعة واحدة، يوجّه خط الأنابيب 5٪ من طلبات الإنتاج إلى الإصدار الجديد. تعمل فحوصات الصحة الآلية (معدل الأخطاء، وزمن الاستجابة p99، والإشباع) لمدة خمس دقائق. إن نجحت، يكتمل الطرح. وإن فشلت، يُعاد نشر الإصدار السابق تلقائياً — ويُرسل خط الأنابيب تنبيهاً على Slack بالمقياس الفاشل.

الشرط المُسبق الخفي: لا شيء من هذا يعمل بدون قابلية المراقبة — سجلات منظمة ومقاييس وآثار — موجودة مسبقاً. خطوة كناري لا تستطيع الاستعلام عن معدلات الخطأ تنتظر بشكل أعمى فحسب. ابنِ مجموعة القياس والرصد قبل أتمتة النشر. قابلية المراقبة مغطاة في دروس لاحقة؛ ضعها في ذهنك بوصفها عائقاً لتحقيق تكرارية النشر على مستوى النخبة.

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

أعلام الميزات هي الغراء الذي يربط التطوير القائم على الجذع بإدارة إصدارات المنتج. أبسط تطبيق هو متغير بيئي؛ الأنظمة الإنتاجية تستخدم خدمة أعلام (LaunchDarkly أو Unleash أو Flipt أو نظاماً محلياً مبنياً على Redis hash) حتى يمكن تبديل الأعلام دون إعادة نشر.

# كود توضيحي: تغليف تدفق الدفع الجديد خلف علم
# يُقيَّم العلم في وقت التشغيل — لا إعادة نشر لتفعيله أو تعطيله

if feature_enabled('new_checkout_flow', user_id=current_user.id):
    render_new_checkout()
else:
    render_legacy_checkout()

# إعداد العلم في Unleash / LaunchDarkly:
# {
#   "flag": "new_checkout_flow",
#   "rollout": "percentage",
#   "percentage": 10,      # 10% من المستخدمين يرون التدفق الجديد
#   "targeting": {
#     "segment": "beta_users"
#   }
# }

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

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

النقاط الرئيسية

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