Automatisierung: Auch für kleine Teams? Klar.
FTP-Upload per Hand – immer noch Alltag, gerade in kleinen Agenturen. Läuft, bis jemand aus Versehen das falsche Verzeichnis erwischt oder die Bilder von letzter Woche überschreibt. Spart Zeit? Eher nicht. Fehlerquote inklusive. Automatisch deployen wäre besser. Kompliziert? Muss nicht sein. CI/CD klingt nach Enterprise, braucht aber kein Kubernetes oder Jenkins. GitHub Actions reicht völlig. CI-Server? Nicht nötig. Spezialwissen? Braucht niemand für den Einstieg.
Worum geht’s eigentlich? Continuous Integration und Deployment, aber ohne Bastelorgie. Ziel: Aufwand runter, Fehler runter, Nerven schonen. Kein Team will am Freitagabend noch mit kaputten Deployments kämpfen.
Was reicht für kleine Budgets?
Große CI/CD-Konstrukte? Überdimensioniert für 3-Mann-Agenturen. Meist reichen diese Basics:
- Nach jedem Push: Check oder Test
- Automatischer Upload auf den Server (ja, oft immer noch FTP/SFTP)
- Sofort sehen, ob das Deployment läuft oder abschmiert
Alles andere? Nice to have, aber selten Pflicht. Hauptsache, die Pipeline läuft stabil und nervt nicht. Zu viel Komplexität sorgt am Ende nur dafür, dass doch wieder per Hand hochgeladen wird. Dann beginnt das Fehlerlotto von vorn.
GitHub Actions: Schnell und schmerzlos
Direkt im GitHub-Repo, keine Zusatzsoftware. YAML-File rein, fertig. Server? Braucht nur FTP oder SFTP. Kein extra Dienst, kein Docker. Beispiel für PHP oder statische Seiten? Geht so:
```yaml
name: Deploy Website
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Deploy via FTP
uses: SamKirkland/FTP-Deploy-Action@4.0.0
with:
server: ${{ secrets.FTP_SERVER }}
username: ${{ secrets.FTP_USERNAME }}
password: ${{ secrets.FTP_PASSWORD }}
local-dir: ./public
remote-dir: /www/
```
Ergebnis: Nach jedem Push im Haupt-Branch landet alles aus „public“ automatisch auf dem Server. Niemand muss mehr klicken oder Dateien rüberziehen. Funktioniert auch mit Kaffee in der Hand.
Sicherheit: Zugangsdaten nicht ins Repo kippen
FTP-Daten im Repository? Schlechte Idee. Dafür gibt’s bei GitHub „Secrets“. Die sind verschlüsselt und nur im Workflow sichtbar. Einrichtung? Unter „Settings“ im Repo, da kann nichts schiefgehen.
SFTP? Besser mit SSH-Key als mit Passwort. Auch der Key passt ins Secret-Fach. Ein verlorener Key ist ärgerlich, aber kein Weltuntergang, wenn er nicht im Code rumliegt.
Automatisieren: So viel wie nötig, so wenig wie möglich
Kleine Teams müssen nicht alles automatisieren. Ein simpler Workflow reicht zum Start. Wer später mehr will, kann nachlegen:
- Syntax-Check oder Linter vor dem Upload
- Benachrichtigungen (Mail, Slack) bei Fehlern
- Simple Versionsnummer am Deployment
Extra-Schritte wie Node.js-Build oder SASS-Kompilierung? Geht, muss aber nicht direkt am Anfang sein. Hauptsache, der Grund-Workflow steht.
Typische Fehler – und wie sie sich sparen lassen
Die Klassiker:
- Pfad falsch gesetzt: Manche Provider nutzen /www, andere /htdocs. Vorher checken, sonst landet das Projekt im Nirwana.
- Zu viel Ballast: IDE-Müll, Mac-DS_Store oder Thumbs.db? Gehören nicht auf den Server. .gitignore hilft, wenn sie gepflegt ist.
- Keine Checks: Kleine Tippfehler in der Syntax killen das Live-System. Ein Linter spart graue Haare.
- Zugangsdaten im Klartext: Niemals. Immer Secrets, immer verschlüsselt.
Wer das beachtet, muss selten zurückrudern.
Fazit: CI/CD nicht überdenken – einfach machen
Mit GitHub Actions lässt sich eine schlanke Deployment-Automation bauen, die für kleine Agenturen reicht. Kein Overkill, keine Extra-Tools. Ein paar Secrets anlegen, YAML ins Repo – läuft. Spart Zeit, minimiert Fehler, macht Deployments entspannter.
Wer später mehr will, kann den Workflow Schritt für Schritt erweitern. Die Grundversion bleibt überschaubar. CI/CD bleibt Werkzeug – und wird nicht zur nächsten Großbaustelle. Und endlich ist der FTP-Upload kein Ritual mehr.
bye
mo
Anhänge
Zuletzt bearbeitet: