Erste Schritte

Installieren

gooddeploy ist ein einzelnes Programm für macOS und Linux. Installiere es mit:

curl -fsSL https://gooddeploy.de/install.sh | sh

Das Skript lädt die passende Version für dein System, prüft die Prüfsumme und legt gooddeploy nach /usr/local/bin (falls beschreibbar) oder nach ~/.local/bin. Bei Bedarf ergänzt es deinen PATH und richtet die Tab-Vervollständigung für zsh und bash ein.

Ob alles geklappt hat, siehst du mit:

gooddeploy version
gooddeploy help

gooddeploy help zeigt alle Befehle. Die Optionen eines Befehls siehst du mit --help hinter dem Befehl, z. B. gooddeploy deploy --help (oder gooddeploy help deploy). Vertippst du dich bei einem Befehl, schlägt gooddeploy den passenden vor.

Optionen für das Skript (als Umgebungsvariablen vor sh):

Die Tab-Vervollständigung kannst du auch selbst erzeugen: gooddeploy completion zsh bzw. gooddeploy completion bash gibt das Skript aus.

Anmelden

gooddeploy login

gooddeploy fragt nach deiner E-Mail-Adresse. Hast du dich auf diesem Rechner schon einmal angemeldet, steht die zuletzt benutzte Adresse in Klammern; Enter übernimmt sie.

E-Mail-Adresse [du@agentur.de]:

gooddeploy zeigt dann einen Code wie KXQT-7PRM (im Terminal in einem Kasten) und schickt dir eine E-Mail mit einem Link; während du bestätigst, läuft die Zeit bis zum Ablauf des Codes mit. Öffne den Link, gib dort den Code aus deinem Terminal ein, und gooddeploy meldet dich an, sobald du bestätigt hast. Bestätige nur, wenn du gerade selbst gooddeploy login ausgeführt hast. Danach begrüßt dich gooddeploy mit deinem Namen und zeigt, auf welche Projekte du mit welchen Rechten zugreifen darfst. Die Anmeldung gilt eine Weile; wie lange, zeigen login und whoami („Gültig bis …“).

Mit Zugangscode

In der Pilotphase bietet die Plattform den Login per E-Mail noch nicht überall an. Dann sagt login nach der Adresse „Der Login per E-Mail ist … noch nicht verfügbar“ und fragt stattdessen nach deinem Zugangscode, den du von goodDEV bekommst. Den Code fragt gooddeploy verdeckt ab; Leerzeichen beim Abtippen zählen nicht. Der Code wird sofort geprüft. Lässt du die Frage nach der E-Mail leer (ohne Vorschlag), geht es ebenfalls direkt zum Zugangscode.

Die Anmeldung liegt in ~/.config/gooddeploy/auth.json (bzw. unter $XDG_CONFIG_HOME/gooddeploy/). Ordner und Datei sind nur für dich lesbar. Teile diese Datei nicht und lege sie nie in ein Git-Repo.

Wer bin ich, was darf ich?

gooddeploy whoami

In Skripten

Ohne Terminal (z. B. in einem Skript) fragt login nicht nach. Gib dort die Adresse oder den Code mit:

gooddeploy login --email du@agentur.de
gooddeploy login --token <zugangscode>

Ohne beides liest login den Zugangscode aus der ersten Zeile der Standardeingabe; ist sie leer, endet login mit einem Hinweis auf beide Aufrufe (Exit-Code 1). login --email fragt nie nach einem Zugangscode: Bietet die Plattform den Login per E-Mail noch nicht an, endet es mit „noch nicht verfügbar“ (Exit-Code 6). In der CI brauchst du gar kein login: Setze dort GOODDEPLOY_TOKEN (siehe Für Skripte und CI).

Mehrere Teams

Gehörst du mehreren Teams an (z. B. ein Team je Kunde deiner Agentur), gilt eine Anmeldung immer für genau ein Team. Du wählst es auf der Seite aus der E-Mail oder gleich beim Aufruf:

gooddeploy login --email du@agentur.de --team "Kunde Süd"

--team nimmt den Namen oder die ID des Teams. Passt der Name zu keinem deiner Teams, zeigt die Seite die Auswahl. Für ein anderes Team meldest du dich einfach noch einmal mit --team an.

Abmelden

gooddeploy logout

löscht die Anmeldung auf diesem Rechner. Die API-Adresse und deine E-Mail-Adresse bleiben in auth.json stehen, damit sich ein späteres gooddeploy login wieder bei derselben Plattform anmeldet und die Adresse vorschlägt. Dein Zugangscode bleibt gültig; wenn er nicht mehr gelten soll, sag goodDEV Bescheid. Ist GOODDEPLOY_TOKEN gesetzt, weist logout darauf hin, dass Befehle weiter diesen Zugang nutzen.

Projekt verknüpfen

Jedes Deploy gehört zu einem Projekt, z. B. kunde-website. Projektnamen haben 3 bis 30 Zeichen, nur Kleinbuchstaben, Ziffern und einzelne Bindestriche.

Am einfachsten verknüpfst du dein Repo einmal mit dem Projekt:

cd mein-repo
gooddeploy link kunde-website

link prüft, ob es das Projekt gibt, und schreibt .gooddeploy/project.json. Danach brauchst du in diesem Repo kein --project mehr. Ohne Namen fragt link im Terminal nach dem Namen und schlägt einen vor (aus dem Feld name in package.json, sonst aus dem Ordnernamen).

gooddeploy bestimmt das Projekt in dieser Reihenfolge:

1. --project <name> beim Aufruf,
2. die Umgebungsvariable GOODDEPLOY_PROJECT,
3. die Datei .gooddeploy/project.json im Repo,
4. sonst fragt deploy im Terminal nach dem Namen; ohne Terminal gilt der Name deines Repo-Ordners, aber nur, wenn es dieses Projekt schon gibt.

Neues Projekt anlegen

Gibt es das Projekt noch nicht, legt gooddeploy es nicht nebenbei an, sondern fragt im Terminal nach:

? Projektname [kunde-website]:
? Projekt kunde-website gibt es noch nicht. Jetzt anlegen? (J/n)
✓ Projekt kunde-website angelegt
? Postgres anlegen? (J/n)

Enter übernimmt jeweils den Vorschlag. Das geht mit gooddeploy link und beim ersten gooddeploy deploy; zum Anlegen brauchst du das Recht deploy. Ohne Terminal (Skript, CI) legt gooddeploy kein Projekt an: deploy und link enden dann mit NOT_FOUND (Exit-Code 1) und dem Hinweis auf gooddeploy link <name>. In einem Skript legst du ein Projekt ausdrücklich mit gooddeploy link <name> --yes an, mit Postgres per --yes --postgres.

Gut zu wissen: Postgres je Projekt bietet die Plattform noch nicht an. Auf „Postgres anlegen?“ antwortet gooddeploy dann „Postgres ist auf diesem Server noch nicht verfügbar; das kommt später.“; das Projekt ist trotzdem angelegt.

Die Verknüpfung gehört nicht ins Git

.gooddeploy/project.json ist eine lokale Verknüpfung zwischen deinem Ordner und dem Projekt. Damit sie nicht im Git landet, legt gooddeploy daneben .gooddeploy/.gitignore an; der Ordner ignoriert sich damit selbst, git status bleibt sauber, und deine eigene .gitignore bleibt unberührt. Kolleginnen und Kollegen verknüpfen ihren Checkout selbst mit gooddeploy link.

Liegt dein Projekt in einem Unterordner (z. B. site/), deployst du mit --dir site. Hast du das Repo mit gooddeploy link verknüpft, nimmt deploy --dir site die Verknüpfung aus dem Repo-Root; ein Projekt je Repo ist der Normalfall. Gibt es keine Verknüpfung, landet sie beim ersten Deploy in site/.gooddeploy/project.json, und die gilt dann für site/. Aus site/ heraus funktionieren status, promote und rollback in beiden Fällen ohne --project.

Wie geht es weiter?

• Deploy, Preview, Promote, Rollback: deine erste Seite online bringen.
• Rechte: was dein Zugangscode darf.