Continuous Integration (CI) und Continuous Deployment (CD) für PHP‑Projekte

Inhaltsverzeichnis

Erste Schritte: Continuous Integration (CI) und Continuous Deployment (CD) für PHP‑Projekte

Mit CI/CD laufen Tests, Builds und Deploys automatisch, sobald Code in das Git‑Repository
gepusht wird.
Das spart Zeit, vermeidet „funktioniert‑nur‑bei‑mir“ Bugs und sorgt für reproduzierbare Releases.
Wir konzentrieren uns hier auf GitHub Actions; andere Systeme
(GitLab CI, Jenkins, Bitbucket Pipelines) funktionieren sehr ähnlich.

1. Ziele & Pipeline‑Schritte

Install – Composer Dependencies mit
```
--no-dev
```
.
Static Analyse – z. B. PHPStan / Psalm.
Tests – PHPUnit / Pest + Coverage.
Build – Assets minifizieren (npm / esbuild).
Deploy – SSH/FTP‑Upload oder
```
git pull
```
auf dem Server.

2. GitHub Actions – Workflow‑Datei anlegen

# .github/workflows/ci-cd.yml
name: CI & CD

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build-test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4

    - uses: shivammathur/setup-php@v2
      with:
        php-version: '8.3'
        extensions: mbstring, pdo_mysql
        coverage: pcov             # für Coverage Report

    - name: Install Composer Deps
      run: composer install --no-interaction --prefer-dist --no-progress

    - name: Static Analyse (PHPStan)
      run: vendor/bin/phpstan analyse --no-progress

    - name: Unit Tests
      run: vendor/bin/pest --coverage-text --colors=always

    - name: Build Front‑end
      run: |
        npm ci
        npx esbuild assets/app.js --minify --outfile=public/assets/app.min.js

  deploy:
    needs: build-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'   # nur auf main

    steps:
    - uses: actions/checkout@v4     # noch einmal Code holen
    - name: Sync via rsync over SSH
      run: |
        rsync -az --delete -e "ssh -p 22 -o StrictHostKeyChecking=no" \
          ./  ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}:/var/www/taskboard
      env:
        RSYNC_RSH: ssh
      # SSH_KEY im Secrets hinterlegen (SSH_PRIVATE_KEY)
      # Host & User ebenso als Secrets

3. SSH‑Key & Secrets einrichten

# lokal
ssh-keygen -t ed25519 -C "ci-cd"
cat ~/.ssh/id_ed25519.pub            # auf Server ➜ ~/.ssh/authorized_keys

# GitHub → Repository → Settings → Secrets → New secret
SSH_PRIVATE_KEY = (Inhalt von id_ed25519)
SSH_HOST        = server.example.com
SSH_USER        = deploy

4. Umgebungs‑Variablen (.env) sichern

Lege .env.example ins Repo, .env bleibt nur auf dem Server.
Alternativ:
```
echo "$ENVFILE" > .env
```
in Deploy‑Schritt;
ENVFILE im Secret speichern.

5. Datenbank‑Migrations im CD‑Schritt

ssh $USER@$HOST "cd /var/www/taskboard && php artisan migrate --force"

--force

läuft ohne interaktive Bestätigung.

6. Blue‑Green / Zero‑Downtime Deployment (vereinfachtes Prinzip)

```
/var/www/taskboard_blue
```
+
```
taskboard_green
```
Ordner.
GitHub‑Action deployt in frei liegenden Ordner.
Nach erfolgreichem Test:
```
ln -sfn taskboard_green current
```
;
Webserver verweist immer auf Symlink current.

7. Rollback‑Strategie

ssh $USER@$HOST "
  cd /var/www &&
  ln -sfn taskboard_blue current &&
  systemctl reload php-fpm
"

Ein simples Symlink‑Switch dauert Millisekunden.

8. Tipps für schnelle Pipelines

composer install –prefer-dist – lädt ZIP‑Artefakte statt Git‑Klone.
actions/cache@v4 für Composer & npm Cache, spart Minuten.
Splitte lange Jobs – Tests parallel aufteilen (matrix Build).

9. Monitoring nach Deploy

HTTP‑Smoke‑Test Schritt →
```
curl -f -s https://app/health
```
.
Error Tracking (Sentry, Bugsnag) aktivieren.
Server‑Metrics → Grafana + Prometheus / Netdata.

10. Fazit

CI/CD nimmt dir Routinearbeit ab: Linting, Tests, Build‑Steps und Deploy laufen
vollautomatisch, zuverlässiger als jede manuelle FTP‑Session.
Mit GitHub Actions reicht eine YAML‑Datei, SSH‑Key‑Secrets und rsync –
schon landet neuer Code wenige Sekunden nach dem Merge auf dem Server.
Einmal eingerichtet, beschleunigt das deinen Entwicklungs‑Zyklus enorm
und reduziert Produktionsfehler auf ein Minimum.