CI/CD für PHP von Grund auf: Schritt-für-Schritt-Anleitung zur Pipeline-Einrichtung

Warum brauchen Sie CI/CD, wenn Sie kein Roboter sind?

Stellen Sie sich vor: Freitagabend, Sie haben gerade eine Funktion fertiggestellt, laden den Code per FTP auf den Server (ja, das gibt es noch) und … die Website stürzt mit einem weißen Bildschirm des Todes ab. Kommt Ihnen bekannt vor? Wenn Sie eine CI/CD-Pipeline für PHP hätten, wäre alles automatisch passiert: Die Tests wären bereits beim Push fehlgeschlagen, der Code wäre nicht in die Produktion gelangt und Sie hätten in Ruhe Ihren Tee trinken können.

Continuous Integration und Continuous Delivery (oder Deployment) sind nicht nur modische Abkürzungen. Sie sind Ihr persönlicher Assistent, der den Code überprüft, Tests ausführt, lintet, Artefakte erstellt und auf den Server deployed. In diesem Artikel zeige ich Ihnen, wie Sie eine CI/CD-Pipeline für PHP von Grund auf mit GitHub Actions einrichten. Keine Abstraktionen – nur echter Code und funktionierende Beispiele.

Was ist eine CI/CD-Pipeline und warum brauchen PHP-Entwickler sie?

Eine CI/CD-Pipeline ist eine Abfolge automatischer Schritte, die jedes Mal ausgeführt werden, wenn Sie Code in das Repository pushen. Für PHP ist dies besonders relevant, weil:

\n
• PHP eine dynamische Sprache ist und viele Fehler (Tippfehler, falsche Typen) erst zur Laufzeit auftreten.
\n
• Deployments oft „auf die Schnelle“ durchgeführt werden – per SCP, rsync oder sogar FTP (ein Schrei aus der Seele).
\n
• Teams wachsen und manuelle Überprüfungen zum Engpass werden.
\n

Durch die Einrichtung von CI/CD für PHP erhalten Sie:

\n
• Automatisches Testen bei jedem Push.
\n
• Überprüfung des Codestils (PSR-12, Ihr interner Standard).
\n
• Automatisches Deployment auf Staging/Production.
\n
• Benachrichtigungen in Telegram/Slack über den Build-Status.
\n

Tool-Auswahl: Warum GitHub Actions?

Es gibt viele Optionen: Jenkins, GitLab CI, Bitbucket Pipelines, CircleCI. Für die Einrichtung einer CI/CD-Pipeline für PHP von Grund auf empfehle ich jedoch GitHub Actions. Warum?

\n
• Kostenlos für öffentliche Repositories (und 2000 Minuten pro Monat für private – völlig ausreichend).
\n
• Alles an einem Ort – Code, Issues, Actions.
\n
• Riesiges Ökosystem an vorgefertigten Aktionen (Actions) – kein Grund, das Rad neu zu erfinden.
\n

Aber wenn Sie GitLab verwenden – die Prinzipien sind dieselben, nur die YAML-Syntax ist anders. Los geht's.

Schritt 1: Repository-Struktur und Basisdaten

Für die Demonstration nehmen wir ein typisches PHP-Projekt mit Laravel (der Ansatz funktioniert jedoch für jedes Framework). Ihre Struktur sollte so aussehen:

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 (falls Sie PHP-CS-Fixer verwenden)

Erstellen Sie den Ordner .github/workflows/ und die Datei ci-cd.yml – das ist das Herzstück Ihrer Pipeline.

Schritt 2: Basis-YAML – Continuous Integration (CI)

Beginnen wir einfach: Testausführung und Linting bei jedem Push in main oder bei Pull Requests. Hier ist eine minimale CI/CD-Pipeline für 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

Was passiert hier?

\n
• checkout – wir holen den Code ab.
\n
• setup-php – wir richten PHP ein.