Wenn du allein an einem Projekt arbeitest, klingt CI/CD nach Werkzeugkasten für Teams, die du nicht hast. Trotzdem ist eine kleine Pipeline für Einzelentwickler oft wertvoller als für große Teams — nicht weil sie Abstimmung ersetzt, sondern weil sie das ersetzt, was du als Einzelperson nachts um elf garantiert vergisst.
Der Anspruch ist dabei ein anderer als im Konzern. Es geht nicht um Sicherheitsnetze für zwanzig Leute, sondern darum, dass ein Deploy nicht mehr aus fünf handgetippten Befehlen besteht, bei denen du beim dritten schon nicht mehr weißt, ob du sie in der richtigen Reihenfolge hattest.
Was du automatisierst — und in welcher Reihenfolge
Ich würde jedem Solo-Projekt genau vier Stufen empfehlen, in dieser Reihenfolge eingeführt:
Stufe eins: Der Build muss durchlaufen. Klingt trivial, ist aber der mit Abstand häufigste Fehler beim Deployen: Etwas läuft lokal, weil auf deiner Maschine eine Datei existiert, die nirgends eingecheckt ist, oder eine Abhängigkeit global installiert ist. Ein Build auf einer frischen Maschine deckt das sofort auf. Allein dieser Schritt verhindert einen großen Teil aller kaputten Deployments.
Stufe zwei: Automatische Prüfungen. Linter, Typprüfung, Formatierung. Das sind Sekunden Laufzeit für Fehler, die du sonst im Review deiner selbst — also gar nicht — finden würdest. Bei TypeScript ist der Typcheck in der Pipeline besonders wichtig, weil viele Build-Werkzeuge Typen beim Bauen gar nicht prüfen und du dich sonst in falscher Sicherheit wiegst.
Stufe drei: Tests, aber die richtigen. Als Einzelentwickler brauchst du keine Testpyramide aus dem Lehrbuch. Du brauchst eine Handvoll Tests für die Stellen, an denen ein Fehler wirklich weh tut: Bezahlvorgang, Authentifizierung, Datenexport, alles, was Geld oder Daten anfasst. Diese Tests müssen schnell sein, sonst umgehst du sie irgendwann selbst.
Stufe vier: Deployment. Erst wenn die ersten drei Stufen grün sind, darf ausgeliefert werden. Der eigentliche Deploy kann simpel sein: Code auf den Server ziehen, bauen, Dienst neu starten. Der Wert liegt nicht in der Eleganz, sondern darin, dass es jedes Mal identisch abläuft.
Der Punkt, an dem es zur Zeitverschwendung wird
Automatisierung ist nicht kostenlos. Jede Pipeline ist Code, den du wartest, und für Solo-Projekte gibt es einen klaren Bereich, in dem sich das nicht mehr lohnt.
Verzichte auf Dinge, deren Einrichtung länger dauert als der manuelle Vorgang über ein Jahr gerechnet. Ein aufwendiges Container-Orchestrierungs-Setup für eine Anwendung, die auf einem einzigen Server läuft, ist genau das. Ebenso mehrstufige Freigabeprozesse, Genehmigungsschritte und Deployment-Strategien mit parallel laufenden Umgebungen — sie lösen Probleme von Organisationen, nicht von Einzelpersonen.
Ebenfalls kritisch: eine Pipeline, die zu langsam ist. Wenn ein Durchlauf zwanzig Minuten braucht, hörst du auf, kleine Änderungen zu deployen, und sammelst stattdessen große Blöcke an — womit du dir genau das Risiko zurückholst, das du eigentlich loswerden wolltest. Alles unter fünf Minuten ist gut, alles über zehn wird zur Bremse. Abhängigkeiten zwischenzuspeichern und Schritte parallel laufen zu lassen sind die beiden Hebel, die dabei fast immer am meisten bringen.
Secrets gehören nicht in die Pipeline-Datei
Der eine Fehler, der in Solo-Projekten wirklich teuer werden kann: Zugangsdaten, die im Repository landen. Pipeline-Dateien liegen im Repository, oft in öffentlichen. Deploy-Schlüssel, API-Tokens und Datenbank-Passwörter gehören deshalb ausschließlich in den Secret-Speicher deines CI-Anbieters und werden als Umgebungsvariablen eingespeist.
Zwei Ergänzungen, die man leicht übersieht: Erstens loggen viele Skripte im Fehlerfall ihre Umgebung mit — prüfe, dass deine Ausgaben keine Tokens enthalten. Zweitens sollte der Schlüssel, mit dem die Pipeline auf deinen Server kommt, nur das dürfen, was er dafür braucht. Ein Root-Zugang für ein Deployment-Skript ist bequem und im Fall eines kompromittierten CI-Kontos ein Totalschaden.
Ein Rollback-Weg ist Pflicht
Eine Pipeline, die nur vorwärts kann, ist unvollständig. Bevor du die erste automatische Auslieferung scharf schaltest, brauchst du eine Antwort auf die Frage: Was mache ich, wenn der Deploy die Anwendung kaputtmacht und ich in fünf Minuten wieder online sein muss?
Für kleine Setups reicht dafür erstaunlich wenig. Halte die letzten Builds vor, sodass ein Zurückschalten ein einzelner Befehl ist. Trenne Datenbankmigrationen vom Code-Deploy, damit ein Rückschritt im Code nicht an einem bereits geänderten Schema scheitert. Und mach nach jedem Deploy einen automatischen Aufruf einer Statusseite deiner Anwendung — wenn der fehlschlägt, willst du das von der Pipeline erfahren und nicht vom Kunden.
Der eigentliche Gewinn ist nicht die Zeitersparnis
Wenn man ehrlich rechnet, spart eine Solo-Pipeline nicht dramatisch viele Minuten. Der Gewinn liegt woanders: Sie senkt die Hemmschwelle, überhaupt zu deployen.
Ohne Automatisierung wird jedes Ausliefern zu einem kleinen Ereignis, das man lieber auf später schiebt — und weil man es aufschiebt, wird der nächste Deploy größer, riskanter und wieder aufschiebenswerter. Mit einer Pipeline, die in drei Minuten durchläuft, deployst du eine Zeilenänderung ohne nachzudenken. Genau diese Häufigkeit ist es, die Software stabil hält, nicht die Sorgfalt vor dem einzelnen großen Release.
Der zweite Gewinn zeigt sich erst später: Eine Pipeline ist die einzige Dokumentation deines Deployment-Prozesses, die nicht veralten kann, weil sie ausgeführt wird. Wenn du ein Projekt nach acht Monaten wieder anfasst — oder es an jemanden übergibst — steht in dieser Datei exakt, wie aus Quellcode ein laufendes System wird. Das ist mehr, als die meisten Projekte über sich selbst wissen.
Fang klein an: Build und Linter in der Pipeline, alles andere manuell. Erweitere erst, wenn dich ein konkreter Fehler dazu zwingt. Eine Pipeline, die aus Schmerzen gewachsen ist, passt besser als eine, die du am ersten Tag nach Vorlage gebaut hast.
Wenn du wissen willst, wie schlank andere ihre Setups halten: Im Discord der Community werden solche Konfigurationen regelmäßig herumgereicht.