Wenn Deployment Routine wird,
gehört es ins Skript
Browser-Upload ist der schnellste erste Beweis. Wenn derselbe statische Build regelmäßig veröffentlicht wird, gehört der Release-Schritt ins Terminal, in CI oder ins Team-Playbook.
Für Releases, die mehr als einmal passieren
Nicht auf manuelle Erinnerung verlassen
Ein Deploy-Befehl macht aus einem wiederholten Upload einen Release-Schritt, den ein Team dokumentieren, prüfen und zuverlässig ausführen kann.
CI den letzten Schritt machen lassen
Wenn GitHub Actions oder ein anderes CI-System bereits den Build-Ordner erzeugt, sollte der Deployment-Schritt genau diesen Ordner ohne manuelles Nachladen veröffentlichen.
Dasselbe Projektmodell behalten
Starten Sie mit Browser-Upload und verschieben Sie dasselbe Projekt später in Automatisierung, wenn daraus ein echter Release-Pfad wird.
Manuell starten, automatisieren wenn es sich lohnt
Einmalige Vorschauen sollten einfach bleiben. CLI lohnt sich, wenn eine Website wiederholt veröffentlicht, von einem Team geprüft oder von einer Build-Pipeline ausgelöst wird.
steps:
- uses: actions/checkout@v2
- run: npm install && npm run build
- run: npx @deploypages/cli deploy ./dist --token ${{ secrets.DEPLOY_TOKEN }}Häufige Fragen
Q: Läuft das unter Windows, macOS und Linux?
Ja. Ein sinnvoller CLI-Flow muss zu den Betriebssystemen passen, die Teams bereits für lokale Builds und CI-Runner verwenden.
Q: Kann ich aus Automatisierung ein bestimmtes Projekt ansprechen?
Ja. Skriptbares Deployment ist nur nützlich, wenn Teams den Release-Flow eindeutig an den richtigen Projektkontext binden können.
Q: Passt das zu Monorepos?
Ja. Teams mit Monorepos brauchen einen Deployment-Pfad, der gezielte Arbeitsverzeichnisse und Ausgabeordner sauber veröffentlichen kann.
Starten Sie mit dem, was jede statische Website schon hat
Laden Sie die gebauten Dateien hoch, erhalten Sie einen HTTPS-Link und ergänzen Sie Domain, Rollback, Statistik, Automatisierung und Teamkontrolle genau dann, wenn das Projekt sie braucht.