التكامل والنشر المستمر (CI/CD)

طريقان إلى نفس الفكرة

قبل أن تبدأ

الفكرة الجوهرية

1أول workflow

ملف واحد يفحص ويختبر كل push وطلب دمج على إصدارين من بايثون:

# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python: ["3.12", "3.13"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python }}
          cache: pip
      - run: pip install -r requirements.txt
      - run: ruff check .
      - run: pytest -q

2من CI إلى CD

مهمة نشر تعمل فقط بعد نجاح الاختبار وعلى main فقط، وتأخذ أسرارها من GitHub:

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t registry.example.com/cafe-api:${{ github.sha }} .
      - run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login registry.example.com -u ci --password-stdin
      - run: docker push registry.example.com/cafe-api:${{ github.sha }}
      - run: ./scripts/deploy.sh ${{ github.sha }}

3حماية الفرع الرئيسي

من إعدادات المستودع: Branches ثم قاعدة لـ main: اطلب طلب دمج، واطلب نجاح فحص test، واطلب مراجعة واحدة، وامنع الدفع المباشر. الآن لا يدخل main كود لم يُختبر، حتى منك.

مثال محلول

المسألة: CI يأخذ 14 دقيقة فيتجاهله الفريق ويدمج قبل انتهائه. القياس: 9 دقائق تثبيت اعتماديات، و4 اختبارات تكامل متتابعة. الحل: cache: pip يحوّل التثبيت لـ 40 ثانية، وتقسيم الاختبارات لمهمتين متوازيتين، وفحص التنسيق كأول خطوة ليفشل خلال ثوانٍ. النتيجة: 4 دقائق، والفريق ينتظر النتيجة.

خرافة مقابل حقيقة

اختبر فهمك

بطاقات مراجعة سريعة

تحقق من فهمك