أفضل الممارسات لخط أنابيب CI/CD: أتمتة طريقك إلى عمليات نشر موثوقة

**تنشر الفرق التي لديها خطوط أنابيب CI/CD ناضجة بمعدل 208 مرات أكثر من تلك التي لا تملكها، بينما تشهد معدلات فشل تغيير أقل بمقدار 7 مرات. ** يعود الفرق بين خط الأنابيب الهش "الذي يعمل في الغالب" ونظام النشر الذي تم اختباره في المعركة إلى عدد قليل من الممارسات التي تفصل أتمتة الهواة عن البنية التحتية لمستوى الإنتاج.

يغطي هذا الدليل الممارسات والتكوينات والقرارات المعمارية الملموسة التي تجعل خطوط أنابيب CI/CD موثوقة على نطاق واسع.

الوجبات الرئيسية

• يؤثر وقت تنفيذ المسار بشكل مباشر على إنتاجية المطور --- الهدف أقل من 10 دقائق للمجموعة الكاملة
• يلتقط الفحص الأمني في CI 85% من الثغرات الأمنية قبل وصولها إلى مرحلة الإنتاج
• تعمل آليات التراجع التلقائية على تقليل متوسط الوقت اللازم للتعافي من ساعات إلى دقائق
• قواعد حماية الفرع وفحوصات الحالة المطلوبة تمنع وصول التعليمات البرمجية المعطلة إلى الصفحة الرئيسية

---

هندسة خطوط الأنابيب

نموذج المراحل الخمس

يجب أن ينفذ كل خط أنابيب CI/CD للإنتاج خمس مراحل:

المرحلة 1: الفحص والتحقق (الهدف: أقل من دقيقتين)

lint:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: pnpm
    - run: pnpm install --frozen-lockfile
    - run: pnpm lint
    - run: pnpm typecheck

المرحلة الثانية: الاختبار (الهدف: أقل من 8 دقائق)

test:
  runs-on: ubuntu-latest
  services:
    postgres:
      image: postgres:17
      env:
        POSTGRES_PASSWORD: test
        POSTGRES_DB: test
      ports:
        - 5432:5432
      options: >-
        --health-cmd pg_isready
        --health-interval 10s
        --health-timeout 5s
        --health-retries 5
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: pnpm
    - run: pnpm install --frozen-lockfile
    - run: pnpm test
      env:
        DATABASE_URL: postgresql://postgres:test@localhost:5432/test

المرحلة 3: البناء (الهدف: أقل من 5 دقائق)

قم ببناء صور Docker، وتجميع الأصول، وإنشاء حزم الإنتاج. تبعيات ذاكرة التخزين المؤقت بقوة.

المرحلة 4: النشر إلى التدريج

النشر التلقائي عند الدمج إلى الرئيسي. قم بإجراء اختبارات الدخان على بيئة التدريج.

المرحلة 5: النشر إلى الإنتاج

بوابة موافقة يدوية أو آلية بعد اجتياز عملية التحقق من الصحة.

---

تحسين السرعة

تؤدي خطوط الأنابيب البطيئة إلى قتل إنتاجية المطورين. كل دقيقة من وقت انتظار CI مضروبة في الفريق تؤدي إلى ساعات من فقدان وقت تبديل السياق.

التوازي

تشغيل وظائف مستقلة في وقت واحد:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [...]

  test-unit:
    runs-on: ubuntu-latest
    steps: [...]

  test-integration:
    runs-on: ubuntu-latest
    steps: [...]

  test-e2e:
    runs-on: ubuntu-latest
    steps: [...]

  build:
    needs: [lint, test-unit, test-integration, test-e2e]
    runs-on: ubuntu-latest
    steps: [...]

التخزين المؤقت للتبعية

- uses: actions/cache@v4
  with:
    path: |
      ~/.pnpm-store
      node_modules
      apps/*/node_modules
      packages/*/node_modules
    key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}
    restore-keys: |
      ${{ runner.os }}-pnpm-

التخزين المؤقت لطبقة عامل الميناء

- uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: registry.example.com/app:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

معايير سرعة خطوط الأنابيب

---

المسح الأمني

فحص الثغرات الأمنية في التبعية

security:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - name: Run Snyk to check for vulnerabilities
      uses: snyk/actions/node@master
      env:
        SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      with:
        args: --severity-threshold=high

    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: fs
        scan-ref: .
        severity: CRITICAL,HIGH
        exit-code: 1

المسح السري

    - name: Detect secrets
      uses: trufflesecurity/trufflehog@main
      with:
        extra_args: --only-verified

SAST (اختبار أمان التطبيقات الثابتة)

    - name: CodeQL Analysis
      uses: github/codeql-action/analyze@v3
      with:
        languages: javascript-typescript

سياسة البوابة الأمنية

---

استراتيجية حماية الفروع ودمجها

الشيكات الحالة المطلوبة

قم بتكوينها كفحوصات الحالة المطلوبة في الفرع الرئيسي:

1. يجب اجتياز فحص الوبر والطباعة
2. يجب اجتياز جميع اختبارات الوحدة
3. يجب اجتياز جميع اختبارات التكامل
4. يجب ألا يحتوي الفحص الأمني على نتائج حرجة/عالية
5. يجب أن ينجح البناء

استراتيجية الدمج

استخدم عمليات دمج الاسكواش لفروع المعالم للحفاظ على سجل نظيف:

main: A --- B --- C --- D (each is a squashed feature)

تتطلب موافقة واحدة على الأقل لممثلي العلاقات العامة. بالنسبة للمسارات المهمة (المصادقة، والفوترة، وترحيل قاعدة البيانات)، يلزم الحصول على موافقتين.

---

استراتيجيات النشر

النشر باللونين الأزرق والأخضر

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

#!/bin/bash
# blue-green-deploy.sh

CURRENT=$(kubectl get service production -o jsonpath='{.spec.selector.version}')

if [ "$CURRENT" == "blue" ]; then
  TARGET="green"
else
  TARGET="blue"
fi

echo "Current: $CURRENT, deploying to: $TARGET"

# Deploy to inactive environment
kubectl set image deployment/$TARGET-app app=registry.example.com/app:$TAG

# Wait for rollout
kubectl rollout status deployment/$TARGET-app --timeout=300s

# Run smoke tests against target
curl -sf "http://$TARGET.internal/health" || exit 1

# Switch traffic
kubectl patch service production -p "{\"spec\":{\"selector\":{\"version\":\"$TARGET\"}}}"

echo "Traffic switched to $TARGET"

النشر المتداول

تحديث القرون بشكل تدريجي:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 0

maxUnavailable: 0 يضمن عدم فقدان القدرة أثناء النشر.

نشر الكناري

قم بتوجيه نسبة صغيرة من حركة المرور إلى الإصدار الجديد:

# Using Istio for traffic splitting
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app-canary
spec:
  hosts:
    - app.example.com
  http:
    - route:
        - destination:
            host: app-stable
          weight: 95
        - destination:
            host: app-canary
          weight: 5

لمزيد من إستراتيجيات النشر، راجع دليلنا المخصص حول عمليات النشر بدون توقف.

---

أتمتة التراجع

التراجع التلقائي عند فشل التحقق من الصحة

deploy-production:
  runs-on: ubuntu-latest
  steps:
    - name: Deploy
      run: |
        kubectl set image deployment/app app=${{ env.IMAGE }}
        kubectl rollout status deployment/app --timeout=300s

    - name: Smoke tests
      run: |
        sleep 30
        STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://app.example.com/health)
        if [ "$STATUS" != "200" ]; then
          echo "Health check failed with status $STATUS"
          kubectl rollout undo deployment/app
          exit 1
        fi

    - name: Monitor error rate
      run: |
        # Check error rate over 5 minutes
        ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~'5..'}[5m])/rate(http_requests_total[5m])" | jq '.data.result[0].value[1]' -r)
        if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
          echo "Error rate $ERROR_RATE exceeds threshold"
          kubectl rollout undo deployment/app
          exit 1
        fi

---

تحسين خط أنابيب Monorepo

بالنسبة لمشاريع monorepo (مثل تلك التي تستخدم Turborepo)، قم بتشغيل ما تغير فقط:

- name: Determine affected packages
  id: affected
  run: |
    AFFECTED=$(npx turbo run build --filter='...[HEAD~1]' --dry-run=json | jq -r '.packages[]')
    echo "packages=$AFFECTED" >> $GITHUB_OUTPUT

- name: Test affected packages
  if: steps.affected.outputs.packages != ''
  run: npx turbo run test --filter='...[HEAD~1]'

يؤدي هذا إلى تقليل وقت CI بنسبة 60-80% للتغييرات التي تؤثر فقط على حزمة واحدة في monorepo كبيرة.

---

الأسئلة المتداولة

كم مرة يجب علينا النشر في الإنتاج؟

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

هل يجب أن نستخدم التطوير القائم على الجذع أو الفروع المميزة؟

تعمل الفروع المميزة ذات العمر القصير (1-3 أيام) بشكل أفضل لمعظم الفرق. يتطلب التطوير القائم على الجذع بنية تحتية أكثر نضجًا للاختبار وأعلام الميزات. الشيء المهم هو أن الفروع قصيرة العمر --- تؤدي الفروع المميزة طويلة العمر إلى إنشاء تعارضات مدمجة وتأخير ردود الفعل.

كيف نتعامل مع عمليات ترحيل قاعدة البيانات في CI/CD؟

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

ما هو هرم الاختبار الصحيح لـ CI؟

بالنسبة لتطبيق ويب نموذجي: 70% من اختبارات الوحدة (سريعة ومعزولة)، و20% من اختبارات التكامل (نقاط نهاية واجهة برمجة التطبيقات، واستعلامات قاعدة البيانات)، و10% من اختبارات E2E (تدفقات المستخدم المهمة). يتم تشغيل اختبارات الوحدة عند كل التزام. يتم إجراء اختبارات التكامل على العلاقات العامة. يتم تشغيل اختبارات E2E عند الدمج مع الرئيسي أو قبل نشر الإنتاج.

---

ما يأتي بعد ذلك

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

اتصل بـ ECOSIRE لتصميم وتنفيذ مسارات CI/CD، أو استكشف دليل DevOps للشركات الصغيرة للحصول على خريطة طريق البنية التحتية الكاملة.

---

تم النشر بواسطة ECOSIRE - لمساعدة الشركات على نشر البرامج بثقة.