إرسال إشعارات فورية إلى Telegram أو Slack عند نجاح أو فشل نشر التحديثات

إرسال إشعارات فورية إلى Telegram أو Slack عند نجاح أو فشل نشر التحديثات

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

إذا كنت قد قرأت مقال ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟ فستعرف أن الهدف من الأتمتة ليس السرعة فقط، بل بناء سلسلة قرارات قابلة للملاحظة والقياس. والإشعارات هنا تمثل الطبقة الأخيرة من خط الأنابيب؛ فهي تربط نتائج التنفيذ بالأشخاص المسؤولين مباشرة.

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

لماذا تعتبر الإشعارات جزءاً من معمارية النشر وليست مجرد إضافة تجميلية؟

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

الإشعار الجيد لا يقول “تم” أو “فشل” فقط، بل يرسل سياقاً تشغيلياً مثل:

• اسم المشروع أو الخدمة.
• بيئة النشر: staging أو production.
• اسم الفرع أو رقم commit.
• رابط المهمة التنفيذية للتحقيق السريع.
• سبب الفشل إن أمكن، مثل تعطل اختبار أو رفض اتصال SSH.

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

المكونات الأساسية لإرسال الإشعارات

قبل كتابة أي تكامل، ستحتاج عادة إلى ثلاثة عناصر:

1. قناة استقبال في Telegram أو Slack.
2. بيانات اعتماد مثل Bot Token أو Webhook URL.
3. مرحلة داخل خط النشر ترسل الطلب عند نجاح المهمة أو فشلها.

في Telegram غالباً ستستخدم واجهة sendMessage API مع رقم chat_id. أما في Slack فالأبسط هو Incoming Webhook الذي يستقبل حمولة JSON.

لا تضع مفاتيح API أو روابط Webhook مباشرة داخل المستودع. استخدم الأسرار المشفرة كما شرحنا في إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة، لأن أي تسريب قد يسمح لطرف خارجي بإرسال رسائل مزيفة أو كشف بنية التشغيل.

تنفيذ الإشعار داخل GitHub Actions

إذا كنت قد اطلعت على مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow)، فإضافة الإشعارات تكون عادة في الخطوة الأخيرة من ملف workflow. الفكرة هي تنفيذ خطوة عند النجاح، وأخرى عند الفشل، مع الاستفادة من تعبيرات الحالة.

مثال إرسال إشعار إلى Telegram بعد النشر

name: Deploy and Notify

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Run deployment
        run: |
          echo "Deploying application..."
          ./deploy.sh

      - name: Notify Telegram on success
        if: success()
        run: |
          curl -s -X POST "https://api.telegram.org/bot${{ secrets.TELEGRAM_BOT_TOKEN }}/sendMessage" \
            -d "chat_id=${{ secrets.TELEGRAM_CHAT_ID }}" \
            -d "text=✅ Deployment succeeded for ${GITHUB_REPOSITORY} on branch ${GITHUB_REF_NAME}"

      - name: Notify Telegram on failure
        if: failure()
        run: |
          curl -s -X POST "https://api.telegram.org/bot${{ secrets.TELEGRAM_BOT_TOKEN }}/sendMessage" \
            -d "chat_id=${{ secrets.TELEGRAM_CHAT_ID }}" \
            -d "text=❌ Deployment failed for ${GITHUB_REPOSITORY} on branch ${GITHUB_REF_NAME}. Check run: https://github.com/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"

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

مثال إرسال إشعار إلى Slack

- name: Notify Slack on failure
  if: failure()
  run: |
    curl -X POST -H "Content-type: application/json" \
      --data '{
        "text": "❌ Deployment failed for '${{ github.repository }}' on branch '${{ github.ref_name }}'. Details: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}"
      }' \
      ${{ secrets.SLACK_WEBHOOK_URL }}

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

تنفيذ نفس الفكرة داخل Jenkins

في بيئات كثيرة لا يزال Jenkins هو المحرك الأساسي للأتمتة، خاصة في البنى الهجينة أو داخل الشبكات الخاصة. هنا نستخدم مقطع post داخل ملف Jenkinsfile لإرسال التنبيه.

pipeline {
  agent any

  stages {
    stage('Deploy') {
      steps {
        sh './deploy.sh'
      }
    }
  }

  post {
    success {
      sh '''
        curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
        -d "chat_id=$TELEGRAM_CHAT_ID" \
        -d "text=✅ Jenkins deployment succeeded for $JOB_NAME build #$BUILD_NUMBER"
      '''
    }
    failure {
      sh '''
        curl -s -X POST "$SLACK_WEBHOOK_URL" \
        -H "Content-type: application/json" \
        --data "{\\"text\\":\\"❌ Jenkins deployment failed for $JOB_NAME build #$BUILD_NUMBER\\"}"
      '''
    }
  }
}

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

كيف تصمم رسالة مفيدة فعلاً للفريق؟

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

• ماذا حدث؟ نجاح أم فشل.
• أين حدث؟ أي خدمة أو بيئة.
• ما النسخة المتأثرة؟ فرع، وسم، أو commit SHA.
• أين أذهب الآن؟ رابط التنفيذ أو السجل.

يمكنك أيضاً إضافة مؤشرات ذكية مثل مدة النشر، الشخص الذي نفّذ push، واسم الخادم الهدف. هذا مهم جداً في المشاريع متعددة البيئات أو عند نشر خدمات مبنية بحاويات Docker كما ناقشنا في مشكلة “الكود يعمل على جهازي فقط” وكيف يحلها Docker نهائياً؟.

أفضل الممارسات الأمنية والتشغيلية

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

ومن أفضل الممارسات كذلك:

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

كما يُستحسن ربط الإشعارات بسياسات حماية الفروع قبل الوصول إلى النشر، خاصة إن كنت تطبق ما ورد في حماية الفروع (Branch Protection) ومنع رفع الأكواد الخاطئة للنسخة الحية. فالإشعار ليس بديلاً عن الضوابط الوقائية، بل طبقة مكملة لها.

متى تستخدم Telegram ومتى تستخدم Slack؟

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

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

الخلاصة

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

ابدأ برسالة بسيطة، ثم حسّنها تدريجياً لتشمل السياق والروابط والمؤشرات المهمة. ومع دمجها داخل GitHub Actions أو Jenkins بشكل صحيح، ستقلل زمن الاستجابة للحوادث وترفع شفافية النشر داخل فريقك بشكل ملموس.