قالب نشر يُستخدم فعليًا

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

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

قالب النشر يحل هذه المشكلة. إنه ليس مستندًا بيروقراطيًا. إنه شبكة أمان.

ماذا يفعل قالب النشر

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

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

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

المرحلة الأولى: البناء والتحقق

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

الخطوات واضحة:

إليك سير عمل GitHub Actions ينفذ المرحلة الأولى لتطبيق Node.js:

name: Build and Verify
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
      - run: npm run build
      - name: Push Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} registry.example.com/myapp:${{ github.sha }}
          docker push registry.example.com/myapp:${{ github.sha }}

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

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

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

المرحلة الثانية: النشر في بيئة الاختبار

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

الخطوات هنا تشمل:

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

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

المرحلة الثالثة: النشر في الإنتاج

هذه هي المرحلة الحرجة. المستخدمون الحقيقيون يعتمدون على تطبيقك. الأخطاء هنا تؤثر على العمل الحقيقي.

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

الخطوات هي:

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

إذا بدت المقاييس خاطئة، لا تنتظر. تقوم بتشغيل التراجع.

المرحلة الرابعة: خطة التراجع

كل نشر يحتاج إلى طريقة للعودة. ليست فكرة غامضة عن العودة. خطة ملموسة مكتوبة قبل بدء النشر.

خطة التراجع تجيب على ثلاثة أسئلة:

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

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

قائمة مراجعة عملية لنشر التطبيق

إليك قائمة مراجعة قصيرة يمكنك تكييفها لفريقك. ليست شاملة، لكنها تغطي الأساسيات.

البناء والتحقق

• تم التحقق من الكود من الفرع الموثوق
• البناء ناجح
• اختبارات الوحدة والتكامل ناجحة
• تم دفع الأرتيفكت إلى السجل

النشر في بيئة الاختبار

• تم سحب الأرتيفكت من السجل
• النشر اكتمل بدون أخطاء
• اختبارات الدخان ناجحة
• السجلات لا تظهر أخطاء غير متوقعة

النشر في الإنتاج

• لا يوجد نشر متزامن قيد التنفيذ
• تم استخدام الأرتيفكت من بيئة الاختبار
• تم تطبيق استراتيجية النشر التدريجي
• تم مراقبة المقاييس لمدة 10-15 دقيقة
• فحوصات الصحة ناجحة

خطة التراجع

• تم تعريف مشغل التراجع
• تم تحديد آلية التراجع
• تم تحديد صاحب القرار
• تم مشاركة الخطة والموافقة عليها قبل النشر

تكييف القالب لفريقك

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

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

الخلاصة

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