أنابيب CI/CD لـ PHP من الصفر: دليل خطوة بخطوة لإعداد pipeline

لماذا تحتاج CI/CD حتى لو كنت مطورًا بشريًا؟

تخيل: يوم الجمعة، المساء، انتهيت للتو من تطوير ميزة جديدة، وترفع الكود إلى السيرفر عبر FTP (نعم، هذا لا يزال يحدث)، وفجأة... الموقع ينهار بشاشة بيضاء. مألوف؟ أما لو كان لديك أنابيب CI/CD لـ PHP، لكان كل شيء تم تلقائيًا: الاختبارات كانت ستفشل في مرحلة الدفع، والكود لم يكن ليصل إلى الإنتاج، وكنت ستستمتع بوقتك بهدوء.

التكامل المستمر والتسليم المستمر (أو النشر المستمر) ليسا مجرد مصطلحات عصرية. إنهما مساعدك الشخصي الذي يفحص الكود، ويجري الاختبارات، ويحلل الأسلوب، ويجمع المخرجات، وينشر على السيرفر. في هذا المقال، سأريك كيفية إعداد أنابيب CI/CD لـ PHP من الصفر باستخدام GitHub Actions. بدون تجريد — فقط كود حقيقي وأمثلة عملية.

ما هي أنابيب CI/CD ولماذا يحتاجها مطور PHP؟

أنابيب CI/CD هي سلسلة من الخطوات التلقائية التي تُنفَّذ في كل مرة تدفع فيها الكود إلى المستودع. بالنسبة لـ PHP، هذا مهم بشكل خاص لأن:

\n
• PHP لغة ديناميكية، والعديد من الأخطاء (أخطاء إملائية، أنواع غير صحيحة) تظهر فقط أثناء التشغيل.
\n
• النشر غالبًا ما يتم بشكل عشوائي — عبر SCP أو rsync أو حتى FTP (صرخة ألم).
\n
• الفرق تكبر، والفحوصات اليدوية تصبح عنق زجاجة.
\n

بإعداد CI/CD لـ PHP، ستحصل على:

\n
• اختبارات تلقائية عند كل دفع.
\n
• فحص أسلوب الكود (PSR-12، معيارك الداخلي).
\n
• نشر تلقائي على بيئة الاختبار/الإنتاج.
\n
• إشعارات في Telegram/Slack عن حالة البناء.
\n

اختيار الأداة: لماذا GitHub Actions؟

هناك خيارات كثيرة: Jenkins، GitLab CI، Bitbucket Pipelines، CircleCI. لكن لإعداد أنابيب CI/CD لـ PHP من الصفر، أنصح بـ GitHub Actions. لماذا؟

\n
• مجاني للمستودعات العامة (و 2000 دقيقة شهريًا للمستودعات الخاصة — كافية جدًا).
\n
• كل شيء في مكان واحد — الكود، المشكلات، الإجراءات.
\n
• نظام بيئي ضخم من الإجراءات الجاهزة — لا حاجة لإعادة اختراع العجلة.
\n

لكن إذا كنت تستخدم GitLab — المبادئ نفسها، فقط بناء جملة YAML مختلف. لنبدأ.

الخطوة 1: هيكل المستودع والملفات الأساسية

للتجربة، سنأخذ مشروع PHP نموذجي على Laravel (لكن الطريقة تعمل مع أي إطار عمل). يجب أن يكون هيكلك كالتالي:

my-php-app/\n├── .github/\n│   └── workflows/\n│       └── ci-cd.yml\n├── src/\n├── tests/\n├── composer.json\n├── phpunit.xml\n└── .php_cs.dist (إذا كنت تستخدم PHP-CS-Fixer)

أنشئ مجلد .github/workflows/ وملف ci-cd.yml — هذا هو قلب أنبوبتك.

الخطوة 2: YAML الأساسي — التكامل المستمر (CI)

لنبدأ بسيطًا: تشغيل الاختبارات وتحليل الكود عند كل دفع إلى main أو طلب سحب. إليك الحد الأدنى لأنابيب CI/CD لـ PHP:

name: PHP CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v4\n\n      - name: Setup PHP\n        uses: shivammathur/setup-php@v2\n        with:\n          php-version: '8.2'\n          extensions: mbstring, pdo, sqlite, gd\n          coverage: xdebug\n\n      - name: Install dependencies\n        run: composer install --prefer-dist --no-progress\n\n      - name: Run PHP CS Fixer (Lint)\n        run: vendor/bin/php-cs-fixer fix --dry-run --diff\n\n      - name: Run PHPStan (Static Analysis)\n        run: vendor/bin/phpstan analyse src --level=5\n\n      - name: Run Tests\n        run: vendor/bin/phpunit --coverage-text

ماذا يحدث هنا؟

\n
• checkout — نسحب الكود.
\n
• setup-php — نثبّت PHP مع الإضافات المطلوبة.
\n
• composer install — نثبّت التبعيات.
\n
• PHP CS Fixer — نفحص أسلوب الكود.
\n
• PHPStan — تحليل ثابت للكود.
\n
• PHPUnit — تشغيل الاختبارات مع تقرير التغطية.
\n

هذا هو الحد الأدنى. لكن دعنا نضيف النشر التلقائي — الجزء الممتع.