PHP-Automatisierung in der Praxis

## Wenn Klicks entscheiden: warum Automatisierung kein Luxus mehr ist

Drei Uhr nachts. Der Newsletter an 14.000 Empfänger sollte längst raus sein. Stattdessen hängt ein Skript seit zwei Stunden in einer Endlosschleife, weil ein Praktikant vergessen hat, eine Datenbanksicherung vor dem Versand einzuziehen. Am Morgen erklärt der Geschäftsführer, warum diese Aktion „nicht wieder vorkommen darf". Das ist kein Einzelfall. In PHP-Projekten, die über Jahre gewachsen sind, finden sich solche Zeitzünden an allen Ecken: manuelle Deployments am Freitagabend, lokal getesteter Code, der auf dem Server plötzlich andere Pfade vorfindet, Newsletter, die sporadisch doppelt verschickt werden.

Der ökonomische Treiber für Automatisierung ist so schlicht wie unbestechlich. Jeder händische Schritt kostet Zeit, die ein Entwickler bezahlt bekommt, und produziert Fehler, die im Nachgang teurer werden. Eine Studie nach der anderen zeigt, dass die Fehlerdichte in automatisierten Pipelines um Größenordnungen unter der von Hand ausgeführter Prozesse liegt – der Hebel ist also nicht „ein bisschen bequemer", sondern strukturell. Wer kontinuierlich liefert, kann kontinuierlich korrigieren, statt in großen, risikoreichen Releases zu denken.

Qualitativ kommt ein zweiter Aspekt hinzu: Code, der nicht durch eine Pipeline geht, ist Code, den niemand außer dem Autor gesehen hat. Selbst eine erfahrene Entwicklerin kann ermüden, abgelenkt sein oder schlicht vergessen, eine Randbedingung zu testen. Ein Werkzeug wird nicht müde. Es prüft die gleiche Regel jedes Mal mit derselben Sorgfalt – und dokumentiert gleichzeitig, was geprüft wurde. Das ist der qualitative Treiber: Automatisierung verschiebt Qualität vom subjektiven Können Einzelner hin zu einem nachvollziehbaren, wiederholbaren Verfahren.

[Merke] Manuelle Prozesse sind nicht „nur" ein Risiko. Sie sind ein laufender Kostentreiber, weil sie bezahlte Arbeitszeit für wiederholbare Tätigkeiten verbrennen und jede Wiederholung eine neue Fehlerquelle darstellt. [/Merke]

## Eine kleine Sprachkunde: CI, CD und Continuous Deployment

Im Entwickleralltag werden die drei Begriffe oft munter gemischt. Streng genommen beschreiben sie jedoch unterschiedliche Reifegrade, und ein PHP-Team sollte bewusst entscheiden, auf welcher Stufe es stehen will.

**Continuous Integration (CI)** bedeutet, dass jeder Push in eine geteilte Codebasis automatisch eine Pipeline anstößt: Tests laufen, statische Analyse wird ausgeführt, die Anwendung wird gebaut. Ziel ist es, Integrationskonflikte früh sichtbar zu machen – nicht erst am Tag vor dem Release. CI ist die Voraussetzung für alles, was danach kommt.

**Continuous Delivery (CD im engeren Sinne)** geht einen Schritt weiter: Das Ergebnis der Pipeline ist stets ein lauffähiges Artefakt – ein Paket, ein Container-Image, eine versionierte Codebasis –, das jederzeit deployt werden könnte. Der eigentliche Roll-out auf die Produktion erfolgt jedoch weiterhin per Knopfdruck eines Menschen. Das ist die Stufe, die viele Unternehmen anstreben, weil sie den Release-Termin bewusst steuern wollen, etwa um Support-Teams vorzuwarnen.

**Continuous Deployment** schließlich hebt auch diese letzte Hürde auf: Jeder grüne Build geht automatisch in die Produktion. Was Google, Facebook oder kleinere SaaS-Anbieter schon lange tun, wird für klassische PHP-Business-Anwendungen zunehmend realistisch. Das liegt unter anderem an zwei Verfahren, die in den letzten Jahren in PHP-Projekten Einzug gehalten haben: **Zero-Downtime-Strategien** sorgen dafür, dass während des Roll-outs kein Nutzer eine Fehlermeldung sieht (etwa weil alter und neuer Code parallel laufen), und **Feature Flags** erlauben es, neue Funktionen zunächst versteckt auszuliefern und nur für einen Teil der Nutzer sichtbar zu schalten – ein Fehler wird so nicht zum Großschaden, weil das Feature jederzeit abgeschaltet werden kann.

Die drei Stufen sind keine Glaubensfrage, sondern ein Spektrum. Ein Team, das Newsletter und Datenimporte zeitgesteuert ausführt, betreibt längst eine Form der Automatisierung, die CI nur ergänzt. Wer CI/CD einführt, schichtet diese Inseln in einen zusammenhängenden Workflow um.

[Lernziel] Nach diesem Kapitel unterscheidest du CI, CD und Continuous Deployment sauber und kannst einordnen, welche Stufe für dein Team realistisch ist. [/Lernziel]

### Wie sich der Begriff „CD" verdoppelt hat

Beim Lesen von Stellenanzeigen oder Konferenztalks taucht „CD" oft doppelt auf: einmal als Continuous Delivery, einmal als Continuous Deployment. In der Praxis hat sich eingebürgert, dass „CD" ohne Zusatz meist Delivery meint, während Deployment ausgeschrieben wird, wenn tatsächlich das automatische Ausrollen gemeint ist. Diese Konvention wird im Buch durchgehalten – überall, wo von Continuous Deployment die Rede ist, steht das Wort ausgeschrieben, sonst ist Delivery gemeint.

## Vom FTP-Upload zu GitOps: eine kurze Geschichte der PHP-Bereitstellung

Wer PHP heute einführt, kann sich kaum vorstellen, unter welchen Bedingungen die Sprache groß geworden ist. Mitte der 2000er-Jahre war der typische Workflow: per FTP-Client in einen `htdocs`-Ordner hochladen, hoffen, dass die Rechte stimmen, anschließend den Browser bemühen. Versionskontrolle war eher ein Archiv als ein Werkzeug für Zusammenarbeit; Continuous Integration war ein Begriff aus Zeitschriften, nicht aus dem Alltag von Shared-Hosting-Anbietern.

Die ersten spürbaren Verbesserungen brachten Subversion, dann Git, und parallel dazu die ersten CI-Server, allen voran Jenkins. Plötzlich wurden Builds nicht mehr „nach Gefühl" gemacht, sondern auf einem sauberen System reproduziert. PHP selbst profitierte von dieser Phase überproportional: Die Einführung von Composer im Jahr 2012 veränderte das Ökosystem so gründlich wie seinerzeit die Einführung von PEAR – nur besser. Plötzlich waren Abhängigkeiten versioniert, updatebar und überhaupt erst sinnvoll handhabbar.

In der zweiten Hälfte der 2010er-Jahre verschob sich der Schwerpunkt weg vom „Wie baue ich?" hin zum „Wie rolle ich aus?". Tools wie Deployer setzten sich durch, weil sie die Eigenheiten von PHP-Frameworks verstanden: Migrations-Pausen, Wartungsmodi, das getrennte Deployen von Code und Konfiguration. Docker containerisierte schließlich nicht nur die Laufzeit, sondern auch die Build-Umgebung, sodass dieselbe PHP-Version mit denselben Extensions in Produktion lief wie auf dem CI-Server.

Heute stehen Teams am Übergang zu **GitOps**: Die Wahrheit über den gewünschten Zustand der Produktion liegt nicht mehr in Ansible-Playbooks oder Shell-Skripten, sondern ausschließlich im Git-Repository. Wer ausrollt, was Git beschreibt, kann nachvollziehen, wer was wann geändert hat, und jeden Stand mit einem einzigen Commit wiederherstellen. Für ein PHP-Ökosystem, das historisch sehr pragmatisch war, ist das ein großer Sprung – aber einer, der sich lohnt.

```tikz \node[draw, rectangle] (n1) at (0,0) {FTP-Upload}; \node[draw, rectangle] (n2) at (3,0) {Git + CI}; \node[draw, rectangle] (n3) at (6,0) {Container}; \node[draw, rectangle] (n4) at (9,0) {GitOps}; \draw[->] (n1) -- (n2); \draw[->] (n2) -- (n3); \draw[->] (n3) -- (n4); ```

Die vier Knoten stehen für die groben Epochen, die Pfeile für die jeweiligen Reifesprünge. Welche dieser Stufen im eigenen Alltag dominiert, lässt sich ehrlich an einem Tag im Teamkalender ablesen: Wer freitags um 16 Uhr manuell deployt, lebt noch in Stufe eins. Wer morgens einen Pull Request öffnet und am Nachmittag denselben Stand in Produktion wiederfindet, ist bei vier angekommen.

## Reifegradmodell für PHP-Teams in fünf Stufen

Reifegradmodelle haben einen schlechten Ruf, weil sie gerne als Strickleiter missverstanden werden, auf der man die Kollegen nach oben treten darf. In diesem Buch dient das Modell als Selbstdiagnose: jede Stufe steht für eine realistische Frage, die du deinem Team stellen kannst, und für eine typische Antwort, an der sich ablesen lässt, wo ihr steht.

| Stufe | Leitfrage | Typische Antwort | |------:|-----------|------------------| | 1 | Gibt es überhaupt eine Versionskontrolle? | „Meistens, aber das Live-System ist das eigentliche Repository." | | 2 | Laufen Tests automatisch? | „Wenn der Praktikant Zeit hat, ja." | | 3 | Wird jeder Push geprüft? | „Ja, PHPUnit und PHPStan laufen auf Jenkins." | | 4 | Können wir jederzeit releasen? | „Wir haben versionierte Artefakte und Deployer-Skripte, die jeder auslösen kann." | | 5 | Rollen wir kontinuierlich aus? | „Ja, jeder Merge auf main landet nach grünen Checks automatisch in Produktion." |

Stufe 1 ist der Zustand vieler kleiner, gewachsener PHP-Projekte, die jahrelang funktioniert haben und nun an ihre Grenzen stoßen. Stufe 3 ist das realistische Ziel für die meisten mittelständischen Teams, weil dort der größte Effekt mit vertretbarem Aufwand erzielt wird. Stufe 4 und 5 sind eher eine Frage der Disziplin und der Werkzeugkette als der Größe: Auch ein dreiköpfiges Team kann Continuous Deployment betreiben, wenn die Pipeline steht und das Vertrauen in sie da ist.

Wichtig ist die Reihenfolge: Stufe 3 setzt Stufe 2 voraus, Stufe 4 baut auf Stufe 3 auf. Wer versucht, Continuous Deployment einzuführen, ohne dass Tests automatisch laufen, baut sich eine elegante Methode, besonders schnell besonders kaputten Code auszuliefern. Das Modell ist deshalb bewusst konservativ formuliert – jedes Level ist ein stabiler Zustand, in dem man verweilen darf, bevor man weitergeht.

[Faustregel] Ein Reifegradmodell ist kein Wettbewerb. Es ist eine Landkarte: Standort bestimmen, Route wählen, in der eigenen Größenordnung ankommen. [/Faustregel]

## Wie dieses Buch aufgebaut ist

Mit dem Reifegradmodell im Hinterkopf lässt sich der Aufbau des Buches jetzt begründen. Wir gehen die Stufen nicht der Reihe nach durch, weil die meisten Lesenden nicht bei Stufe 1 starten – wer ein gewachsenes PHP-Projekt übernimmt, landet meist mitten in Stufe 2 oder 3 und fragt sich, wie es von dort aus weitergeht. Das Buch greift diese Situation auf und nimmt jede Stufe einzeln auseinander: zuerst die Diagnose, dann die passenden Werkzeuge, dann der Sprung zur nächsten Stufe. Jedes Kapitel schließt mit einem klaren Lernziel und enthält mindestens ein lauffähiges Beispiel, das du in einem kleinen Repository nachstellen kannst.

Kapitel 2 bis 4 widmen sich der Grundlage: Composer als Dependency-Werkzeug, PHPUnit und Pest als Testframeworks sowie PHPStan und PHP-CS-Fixer für statische Analyse und Stil. Diese Werkzeuge sind die Bausteine, die in jeder späteren Pipeline wiederverwendet werden – wer sie beherrscht, kann sie in jedem CI-System wiederfinden. Kapitel 5 und 6 behandeln zeitgesteuerte Aufgaben mit Cron, systemnaher ausgeführt mit Robo, und zeigen, wie sich Newsletter, Autoresponder und Datenimporte reproduzierbar machen lassen.

Kapitel 7 bis 9 bilden das Herzstück der Continuous-Integration-Praxis: Jenkins für selbstgehostete Setups, GitLab CI/CD für integrierte Workflows und GitHub Actions für die größte Verbreitung. Jedes Kapitel enthält eine funktionierende Pipeline-Konfiguration, die du direkt übernehmen oder anpassen kannst. Ergänzend kommen in Kapitel 7 mit PHPSpec und Behat verhaltensgetriebene Werkzeuge hinzu, in Kapitel 8 mit Mockery und Infection weitere Bausteine für saubere Test-Doubles und automatisierte Mutationstests, und in Kapitel 9 mit Envoyer und Capistrano zusätzliche Deploy-Werkzeuge neben Deployer.

Kapitel 10 und 11 gehen einen Schritt weiter und zeigen, wie mit Deployer und Docker Zero-Downtime-Deployments gelingen – also genau jene Verfahren, die Continuous Deployment überhaupt erst möglich machen. Kapitel 11 widmet sich darüber hinaus Psalm als zweiter statischer Analyser neben PHPStan, weil beide Werkzeuge unterschiedliche Stärken haben und in vielen Teams parallel laufen.

Kapitel 12 und 13 behandeln Betriebsaspekte: Logging, Monitoring und das ganze Drumherum, das in vielen PHP-Büchern fehlt. Kapitel 14 schließt mit einer Sammlung typischer Migrationspfade – also konkreten Plänen, wie ein bestehendes Projekt in Richtung Continuous Deployment wandern kann, ohne dass der laufende Betrieb darunter leidet.

Jedes Kapitel schreibt eine zentrale Idee fort: Automatisierung ist kein Selbstzweck, sondern ein Mittel gegen wiederholbare Fehler, unzuverlässige Release-Termine und Code, der nur einmal funktioniert hat. Wer die Werkzeuge beherrscht, kann Prioritäten setzen – und genau das ist die Kompetenz, die moderne PHP-Teams von reinen Codierern unterscheidet.

```php <?php // Beispiel: kleinster möglicher Automatisierungs-Hook // Wird z. B. per Cron jede Nacht um 03:15 ausgeführt. require __DIR__ . '/vendor/autoload.php';

$logger = new Monolog\Logger('nightly'); $logger->pushHandler( new Monolog\Handler\StreamHandler(__DIR__ . '/var/log/nightly.log') );

try { (new App\Automation\NewsletterDispatcher($logger))->run(); $logger->info('Newsletter erfolgreich versandt'); } catch (\Throwable $e) { $logger->error('Fehler beim Versand', ['exception' => $e]); } ```

Das Skript ist bewusst klein gehalten. Es illustriert das Prinzip, das viele Kapitel wieder aufgreifen: ein klar definierter Einstiegspunkt, ein einziger Verantwortlicher, ein Logfile als Wahrheitsspeicher. Sobald dieser Baustein steht, lässt er sich in jede Pipeline einhängen – sei es als Cron-Job, als GitHub-Action oder als Docker-Container mit Zeitsteuerung.

## Werkzeugkasten auf einen Blick

Wer zum ersten Mal mit PHP-Automatisierung in Berührung kommt, sieht sich einer Flut von Werkzeugen gegenüber. Die folgende Übersicht listet die Werkzeuge auf, die in diesem Buch eine zentrale Rolle spielen. Sie sind keine zufällige Auswahl, sondern bilden gemeinsam eine zusammenhängende Kette: vom Abhängigkeitsmanagement über Tests und statische Analyse bis hin zu Build, Deploy und Laufzeit. Einige davon werden in eigenen Kapiteln behandelt, andere kommen ergänzend innerhalb anderer Kapitel vor.

| Werkzeug | Aufgabe | Wo es im Buch auftaucht | |----------|---------|-------------------------| | Composer | Abhängigkeiten, Autoloading, Skripte | Kapitel 2, durchgehend | | PHPUnit | Unit- und Integrationstests | Kapitel 3 | | Pest | Lesbarer Test-DSL auf PHPUnit-Basis | Kapitel 3 | | PHPSpec | Spec-basierte Tests für Klassen-Verträge | Kapitel 7 | | Behat | Verhaltensgetriebene Tests auf Story-Ebene | Kapitel 7 | | Mockery | Test-Doubles und Mocks | Kapitel 8 | | Infection | Mutationstests für PHPUnit-Suiten | Kapitel 8 | | PHPStan | Statische Typ- und Code-Analyse | Kapitel 4 | | Psalm | Statische Analyse, Schwerpunkt Typinferenz | Kapitel 11 | | PHP-CS-Fixer | Stilvereinheitlichung | Kapitel 4 | | Robo | Aufgaben-Runner für PHP-Projekte | Kapitel 5 | | Jenkins | Selbstgehosteter CI-Server | Kapitel 7 | | GitLab CI/CD | Integrierte CI/CD in GitLab | Kapitel 8 | | GitHub Actions | CI/CD in GitHub-Repositories | Kapitel 9 | | Envoyer | Zero-Downtime-PHP-Deployment | Kapitel 9 | | Capistrano | Deployment-Werkzeug aus dem Ruby-Ökosystem | Kapitel 9 | | Deployer | PHP-nahes Deployment-Werkzeug | Kapitel 10 | | Docker | Containerisierung von Build und Laufzeit | Kapitel 11 |

Jedes dieser Werkzeuge wird im Buch in der Tiefe behandelt – entweder in einem eigenen Kapitel oder als ergänzender Baustein innerhalb eines anderen Kapitels. An dieser Stelle genügt eine erste Orientierung, damit du beim Lesen weißt, wohin ein bestimmtes Werkzeug gehört.

### Die Bausteine im Kurzporträt

Die folgenden Kurzporträts beschreiben jedes Werkzeug in einem Absatz: was es tut, wozu man es nutzt – und, wo es sich anbietet, einordnende Halbsätze zu Begriffen, die dir in der PHP-Welt immer wieder begegnen werden. Wo ein Kapitelverweis nötig ist, steht er am Ende des Absatzes, damit der Lesefluss nicht ständig unterbrochen wird.

**Composer.** Heute so selbstverständlich wie ein Texteditor. Composer verwaltet die Abhängigkeiten eines PHP-Projekts, lädt automatisch Klassen nach dem PSR-4-Standard (einer Konvention, die festlegt, wo eine Klasse mit einem bestimmten Namen in der Verzeichnisstruktur liegen muss) und stellt eine eigene Skript-Sektion bereit, in der sich hunderte von Alltagsaufgaben definieren lassen – vom Aufräumen des Cache bis zum Ausführen der Test-Suite. Mehr dazu in Kapitel 2.

**PHPUnit und Pest.** PHPUnit ist seit Jahren der Standard für Unit- und Integrationstests in PHP. Daneben hat sich Pest etabliert, eine dünnere Schicht über PHPUnit, die mit knapperer, funktionaler Syntax dieselbe Engine nutzt. Beide Werkzeuge schließen sich nicht aus; wer ein bestehendes PHPUnit-Projekt übernimmt, kann Pest schrittweise ergänzen, ohne alte Tests umzuschreiben. Beide werden in Kapitel 3 behandelt.

**PHPSpec und Behat.** Sie erweitern das Spektrum um zwei weitere Perspektiven: PHPSpec denkt Tests vom Verhalten der Klasse her und formuliert sie als Spezifikation, bevor der Code existiert. Behat geht noch einen Schritt weiter und schreibt Tests in einer fast natürlichen Sprache (genannt Gherkin), die auch nicht-technische Stakeholder lesen und mitformulieren können. Beide treten neben PHPUnit und Pest, nicht an deren Stelle – ihr Einsatz lohnt sich, wenn Anforderungen zwischen Fachseite und Entwicklung immer wieder missverstanden werden. Beide in Kapitel 7.

**Mockery und Infection.** Mockery erspart das Schreiben eigener Stub-Klassen (kleine Attrappen, die echte Objekte im Test vertreten) und liefert Test-Doubles (Schein-Instanzen einer Klasse, die kontrollierte Antworten zurückgeben). Infection geht noch weiter: Es prüft, ob die bestehenden Tests überhaupt scharf genug gestellt sind, indem es gezielt Mutationen in den Code einbaut (etwa `>` zu `>=`, `true` zu `false`) und zusieht, ob die Testsuite diese Mutationen entdeckt. Wer hier viele „Überlebende" findet, hat eine ehrliche Aussage über die Testqualität. Beide in Kapitel 8.

**PHPStan und Psalm.** Sie kümmern sich um Dinge, die das Auge des Reviewers übersieht: ungenutzte Variablen, falsche Typ-Annotationen, inkonsistente Einrückungen. Sie sind die ehrlichsten Kritiker eines Codebestands, weil sie nicht diplomatisch schweigen. Psalm und PHPStan haben unterschiedliche Stärken und laufen in vielen Teams parallel; Psalm wird in Kapitel 11 zusammen mit Docker behandelt, weil beide Werkzeuge besonders dann glänzen, wenn die Build-Umgebung in einem Container reproduzierbar definiert ist. PHPStan in Kapitel 4.

**PHP-CS-Fixer.** Ergänzt die statische Analyse um die Stil-Seite: konsistente Einrückung, einheitliche Imports, vorhersehbare Formatierung. Es läuft typischerweise als Pre-Commit-Hook – also als kleine Prüfung, die Git direkt vor dem Einchecken ausführt – oder als Schritt in der CI-Pipeline. Beides hat Vor- und Nachteile: Der Hook fängt Probleme lokal ab, die Pipeline stellt sicher, dass auch vergessliche Teammitglieder keine Ausnahmen hinterlassen. Kapitel 4.

**Robo.** Weniger bekannt als die anderen, leistet aber beim Strukturieren wiederkehrender Aufgaben unschätzbare Dienste. Wer schon einmal ein 200-Zeilen-Shell-Skript im Projekt liegen hatte, das niemand mehr anfassen wollte, weiß diese PHP-basierte Alternative zu schätzen: Aufgaben werden als PHP-Klassen formuliert, sind damit versionierbar, testbar und in jedem IDE farblich hervorgehoben. Kapitel 5.

**Jenkins, GitLab CI/CD und GitHub Actions.** Die drei CI-Plattformen, die in PHP-Projekten am häufigsten anzutreffen sind. Jenkins betreibt ihr selbst auf eigener Hardware, GitLab CI/CD ist eng an ein Git-Repository-Produkt gekoppelt, GitHub Actions läuft direkt im größten Code-Hosting-Anbieter der Welt. Das Buch stellt sie in eigenen Kapiteln nebeneinander, damit du die Übergänge zwischen den Systemen wiedererkennst und beim Wechsel des Hostings nicht bei Null anfängst. Kapitel 7, 8 und 9.

**Deployer, Envoyer und Capistrano.** Drei Werkzeuge, die die Brücke zur Produktion schlagen. Deployer und Envoyer kennen die Eigenheiten von PHP-Frameworks, legen Releases versioniert ab und ermöglichen atomare Rollbacks – das heißt, ein fehlgeschlagenes Deployment lässt sich in einem einzigen Schritt rückgängig machen, ohne manuell Dateien zu sortieren. Capistrano stammt aus dem Ruby-Ökosystem, wird aber in Kapitel 9 behandelt, weil es in etlichen PHP-Hosting-Setups als Brücke zwischen Application-Server und Versionsverwaltung dient. Deployer selbst in Kapitel 10.

**Docker.** Verpackt das Ergebnis in einen reproduzierbaren Container, der auf dem Laptop des Entwicklers genauso läuft wie auf dem Produktionsserver. Der entscheidende Punkt ist nicht Docker selbst, sondern die Idee dahinter: Build-Umgebung und Laufzeit werden zusammen eingefroren, sodass „bei mir funktioniert es" aufhört, ein Argument zu sein. In Kombination mit Deployer entsteht daraus eine Migrationsstrategie, die auch zwischen beliebigen Cloud-Providern funktioniert. Kapitel 11.

[Ausblick] Die folgenden Kapitel vertiefen jeden Eintrag dieser Tabelle um eine Dimension: nicht nur *was* das Werkzeug tut, sondern *wie* es in eine Pipeline eingebunden wird und welche typischen Fehler beim ersten Einsatz lauern. [/Ausblick]

### Werkzeuge auswählen, nicht anhäufen

Eine Warnung gehört in jede Werkzeugübersicht: Mehr Werkzeuge bedeuten nicht mehr Automatisierung, sondern mehr Wartung. Ein Team, das parallel PHPUnit, Pest, Behat, Codeception und PHPSpec als konkurrierende Test-Frameworks einführt, hat nicht fünfmal so viel Testabdeckung, sondern fünf konkurrierende Konventionen im selben Projekt. Drei Werkzeuge, die zusammenpassen und von allen verstanden werden, schlagen sieben, die niemand mehr überblickt. Die Auswahl folgt deshalb einer einfachen Frage: Welches Werkzeug deckt die Lücke ab, die im aktuellen Reifegrad noch offen ist? Solange Tests nicht stabil laufen, hilft der schönste Mutation-Tester nichts. Solange Deployments manuell passieren, ist die Diskussion über Continuous Deployment verfrüht. Das Buch folgt dieser Logik: erst die Stufe sichern, dann das nächste Werkzeug hinzunehmen – und vorher ehrlich prüfen, ob das bestehende Set noch beherrscht wird.

===ENDE===

Wiederkehrende Aufgaben von Hand erledigen, Deployments per FTP hochladen, Tests nur „wenn Zeit ist" laufen lassen — so verlieren PHP-Teams täglich Stunden und riskieren vermeidbare Fehler.

Dieses Buch zeigt Schritt für Schritt, wie sich der komplette PHP-Entwicklungsprozess automatisieren lässt: von zeitgesteuerten Aufgaben mit Cron über CI/CD-Pipelines mit Jenkins, GitLab CI/CD und GitHub Actions bis zu automatisiertem Testen mit PHPUnit und Pest, Zero-Downtime-Deployments mit Deployer und Docker sowie statischer Codeanalyse mit PHPStan und Psalm.

Jedes Kapitel ist praxisnah aufgebaut, mit lauffähigen Beispielen und ohne graue Theorie — Werkzeuge und Workflows, die sich direkt in reale Projekte übernehmen lassen.

Für PHP-Entwickler, DevOps-Einsteiger und Teamleiter, die ihre Prozesse reproduzierbar, zuverlässig und professionell gestalten wollen.

• Zeitgesteuerte Aufgaben mit Cron, Aufgabenplaner und PHP-CLI
• Composer als Fundament — Skripte, Abhängigkeiten, reproduzierbare Builds
• CI/CD-Plattformen im Vergleich: Jenkins, GitLab CI/CD, GitHub Actions
• GitHub Actions für PHP-Projekte mit shivammathur/setup-php
• Automatisiertes Testen mit PHPUnit, Pest und Codeception
• Verhaltensgetriebene Entwicklung mit PHPSpec und Behat
• Mocking und Testqualität: Mockery, Coverage, Mutation-Tests
• Deployment-Strategien mit Deployer, Envoyer und Capistrano
• Containerisierte Deployments mit Docker und Docker Swarm
• Statische Code-Analyse mit PHPStan und Psalm
• Coding Standards: PHP_CodeSniffer und PHP-CS-Fixer
• Pre-Commit-Hooks und Quality Gates mit GrumPHP
• Task-Runner in PHP: Robo, Blend, openeuropa/task-runner

Platzhalter — Bestelllinks (Amazon KDP, Direktverkauf, eBook-Download) werden nachgereicht, sobald die Distributionskanäle feststehen.