Bau dir Tools, die du wirklich brauchst
Wie individuelle Automatisierung Zeit spart, Fehler reduziert und Wissen im Team nachhaltig verfügbar macht
In der Softwareentwicklung liegt der Fokus meistens auf dem Projektfortschritt. Nicht selten fallen dabei sogenannte „Chores“, also lästige Pflichten, unter den Tisch. Die Gründe dafür sind zahlreich, das Ergebnis oft dasselbe: schleichende Qualitätsverluste, technische Schulden und Erschwernisse bei der Entwicklung. In diesem Beitrag berichte ich von unserem aktuellen Projekt und zeige, wie sich ein genau solches Thema nach und nach zu einem Problem für uns entwickelt hat und wie wir es mit einer selbst implementieren Lösung in den Griff bekommen konnten.
In unserem Projekt entwickeln wir eine Reihe unabhängiger, in sich geschlossener Systeme, jedes dieser Systeme hat eine eigene Codebasis, Datenbank, Docker-Containern und Infrastruktur. Die Aufteilung unserer Anwendungsfälle in mehrere Services ist fachlich zwar sinnvoll, führt im Alltag aber zu einigem Mehraufwand: Wir müssen ständig zwischen diesen Systemen hin und her wechseln. Der Aufwand liegt dabei also nicht im erstmaligen Aufsetzen eines Services, sondern im häufigen Kontextwechsel während der Implementierungsphase.
Bei eben diesem Kontextwechsel kommt es dann bspw. zu Overhead durch das Neustarten von Docker-Containern und Services, sowie das Einspielen von Testdaten.
Das Problem: Wiederholung der immer selben Schritte
Woran sich diese Reibung konkret bemerkbar macht, zeigt sich im Alltag sehr deutlich. Denn die ständigen Wechsel zwischen den Anwendungen führen zu mehreren negativen Effekten:
Besonders spürbar wird das, wenn mehrere Personen im Team aufgrund von parallelen Arbeiten regelmäßig zwischen Anwendungen wechseln müssen und auch wenn neue Kolleg:innen eingearbeitet werden.
Unsere Vorstellung: Projektwechsel per Tool statt aus dem Gedächtnis
Im Alltag zeigt sich schnell: Die eigentliche lästige Arbeit liegt nicht in den einzelnen Anwendungen, sondern in den vielen kleinen, sich ständig wiederholenden Schritten beim Wechsel zwischen ihnen. Statt uns weiterhin auf individuelle Skripte, verstreute Dokumentationen und das Gedächtnis des Teams zu verlassen, vereinheitlichen und vereinfachen wir diesen Prozess gezielt.
Unser Ansatz war, eine zentrale Anlaufstelle zu schaffen, die den Wechsel zwischen unseren Anwendungen für alle gleichermaßen steuert. Ein Werkzeug, das wiederkehrende Abläufe automatisiert, sich direkt im Terminal nutzen lässt und so wenig Hürden wie möglich mitbringt, damit es im Alltag auch wirklich verwendet wird. Gleichzeitig sollte die Lösung genau auf unsere Projektstruktur zugeschnitten sein und unabhängig vom Betriebssystem funktionieren.
Aus diesem Bedarf heraus ist ein eigenes CLI-Tool entstanden: der „Project Starter“.
Der Project Starter
Die Oberfläche: ein zentrales Menü im Terminal
Der Project Starter ist eine interaktive Konsolenanwendung. Beim Start erscheint ein Menü, über das sich die wichtigsten Aktionen ausführen lassen: Anwendungen auswählen, bauen und starten, Tests ausführen, Dependencies installieren und noch weitere Funktionen. Die Funktionen, die mittlerweile über das einfache Wechseln der lokalen Entwicklungsumgebung für verschiedene Anwendungen hinaus gehen, wurde nach und nach erweitert und können jederzeit ergänzt werden.
Statt sich verschiedene Befehle merken oder in der Dokumentation nachschlagen zu müssen, kann man direkt durch ein Menü navigieren. Die Bedienung ist dabei bewusst einfach gehalten, damit das Tool nicht mehr Komplexität schafft, als es reduzieren soll.
Die Wechselfunktion: das Herzstück
Die Vorteile des Project Starters sind am deutlichsten beim eigentlichen Projektwechsel spürbar. Mit einem Tastendruck gelangt man in ein Kontextmenü, in dem die verfügbaren Projekte angezeigt und gefiltert werden können. Nach der Auswahl eines Projekts übernimmt das Tool die Arbeit:
Nicht mehr benötigte Container und Volumes werden entfernt, neue Services gestartet, Builds angestoßen und Testdaten eingespielt. Aus mehreren manuellen Kommandos wird damit ein konsistenter, automatisierter Ablauf, der mit nur einem Knopfdruck ausgeführt werden kann.
Für die Nutzenden reduziert sich der Wechsel auf wenige Befehle. Alles andere läuft automatisch im Hintergrund ab, nachvollziehbar durch Logs im Terminal-Output. Da der Code zum Project Starter in einem eigenen Repository für das Projektsetup eingecheckt ist, wird es für alle im Team zugänglich und kann schnell und einfach erweitert werden.
Wo der Project Starter gut funktioniert
Damit der Project Starter zuverlässig arbeiten kann, braucht es eine gewisse Einheitlichkeit in den Projekten. Bei uns bedeutet das:
Weil wir diese Standards im Vorfeld etabliert haben, können wir nun einen Großteil unserer Anwendungen über das Tool steuern, ohne für jedes Projekt spezielle Wege gehen zu müssen. Die notwendige Vereinheitlichung ist also weniger eine Einschränkung, sondern vielmehr eine Voraussetzung für Automatisierung und zudem ein guter Standard, der es ermöglicht, sich in jedem Projekt gut zurechtzufinden.
Uns war wichtig, diese Automatisierung selbst in die Hand zu nehmen, und mit überschaubarem Aufwand ein Tool zu entwickeln, das genau zu unserer Struktur passt und im Alltag tatsächlich genutzt wird. Dadurch bleibt der Code bei uns: es entstehen keine Mehrkosten und Abhängigkeiten, gleichzeitig sind bei Bedarf schnellere Anpassungen möglich.
Verwendete Technologie
Für den Project Starter setzen wir bewusst auf einfache, aber flexible Technologien: Bash als Skriptsprache und Gum für die interaktive Nutzung im Terminal, ergänzt durch klassische Unix-Werkzeuge.
Die gesamte Anwendungslogik ist in Bash umgesetzt. Ausschlaggebend dafür waren vor allem die breite Verfügbarkeit auf Unix-basierten Systemen (inklusive macOS, Linux und WSL), die nahtlose Integration bestehender Tools wie Docker, sowie die geringe Einstiegshürde für Entwickler:innen. Im Skript selbst kommen typische Shell-Mechanismen zum Einsatz, etwa Funktionen zur Kapselung wiederkehrender Abläufe, Conditional Statements zur Steuerung des Programmflusses, sowie das Einlesen von Konfigurationsdateien (z. B. .env- oder .sh-Files), um projektbezogene Parameter dynamisch zu verwalten.
Für die Interaktion im Terminal nutzen wir Gum. Damit lassen sich ohne großen Overhead interaktive Elemente wie Auswahlmenüs, Eingabemasken oder Bestätigungsdialoge realisieren. Gleichzeitig ermöglicht Gum eine strukturierte und visuell klarere Ausgabe von Statusmeldungen und Fehlern. So bleibt die gesamte Logik in der Shell, während die Nutzung deutlich an Qualität gewinnt – ohne den Einsatz eines vollwertigen UI-Frameworks.
Fazit: individuelle Automatisierung lohnt sich
Mit dem Project Starter entsteht eine Lösung, die genau dort ansetzt, wo sich lästige Aufgaben wiederholen: beim Setup lokaler Infrastruktur und dem Wechsel zwischen Projekten. Anstatt immer wieder von vorne zu beginnen, folgt der Wechsel nun einem klar definierten, automatischen Ablauf.
Der Effekt ist deutlich: weniger Zeit und Aufwand pro Anwendungswechsel, weniger Fehler, weniger Frust – und ein schnelles, leichtgewichtiges Onboarding. Nicht zuletzt, weil das Wissen über lokale Infrastruktur nicht mehr nur in den Köpfen der Entwickelnden oder verstreut in Dokumentationen liegt, sondern zentralisiert in einem Tool gebündelt ist.
Für andere Teams bedeutet das: Gerade wenn Standardlösungen nicht zu speziellen Projektanforderungen passen, lohnt es sich, ein kleines Tool selbst zu schreiben. Es ist schnell entwickelt, kostengünstig, lässt sich flexibel erweitern und verbessert spürbar den Arbeitsalltag des Teams.
Der Project Starter zeigt, dass sich eine individuelle Automatisierung auszahlt:
Über den Autor
Luca Fehmel ist Software Engineer bei BettercallPaul und bringt ein starkes Gespür für Qualität, Struktur und nachhaltige Lösungen mit. Er arbeitet als Fullstack-Entwickler mit Fokus auf agiles Projektvorgehen und der Entwicklung von Projektinfrastruktur. Sein Ziel ist es komplexe Systeme & Prozesse verständlich und stabil zu implementieren.
Dabei verbindet er technisches Know-how mit einem guten Blick für Teamdynamik: Er fördert den Austausch und trägt dazu bei, ein Umfeld zu schaffen, in dem Zusammenarbeit und kontinuierliche Verbesserung selbstverständlich sind.
