Zielgruppen

Sailwright ist ein einziges Werkzeug, löst aber je nach Perspektive ein anderes Problem. Finden Sie unten Ihre Rolle – jeder Abschnitt verlinkt zur Funktion oder zum Workflow, der die jeweilige Aussage untermauert.

Entwickler & Power-User

Ihre Maschine ist Ihre Werkstatt, und sie driftet: schnelle Installationen, PATH-Hacks, „vorübergehende“ Fixes, an die sich niemand mehr erinnert. Sailwright behandelt Ihre Workstation wie ein gemanagtes Ziel – sailwright provision local --check zeigt genau, welche Abweichungen zum Sollzustand bestehen; führen Sie den Befehl dann aus, ist wieder alles im definierten Zustand. Ein einziges Tool, kein Server, kein Konto.

Lernen Sie, wie Sie das eigene Gerät überprüfen, oder laden Sie sich ein Release herunter und probieren Sie es direkt auf Ihrer eigenen Maschine aus.

Platform- und Developer-Experience-Teams

Sie verantworten das Onboarding und die System-Setup-Konsistenz in der gesamten Organisation. Mit Sailwright lebt das Maschinen-Setup des Teams in versionierten Ansible-Rollen statt in Wiki-Seiten – neue Mitarbeitende führen einen einzigen Befehl aus, und jede Maschine erhält die äquivalente Konfiguration auf macOS, Windows und Linux.

Siehe Onboarding neuer Entwickler und Gestaffelte Ansible-Rollenquellen.

DevOps- und SRE-Ingenieure

Entwicklungsmaschinen sind die Umgebung, die sich in einem Team am schwersten konsistent halten lässt: manuelle Installationen, punktuelle Fixes, Abweichungen, die niemand bemerkt, bis etwas kaputtgeht. Sailwright baut ein VM-Image einmal und teilt es über eine beliebige OCI-Registry mit sailwright push und pull – jeder Laptop lädt dasselbe bewährte Artefakt, statt von Grund auf neu zu provisionieren, und eine neu aufgebaute Maschine konvergiert exakt zum Zustand derjenigen, die sie ersetzt.

Siehe Build-Artefakte wiederverwenden statt neu bauen.

Admins von Entwicklungssystemen & gemischten Betriebssystemflotten

Sie managen die Maschinen, an denen Entwickler tatsächlich arbeiten – oft Windows und macOS nebeneinander, meist mit einem MDM, das dort endet, wo Entwickler-Tooling beginnt. Sailwright deckt diese letzte Meile ab, ohne Ihre Angriffsfläche zu vergrößern: Unter Windows öffnet es nur für die Dauer der Ausführung einen temporären, ausschließlich lokal erreichbaren WinRM-Listener (oder einen temporären, lokal erreichbaren SSH-Zugang) und stellt danach den vorherigen Status der Maschine wieder her. Es bleibt keine dauerhafte Management-Schnittstelle zurück.

Siehe Windows sicher managen.

QA- und Testingenieure

Tests gegen einen sauberen, bekannten Maschinenzustand sollten nicht bedeuten, Hardware zu horten oder Test-VMs zu hegen und zu pflegen. build, create, provision, destroy: Wegwerf-Testsysteme mit exakter Spezifikation auf Abruf – mit --check, um vorab zu sehen, was eine Änderung bewirken würde, bevor sie tatsächlich angewendet wird.

Siehe Provisioning-Änderungen sicher testen.

KI-Agenten & Agent-Harnesses

Ihre Agenten brauchen einen Rechner, den sie ruhig kaputt machen dürfen. Sailwright baut eine VM aus einem wiederverwendbaren Image, richtet sie per Ansible ein und zerstört sie, sobald der Lauf beendet ist. Hängen Sie vorab --check an provision, um zu sehen, was eine von einem Agenten geschriebene Änderung bewirken würde. Vorgefertigte Ubuntu-Images ziehen Sie aus einer OCI-Registry, statt sie neu zu bauen. Unter Linux mit QEMU/KVM führt scripts/quickstart.sh den gesamten Lebenszyklus mit einem einzigen Befehl aus und räumt auch dann auf, wenn ein Schritt fehlschlägt.

Siehe Test-Workflows.

Teamleitungen & Onboarding-Verantwortliche

Jede Stunde, die ein erfahrener Entwickler damit verbringt, einen neuen Kollegen durch das Setup zu führen, ist eine Stunde, in der zwei Personen nicht produktiv sind. Sailwright macht aus diesem halben Tag manueller Installationen und Slack-Fragen einen einzigen Befehl – und verwandelt „wie soll eine Maschine eigentlich aussehen?“ von institutionellem Wissen in ein versioniertes Repository.

Siehe Onboarding neuer Entwickler.

IT-Entscheider

Sailwright ist kostenlos und Open Source unter der AGPLv3 – Ihre Organisation kann es ohne Lizenzkosten nutzen, auch kommerziell. Es ergänzt das MDM-/UEM-Tooling, das Sie bereits einsetzen, statt damit zu konkurrieren. Und es bleibt nachvollziehbar: Die Automatisierung ist reines Ansible in Ihren eigenen Repositories, keine Blackbox.

Details zur Lizenzierung finden Sie unter Über uns.

Open-Source-Mitwirkende, Beratungen & MSPs

Das mehrschichtige Rollenmodell ist für die gemeinsame Nutzung gedacht: Öffentliche Basisrollen bilden die Grundlage, private Overrides legen sich darüber, und nichts muss geforkt werden. Beratungen pflegen eine kundenspezifische Schicht auf einer gemeinsamen Basis, Mitwirkende erweitern die öffentliche Rollenbibliothek.

Siehe Mehrere Ansible-Rollenquellen und Mitwirken.

Klingt nach Ihrem Team?

Die Szenarien im Detail finden Sie unter Anwendungsfälle, die vollständige Befehlsübersicht unter Funktionen, oder legen Sie direkt los: Releases auf GitHub, Setup in der Dokumentation. Fragen? Nehmen Sie Kontakt auf.