הגדרת CI/CD עבור יישומי PHP (Composer)

צינור ה-CI שלך מבזבז 90 שניות רק על composer install. מפתח מבצע commit, הולך לקפה, חוזר — והבנייה אפילו לא הגיעה לבדיקות. כמהנדסי DevOps עם ניסיון של 7+ שנים, ראינו את זה עשרות פעמים. הפתרון הוא שמירת vendor במטמון ודגלי Composer נכונים. איתם, אותה פעולה יורדת ל-8 שניות. חיסכון של פי 10 בזמן אומר שצוות של עשרה מקבל משוב שעה מוקדם יותר בכל יום. במהלך חודש, זה מתורגם לחיסכון משמעותי בעלויות על רצים בענן — עשרות דולרים, בערך $9–13 בחיסכון. במאמר זה, נראה כיצד לגרום ל-CI/CD עבור PHP לעוף ואילו מלכודות ייחודיות לפרויקטי PHP.

למה רוב פרויקטי PHP מבזבזים זמן ב-CI?

הבעיות הנפוצות ביותר הן מטמון Composer חסר, הרצת בדיקות ללא ניתוח סטטי, והתעלמות מאופטימיזציות Docker. בואו נסתכל על כל אחת עם מספרים.

Composer ללא מטמון — 60–120 שניות לכל commit בפרויקט Laravel טיפוסי. עם מטמון — 5–10 שניות. חיסכון של פי 10 בשלב אחד.

PHPStan ללא baseline — בפרויקטים legacy, האנליזר נכשל עם 500+ שגיאות, ומפתחים פשוט משביתים אותו. baseline נכון קובע את השגיאות הנוכחיות וחוסם רק שגיאות חדשות.

תמונות Docker ללא multistage — שוקלות 1–2 GB, מעמיסות על הרישום, ומאטות את הפריסה. בניית multistage מניבה תמונה של 100–200 MB, ומפחיתה את זמן ההעברה ואת עלויות האחסון.

איך הקמנו CI/CD עבור PHP מקצה לקצה

הגישה שלנו היא לבנות צינור שמסתיים תוך 2–3 דקות ומספק גרסה בביטחון. בואו נפרק כל שלב.

Composer: מטמון ודגלים נכונים

לפי תיעוד Composer, הדגל --prefer-dist מאיץ את התקנת התלויות על ידי הורדת ארכיונים. ב-CI, השתמשו תמיד ב:

---
- uses: actions/cache@v4
  with:
    path: ~/.composer/cache
    key: ${{ runner.os }}-composer-${{ hashFiles('composer.lock') }}
    restore-keys: |
      ${{ runner.os }}-composer-
- run: composer install --no-interaction --no-progress --prefer-dist --optimize-autoloader
---

- uses: actions/cache@v4 with: path: ~/.composer/cache key: ${{ runner.os }}-composer-${{ hashFiles('composer.lock') }} restore-keys: | ${{ runner.os }}-composer- - run: composer install --no-interaction --no-progress --prefer-dist --optimize-autoloader יוצר classmap במקום חיפושי PSR-4 — טעינת מחלקות מהירה יותר בסביבת production. --optimize-autoloader חייב להיות במאגר; בלעדיו, ההתקנה פותרת גרסאות מאפס.

למה מטמון Composer הוא קריטי

ללא מטמון, כל commit מבזבז דקה בהורדת תלויות. עם מטמון, שניות. בפרויקט עם 50 commits ביום, החיסכון הוא כמעט שעת CPU — שמתורגמת ישירות לחיסכון בתקציב. המטמון מקושר ל-composer.lock; הוא מתבטל אוטומטית כשהתלויות משתנות.

איזה מסד נתונים להשתמש בבדיקות?

אם הבדיקות משתמשות בתכונות ייחודיות ל-PostgreSQL (jsonb, חיפוש טקסט מלא, מערכים), יש צורך בשירות אמיתי. אחרת, SQLite בזיכרון מספיק — הוא מהיר יותר ואינו דורש קונטיינרים נוספים. הגדרת שירות דרך composer.lock ב-CI לוקחת 5 שורות.

כלי ניתוח סטטי עבור PHP

PHPStan — אנליזר סטטי עם רמות 0–9. עבור פרויקטים legacy, המתכון שלנו:

./vendor/bin/phpstan analyse --level=5 --configuration=phpstan.neon --generate-baseline 

ה-baseline קובע את השגיאות הנוכחיות ב-services, ורק שגיאות חדשות נחסמות. העלו בהדרגה את הרמה ל-6–9.

PHP_CodeSniffer או PHP CS Fixer — לאכיפת PSR-12. אנו משתמשים ב-PHP CS Fixer ב-CI עם ./vendor/bin/phpstan analyse --level=5 --configuration=phpstan.neon --generate-baseline , ומקומית עם תיקון אוטומטי.

CI ספציפי ל-Laravel

Artisan ב-CI: phpstan-baseline.neon. --dry-run הוא חובה — בלעדיו, Laravel מבקש אישור.

Queues ו-Redis. אם הבדיקות משתמשות ב-php artisan config:clear && php artisan migrate --force --no-interaction && php artisan db:seed --class=TestSeeder --no-interaction, אין צורך ב-Redis. אם בודקים עיבוד אמיתי, הוסיפו שירות Redis ב-CI.

Docker עבור PHP: בניית multistage מקצה לקצה

FROM php:8.3-fpm-alpine AS builder
RUN apk add --no-cache git unzip libzip-dev \
    && docker-php-ext-install pdo pdo_pgsql zip opcache
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
WORKDIR /var/www
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --prefer-dist --optimize-autoloader
COPY . .
RUN composer run-script post-autoload-dump

FROM php:8.3-fpm-alpine
COPY --from=builder /var/www /var/www

OPcache הוא חובה ב-production. תצורת --force:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
; в продакшене — не проверять изменения файлов

Queue::fake() חשוב: OPcache אינו בודק את הדיסק בכל בקשה. בעת פריסה, הפעילו מחדש את FPM או קראו ל-FROM php:8.3-fpm-alpine AS builder RUN apk add --no-cache git unzip libzip-dev \ && docker-php-ext-install pdo pdo_pgsql zip opcache COPY --from=composer:2 /usr/bin/composer /usr/bin/composer WORKDIR /var/www COPY composer.json composer.lock ./ RUN composer install --no-dev --no-scripts --prefer-dist --optimize-autoloader COPY . . RUN composer run-script post-autoload-dump FROM php:8.3-fpm-alpine COPY --from=builder /var/www /var/www .

אפשרויות פריסה: מ-VPS ועד Kubernetes

Kubernetes + Nginx sidecar — פוד PHP-FPM עם Nginx sidecar, נפח משותף. ConfigMap עבור nginx.conf ו-php.ini.

VPS דרך Deployer — opcache.ini — ללא downtime עם symlink אטומי. Laravel Forge / Ploi — פלטפורמות פריסה עבור PHP — מצוינות כשקוברנטיס אינו נחוץ.

מה כלול בהקמת CI/CD מקצה לקצה

• תכנון ויישום צינור CI/CD (GitHub Actions / GitLab CI / Jenkins).
• שמירת Composer ו-node_modules במטמון (אם יש frontend).
• הגדרת PHPUnit, PHPStan, PHP CS Fixer.
• בניית Docker multistage עם OPcache.
• פריסה ל-Kubernetes (דרך ArgoCD או Helm) או ל-VPS (דרך Deployer).
• אינטגרציה עם ניטור (Grafana + Loki, או Datadog).
• תיעוד צינור ו-runbook לאירועים.
• שבועיים של תמיכה לאחר ההשקה.

תהליך ה-CI/CD שלנו

1. ביקורת על הצינור והתשתית הנוכחיים. זיהוי צווארי בקבוק (מטמון, גרסאות כלים, תצורות).
2. תכנון הצינור: בחירת מערכת CI (GitHub Actions, GitLab CI), הגדרת שלבים, כתיבת Dockerfile.
3. יישום — הגדרת מטמונים, ניתוח סטטי, בדיקות, בניית תמונה.
4. בדיקות — הרצת הצינור על staging, תיקון שגיאות.
5. מסירה — תיעוד, הדרכת צוות, תמיכת אחריות ל-30 יום.

לוחות זמנים משוערים

הזמינו הקמת CI/CD — והצוות שלכם יפסיק לחכות לבניות. צרו קשר לייעוץ. הניסיון שלנו: 7+ שנים, 50+ הטמעות CI/CD עבור PHP, תוצאות מובטחות.