Production Artifacts

Was ist ein Artifact?

Nutze artifact, wenn du für einen unterstützten Stack eine Production-Ausgabe vorbereiten möchtest. dwell build bereitet zuerst den lokalen Workspace vor; es ist selbst kein Production-Build.

• Die Ausgabe entsteht separat in artifact/ im Projektwurzelverzeichnis.
• Dwell installiert Backend-Abhängigkeiten für Production und baut unterstützte Vite-Frontends.
• Quellcode, Manifeste und Lockfiles im ursprünglichen Workspace bleiben unverändert.

Unterstützte Kombinationen

Die folgenden Kombinationen sind aktuell unterstützt. Die lokale Entwicklungsunterstützung eines Stacks bedeutet nicht automatisch, dass auch artifact ihn unterstützt.

Symfony ohne Frontend

Symfony-Anwendung mit Production-Composer-Abhängigkeiten; Webroot public/.

Symfony mit React + Vite oder Vue + Vite

Eine Symfony-Anwendung, deren public/ auch die gebauten Frontend-Dateien enthält.

Laravel, TYPO3 oder Shopware 6 ohne separates Frontend

Die jeweilige Backend-Anwendung mit Production-Abhängigkeiten; Webroot public/.

WordPress ohne separates Frontend

Composer-verwaltete WordPress-Anwendung; Webroot wordpress/.

Nicht unterstützt sind Laravel oder CMS mit einem separaten React/Vue-Frontend, reine Frontend-Projekte und Custom-Rollen. Dwell meldet diese Kombinationen vor dem Artifact-Build; bereite deren Production-Ausgabe mit deinem eigenen Prozess vor.

Standard-Workflow

Arbeite im Projektordner. Bereite den Workspace vor und behalte die Dependency-Lockfiles. Erst danach erstellst du das Artifact:

dwell build

dwell artifact

• Das Backend braucht composer.json, composer.lock, Docker und das konfigurierte PHP-Build-Image. Die Installation kann Paketregistries kontaktieren.
• Für React/Vue brauchst du eine passende Node-Version, npm, package.json, package-lock.json und einen funktionierenden Vite-Build-Command.
• Existiert artifact/ bereits, verschiebe die vorige Ausgabe bewusst an einen anderen Ort, bevor du erneut baust. Dwell überschreibt sie nicht.

Dwell arbeitet in einer temporären Kopie und veröffentlicht artifact/ erst nach erfolgreichen Prüfungen. Bei einem Fehler wird diese Kopie entfernt; dein Workspace bleibt erhalten. Lies die Diagnose und behebe die Ursache, statt eine alte Ausgabe als neuen erfolgreichen Build zu behandeln.

Ausgabe verwenden

Die CLI nennt das Ausgabeverzeichnis und den Webroot. Beispiel: Bei Symfony + React werden Backend-Dateien ins Artifact-Root übernommen und das gebaute Frontend in artifact/public/ integriert. Die Entwicklungsordner backend/ und frontend/ bleiben getrennt.

Richte auf dem Zielserver Production-Environment, Datenbankverbindung, Domains, Mail und weitere benötigte Services ein. Lokale .env-Dateien und lokale Zugangsdaten werden nicht als Production-Konfiguration übernommen. Composer-Anwendungsscripts führt Dwell nicht aus; nötige Setup-, Migrations- oder Cache-Schritte planst du für deine Anwendung selbst.

Frontend-Builds bekommen keine lokalen .env-Dateien oder geerbten Anwendungs-Secrets. Lege beabsichtigte öffentliche Production-Einstellungen in der Build-Konfiguration fest und prüfe das Bundle. Production-API-Adressen und SPA-Routing auf dem Server verantwortest du selbst.

Was Dwell hier nicht übernimmt

• Kein Upload und kein Deployment.
• Kein Production-Server-Setup, Hosting oder Start einer Production-Runtime.
• Keine Erzeugung von Production-Secrets.
• Kein Datenbankexport als Teil des Artifacts.

Hinweise & Grenzen

Prüfe Anwendung und Ausgabe vor einer Weitergabe: Beliebige im Quellcode fest eingetragene Secrets kann Dwell nicht erkennen. Die Standard-Vite-Pipeline muss die unterstützten Build-Argumente akzeptieren. Externe Composer-Path-Pakete außerhalb des kopierten Backends werden abgelehnt. Genaue Ausschlüsse, Dateikollisionen, Symlinks und Fehlerverträge stehen in der technischen Referenz.

Als Nächstes

Sichere Anwendungsdaten separat mit dem Datenbank-Guide. Bei einem fehlgeschlagenen Build hilft der Troubleshooting-Guide beim Einordnen der Voraussetzungen.

Technische Referenz