Deployer ist ein Open-Source-Deployment-Tool für PHP-Projekte – speziell entwickelt, um Anwendungen wie Laravel, Symfony, Magento, WordPress oder auch generische PHP-Apps automatisiert, wiederholbar und sicher auf Server zu bringen.
Es ist ein CLI-Tool, geschrieben in PHP.
Du definierst dein Deployment in einer deploy.php
-Datei mit klaren Aufgaben (Tasks).
Es setzt auf das Prinzip Zero Downtime Deployment, z. B. durch Symlinks.
Unterstützt mehrstufige Umgebungen (z. B. staging, production).
Du installierst Deployer über Composer:
composer require deployer/deployer --dev
Du generierst ein Template:
vendor/bin/dep init
Du konfigurierst deploy.php
, z. B. für Laravel:
host('mein-server.com')
->set('deploy_path', '/var/www/meinprojekt')
->set('branch', 'main');
task('deploy', [
'deploy:prepare',
'deploy:vendors',
'artisan:migrate',
'deploy:publish',
]);
Du startest das Deployment:
vendor/bin/dep deploy production
Deployer:
Verbindet sich via SSH mit dem Zielserver
Klont das Git-Repository in ein neues Release-Verzeichnis
Installiert Composer-Abhängigkeiten
Führt Tasks aus (z. B. php artisan migrate
)
Verlinkt das neue Release mit dem Live-Verzeichnis (current
)
Löscht alte Releases nach Bedarf
Vorteil | Beschreibung |
---|---|
🚀 Schnell & Skriptbar | Alles per CLI steuerbar |
🔁 Rollback-Funktion | Bei Fehlern einfach zum letzten funktionierenden Release zurück |
⚙️ Flexibel erweiterbar | Eigene Tasks, Hooks und Bedingungen |
🧩 Viele Presets | Für Laravel, Symfony, WordPress etc. |
🔐 Sicher durch SSH | Keine FTP-Abhängigkeit |
Laravel Octane ist eine offizielle Erweiterung für das Laravel-Framework, die die Performance deiner Anwendung dramatisch verbessert, indem sie Laravel auf Hochleistungsservern wie Swoole oder RoadRunner ausführt.
Statt bei jeder HTTP-Anfrage den Laravel-Framework-Code neu zu laden (wie bei PHP-FPM üblich), hält Octane deine Anwendung permanent im Speicher. Das spart Bootstrapping-Zeit und macht deine App viel schneller.
Laravel Octane nutzt Worker-basierte Server (z. B. Swoole oder RoadRunner), die:
Die Laravel-Anwendung einmalig booten,
Dann Anfragen wiederholt und schnell verarbeiten, ohne das Framework neu zu starten.
Vorteil | Beschreibung |
---|---|
⚡ Höhere Performance | Bis zu 10x schneller als klassische Laravel-Setups mit PHP-FPM |
🔁 Persistente Worker | Keine Neuinitalisierung bei jeder Anfrage |
🌐 WebSockets & Echtzeit | Direkte Unterstützung dank Swoole/RoadRunner |
🧵 Nebenläufigkeit | Möglichkeit zur parallelen Verarbeitung von Aufgaben |
🔧 Built-in Features | Task Worker, Route Watcher, Task Dispatching usw. |
RoadRunner ist ein High-Performance Application Server für PHP, der von Spiral Scout entwickelt wurde. Er ersetzt den klassischen PHP-FPM (FastCGI Process Manager) und bietet durch eine dauerhafte Ausführung deiner PHP-Anwendung einen massiven Performance-Schub – besonders bei Frameworks wie Laravel oder Symfony.
PHP-Skripte werden nicht bei jeder Anfrage neu geladen, sondern laufen dauerhaft in sogenannten Worker-Prozessen (ähnlich wie bei Node.js oder Swoole).
Dadurch sparst du dir das erneute Bootstrapping deiner App bei jedem Request – das ist wesentlich schneller als bei PHP-FPM.
RoadRunner selbst ist in der Programmiersprache Go geschrieben – das bedeutet hohe Stabilität, einfache Cross-Plattform-Deployments und parallele Verarbeitung von Anfragen.
HTTP-Server (inkl. HTTPS, Gzip, CORS, etc.)
PSR-7 & PSR-15 Middleware-Kompatibilität
Unterstützung für:
Hot Reload für Änderungen im Code (mit Watch-Modul)
RoadRunner startet PHP-Worker-Prozesse.
Die Worker laden einmal den gesamten Framework-Bootstrap.
RoadRunner verteilt HTTP- oder gRPC-Anfragen an die Worker.
Die Antwort wird über Go zurückgegeben – schnell und parallel.
Laravel + RoadRunner (statt Laravel + PHP-FPM)
Anwendungen mit hoher Request-Frequenz
APIs, Microservices, Echtzeit-Anwendungen (z. B. mit WebSockets)
Serverless-ähnliche Dienste, wo Latenz kritisch ist
Eigenschaft | PHP-FPM | RoadRunner |
---|---|---|
Bootstrapping pro Request | Ja | Nein (persistente Worker) |
Geschwindigkeit | Gut | Exzellent |
WebSockets | Nicht direkt | Ja |
gRPC | Nein | Ja |
Sprache | C | Go |
GitHub Actions ist ein Feature von GitHub, mit dem du automatisierte Workflows für deine Softwareprojekte erstellen kannst – direkt im GitHub-Repository.
Du kannst CI/CD-Pipelines (Continuous Integration / Continuous Deployment) aufbauen, z. B.:
🛠️ Code bei jedem Push oder Pull Request builden
🚀 Software automatisch deployen (z. B. auf einen Webserver, in die Cloud, zu DockerHub)
📦 Releases erstellen (z. B. ZIP-Dateien, Versionstags)
🔄 Cronjobs oder geplante Tasks laufen lassen
GitHub Actions basiert auf sogenannten Workflows, die du in einer Datei definierst:
Die Datei heißt z. B. .github/workflows/ci.yml
Sie ist im YAML-Format
Du definierst Events (z. B. push
, pull_request
) und Jobs (z. B. build
, test
)
Jobs bestehen aus Steps, die Befehle oder Aktionen ausführen
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '20'
- run: npm install
- run: npm test
Eine Action ist ein einzelner Schritt, den man in einem Workflow ausführt. Es gibt:
Vorgefertigte Actions (z. B. actions/checkout
, setup-node
, upload-artifact
)
Eigene Actions (z. B. Shell-Skripte oder Docker-Container)
Du kannst Actions im GitHub Marketplace finden und nutzen.
Spart manuelle Arbeit
Verbessert Codequalität (durch automatisierte Tests)
Macht Deployments reproduzierbar
Alles direkt in GitHub – kein externer CI-Dienst nötig (wie Jenkins oder Travis CI)
Docker Compose ist ein Werkzeug, mit dem du mehrere Docker-Container als einen einzigen Service definieren und starten kannst. Statt jeden Container einzeln über die Docker-CLI zu starten, kannst du mit Docker Compose eine docker-compose.yml
-Datei schreiben, in der du alle benötigten Dienste (z. B. Datenbank, Webserver, App-Container) deklarierst.
Docker Compose = Projektbeschreibung + Mehrere Container + Ein Befehl zum Starten
docker-compose.yml
version: '3.9'
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
redis:
image: "redis:alpine"
In diesem Beispiel:
Ein Container baut die lokale Webanwendung.
Ein zweiter Container nutzt das offizielle Redis-Image.
Beide Container sind miteinander vernetzt.
docker-compose up # Startet alle Container im Vordergrund
docker-compose up -d # Startet im Hintergrund (detached)
docker-compose down # Stoppt und entfernt Container, Netzwerke etc.
✅ Einfaches Setup für Multi-Container-Anwendungen
✅ Alles wird in einer Datei versioniert (z. B. für Git)
✅ Reproduzierbare Entwicklungsumgebungen
✅ Leichtes Hoch- und Runterfahren ganzer Stacks
Lokale Entwicklung mit mehreren Services (z. B. App + DB)
Integrationstests mit vollständigem Stack
Simpler Deployment-Workflow (z. B. über CI/CD)
Contentful ist ein sogenanntes Headless Content Management System (Headless CMS). Es ermöglicht Unternehmen, Inhalte (Content) zentral zu verwalten und flexibel über APIs an verschiedene Ausgabekanäle auszuliefern – z. B. Websites, Apps oder digitale Displays.
Traditionelle CMS (wie WordPress) verwalten Inhalte und präsentieren sie gleichzeitig auf einer fest verknüpften Website. Bei einem Headless CMS ist die „Präsentationsschicht“ (Frontend) vom „Content-Management“ (Backend) getrennt. Man hat also nur den „Kopf“ (Frontend) abgetrennt – daher der Begriff „headless“.
API-first: Inhalte werden über REST oder GraphQL APIs bereitgestellt.
Flexibles Content Modeling: Man definiert eigene Content-Typen (z. B. Blogartikel, Produkte, Testimonials) mit frei wählbaren Feldern.
Mehrsprachigkeit: Gute Unterstützung für mehrsprachige Inhalte.
Cloud-basiert: Keine eigene Server-Infrastruktur nötig.
Integration: Lässt sich gut mit Tools wie React, Vue, Next.js, Shopify, SAP, etc. kombinieren.
Unternehmen mit mehreren Ausgabekanälen (Website, App, Smartwatch, etc.)
Große Marken mit internationaler Präsenz
Entwicklerteams, die ein flexibles und skalierbares CMS suchen
Ein Prepared Statement (auch vorbereitetes Statement genannt) ist eine Technik in der Programmierung, insbesondere bei der Arbeit mit Datenbanken, um SQL-Abfragen sicherer und effizienter auszuführen.
Ein Prepared Statement besteht aus zwei Schritten:
Vorbereitung der SQL-Abfrage mit Platzhaltern
Beispiel in SQL:
SELECT * FROM users WHERE username = ? AND password = ?
(In manchen Sprachen nutzt man auch :username
oder andere Platzhalter)
Bindung der Parameter und Ausführung
Die echten Werte werden später „gebunden“, z. B.:
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
✅ Sicherer vor SQL-Injection:
Benutzereingaben werden nicht direkt in die SQL eingebaut, sondern separat behandelt.
✅ Schneller bei Wiederholungen:
Die SQL-Abfrage wird vom Datenbankserver einmal geparst und kann mehrfach effizient ausgeführt werden (z. B. bei Schleifen).
$conn = new mysqli("localhost", "user", "pass", "database");
$stmt = $conn->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email); // "s" für string
$email = "beispiel@example.com";
$stmt->execute();
$result = $stmt->get_result();
Ein Prepared Statement trennt SQL-Logik von Benutzereingaben und schützt so vor Sicherheitslücken wie SQL-Injection. Es ist eine Best Practice beim Umgang mit Datenbanken.
Ein Entity Manager ist ein zentraler Bestandteil von ORM-Frameworks (Object-Relational Mapping), vor allem im Zusammenhang mit Java (JPA – Java Persistence API), aber auch in anderen Sprachen wie PHP (Doctrine ORM).
Hier ist eine verständliche Erklärung:
Ein Entity Manager ist eine Komponente, die sich um die Verwaltung von Datenbank-Entities (also Objekten/Datensätzen) kümmert. Er bildet die Schnittstelle zwischen der objektorientierten Welt des Codes und der relationalen Welt der Datenbank.
Persistieren (Speichern):
Finden/Laden:
Holt ein Objekt anhand seiner ID oder anderer Kriterien.
Beispiel: $entityManager->find(User::class, 1);
Aktualisieren:
Änderungen an einem Objekt werden verfolgt und in die Datenbank geschrieben (z. B. beim flush()
).
Entfernen/Löschen:
Löscht ein Objekt aus der Datenbank.
Beispiel: $entityManager->remove($user);
Transaktionen verwalten:
Beginnt, commitet oder rollt Transaktionen zurück.
Query-Handling:
Führt eigene Abfragen aus, oft mit DQL (Doctrine Query Language) oder JPQL.
Der Entity Manager verwaltet den „Zustand“ von Objekten:
managed (verfolgt Änderungen),
detached (nicht mehr verwaltet),
removed (zum Löschen markiert),
new (noch nicht gespeichert).
$user = new User();
$user->setName('Max Mustermann');
$entityManager->persist($user); // Zum Speichern vormerken
$entityManager->flush(); // Tatsächlich in DB schreiben
Der Entity Manager ist der zentrale Ansprechpartner, wenn es darum geht, mit Datenbankobjekten zu arbeiten – lesen, schreiben, ändern, löschen. Er abstrahiert die SQL-Ebene und macht die Datenbankarbeit objektorientiert steuerbar.
Ein Join Point ist ein Begriff aus der Aspect-Oriented Programming (AOP), also der aspektorientierten Programmierung.
Ein Join Point ist eine definierte Stelle im Ablauf eines Programms, an der zusätzlicher Code (ein sogenannter Aspekt) eingefügt werden kann.
Aufruf einer Methode
Ausführung einer Methode
Zugriff auf ein Attribut (lesen oder schreiben)
Werfen einer Ausnahme
In AOP wird Programmcode modularisiert, indem Querschnittsfunktionen (wie Logging, Sicherheit, Transaktionsmanagement) aus dem eigentlichen Anwendungscode ausgelagert werden. Diese Funktionen werden dann an bestimmten Punkten im Programmablauf (den Join Points) „eingeschnitten“.
Pointcut: Eine Ausdrucksweise, mit der beschrieben wird, welche Join Points betroffen sind (z. B. „alle Methoden mit dem Namen save*
“).
Advice: Der Code, der an einem Join Point ausgeführt wird (z. B. „logge diesen Methodenaufruf“).
Aspect: Eine Kombination aus Pointcut(s) und Advice(s) – also ein vollständiges Modul, das eine Querschnittsfunktion implementiert.
@Before("execution(* com.example.service.*.*(..))")
public void logBeforeMethod(JoinPoint joinPoint) {
System.out.println("Aufruf von: " + joinPoint.getSignature().getName());
}
→ Hier wird vor jedem Methodenaufruf in einem bestimmten Package ein Logging-Code ausgeführt – und joinPoint.getSignature()
liefert Details zum konkreten Join Point.
Aspect-Oriented Programming (AOP) ist ein Programmierparadigma, das sich darauf konzentriert, Querschnittsfunktionen (Cross-Cutting Concerns) modular zu kapseln. Es ergänzt objektorientierte oder funktionale Programmierung, indem es Code, der sich durch viele Klassen oder Module zieht, auslagert und separat behandelt.
Probleme wie Logging, Sicherheitsprüfungen, Fehlerbehandlung, Transaktionsmanagement oder Performance-Messungen sind typische Cross-Cutting Concerns. Diese wiederholen sich oft in vielen Klassen und Methoden – AOP ermöglicht es, solchen Code zentral zu schreiben und automatisch an den richtigen Stellen auszuführen.
Aspect: Ein Modul, das eine Querschnittsfunktion kapselt.
Advice: Der eigentliche Code, der ausgeführt wird (z. B. vor, nach oder anstatt einer Methode).
Join Point: Ein Punkt im Programmablauf, an dem ein Aspect eingreifen kann (z. B. Methodenaufruf).
Pointcut: Eine Definition, welche Join Points betroffen sind (z. B. "alle Methoden in Klasse X").
Weaving: Der Prozess, bei dem Aspect-Code mit dem eigentlichen Code „verwoben“ wird – zur Laufzeit, beim Kompilieren oder beim Laden.
@Aspect
public class LoggingAspect {
@Before("execution(* com.example.service.*.*(..))")
public void logBeforeMethod(JoinPoint joinPoint) {
System.out.println("Methode wird aufgerufen: " + joinPoint.getSignature().getName());
}
}
Dieser Code führt automatisch Logging aus, bevor jede Methode im com.example.service
-Paket ausgeführt wird.
Bessere Modularität
Weniger Code-Duplikate
Trennung von Fachlogik und Querschnittslogik
Kann die Lesbarkeit erschweren (man sieht nicht sofort, was alles beim Methodenaufruf passiert).
Debugging kann komplexer sein.
Oft framework-abhängig (z. B. Spring, AspectJ).