CI/CD für PHP-Projekte: GitHub Actions fortgeschrittenes Niveau

Einleitung: Vom einfachen CI/CD zur Produktionsreife

Eine einfache CI/CD-Pipeline, die nur Tests ausführt, ist gut. Aber für ein ernsthaftes PHP-Projekt reicht das nicht aus. In der realen Entwicklung sind Abhängigkeits-Caching zur Beschleunigung von Builds, parallele Aufgaben, Matrix-Builds für verschiedene PHP-Versionen, statische Analyse und natürlich automatisches Deployment erforderlich. In diesem Artikel analysieren wir fortgeschrittene Techniken zur Konfiguration von GitHub Actions für PHP-Projekte anhand praktischer Beispiele.

Wir gehen davon aus, dass Sie bereits mit den Grundlagen der YAML-Syntax und der grundlegenden Struktur von .github/workflows vertraut sind. Nun gehen wir zur Optimierung und Erweiterung der Möglichkeiten über.

1. Beschleunigung von Builds: Composer-Caching und optimale Strategie

Jeder Workflow-Durchlauf lädt Abhängigkeiten erneut herunter. Das dauert 1-3 Minuten, die sich auf 5-10 Sekunden mit Caching reduzieren lassen.

Intelligentes Caching des vendor-Ordners

Wir verwenden actions/cache mit einem Schlüssel basierend auf dem Hash von composer.lock. Wenn sich die Sperrdatei nicht geändert hat, werden die Abhängigkeiten aus dem Cache wiederhergestellt.

name: PHP CIon: [push, pull_request]

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

      - name: Setup PHP        uses: shivammathur/setup-php@v2        with:          php-version: '8.2'          tools: composer:v2

      - name: Cache Composer dependencies        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}          restore-keys: |            ${{ runner.os }}-php-

      - name: Install dependencies        run: composer install --no-progress --prefer-dist

Beachten Sie restore-keys: Wenn der genaue Schlüssel nicht gefunden wird, wird der letzte Cache für dieses Betriebssystem verwendet. Dies ist eine Absicherung beim Wechseln von Branches.

Matrix-Build für verschiedene PHP-Versionen

Um Kompatibilität zu gewährleisten, testen Sie parallel mit mehreren PHP-Versionen:

jobs:  test:    strategy:      matrix:        php-version: ['8.1', '8.2', '8.3']        dependency-stability: [prefer-lowest, prefer-stable]

    steps:      - uses: actions/checkout@v4      - name: Setup PHP ${{ matrix.php-version }}        uses: shivammathur/setup-php@v2        with:          php-version: ${{ matrix.php-version }}

      - name: Cache        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php${{ matrix.php-version }}-${{ hashFiles('**/composer.lock') }}

      - name: Install dependencies        run: |          composer update --${{ matrix.dependency-stability }} --prefer-dist --no-interaction

      - name: Run tests        run: vendor/bin/phpunit

Dieser Ansatz deckt Kompatibilitätsprobleme bereits vor dem Merge in den Hauptbranch auf. Sie erhalten 6 parallele Jobs (3 Versionen × 2 Stabilitätsstrategien).

2. Fortgeschrittene Schritte: Statische Analyse und Codequalität

Unit-Tests sind nicht das einzige Werkzeug zur Qualitätssicherung. Fügen wir PHPStan (maximale Analyseebene) und PHP Code Sniffer hinzu.

Linting und statische Analyse

Erstellen Sie einen separaten Job für die Analyse, der parallel zu den Tests ausgeführt wird:

jobs:  static-analysis:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: shivammathur/setup-php@v2        with:          php-version: '8.2'          coverage: none

      - name: Cache        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php-static-${{ hashFiles('**/composer.lock') }}

      - run: composer install --no-interaction --prefer-dist

      - name: PHPStan        run: vendor/bin/phpstan analyse --level=max src/

      - name: PHPCS        run: vendor/bin/phpcs --standard=PSR12 src/