Deploys und Rollbacks

Was während eines Deploys passiert

1. Build. Mit einem Repository baut Railyard ein Image auf einem dedizierten Build-Server, falls dein Team einen hat, sonst auf dem eigenen Server der App oder einem temporären Build-Server, den Railyard für den Job startet. Mit einer image://-Quelle wird das Image stattdessen gepullt; es wird nichts gebaut. Siehe Build-Methoden.
2. Release-Befehl. Falls die App einen gesetzt hat, läuft er einmal gegen das neue Image, bevor überhaupt Traffic ankommt. Hier gehören Migrationen hin. Schlägt er fehl, stoppt der Deploy an dieser Stelle, und die App läuft weiter mit ihrer alten Version.
3. Health-Check. Der neue Container startet neben dem bereits laufenden. Er muss hochkommen und, falls die App einen Health-Check-Pfad gesetzt hat, innerhalb des konfigurierten Timeouts darauf antworten.
4. Traffic-Umschaltung. Erst wenn der neue Container den Check besteht, wechselt der Traffic zu ihm. Ein Standard-Deploy verschiebt alles auf einmal; ein Canary-Deploy schickt zuerst nur einen Anteil. Siehe Canary-Deploys und Deploy-Fenster.
5. Alte Version stoppt. Der vorherige Container bleibt laufen, bis der neue bestätigt ist, und wird dann entfernt. Das macht Deploys zero-downtime: Es gibt keinen Moment, in dem die App keinen funktionierenden, antwortenden Container hat.

Wenn etwas fehlschlägt

Schlägt der Build, der Release-Befehl oder der Health-Check fehl, lässt Railyard die vorherige Version weiterlaufen und markiert den Deploy als fehlgeschlagen. Ein fehlgeschlagener Deploy legt deine App niemals lahm. Die Deploy-Seite erklärt, was fehlgeschlagen ist, und verlinkt auf eine Lösung; siehe Fehlgeschlagene Deploys beheben.

Zurückrollen

Ein Rollback deployt erneut den Commit (oder das Image) eines früheren erfolgreichen Releases und stellt die Variablen wieder her, mit denen es lief. Die Bestätigungsseite listet auf, welche Variablen sich zurückändern, und warnt, falls sich ein Secret seit diesem Release geändert hat. Um die heutigen Variablen zu behalten und nur den Code wiederherzustellen, wähle “nur Code” (oder übergib es als Flag/Parameter).

• Dashboard: Wähle auf dem Tab Releases & deploys der App Roll back to v<n> neben einem früheren erfolgreichen Release.
• CLI: railyard releases my-app listet Releases zum Zurückrollen; railyard rollback my-app <version> [--code-only].
• API: POST /api/applications/:id/deploys mit rollback_to (der ID eines früheren erfolgreichen Deploys) und optional "restore_config": false.

Ein Rollback ist selbst ein Deploy: Er durchläuft denselben Build-oder-Pull, Release-Befehl, Health-Check und Traffic-Umschaltung wie jeder andere Deploy und respektiert das Deploy-Fenster der App, sofern du es nicht überschreibst. Releases, die deployt wurden, bevor Railyard anfing, eine Kopie ihrer Variablen aufzubewahren, können nur ihren Code zurückrollen.

Release-Historie

Jeder erfolgreiche Deploy mit einem Commit wird als Release durchnummeriert (v1, v2, …). Der Tab Releases & deploys der App listet sie, mit älteren Deploys einen Klick entfernt; railyard deploys --app my-app und GET /api/deploys?application_id=:id zeigen die vollständige Historie über CLI und API. Jeder Deploy behält sein Log, seinen Trigger, seinen Commit und eine eventuelle Notiz.

Siehe auch

• Canary-Deploys und Deploy-Fenster — Releases mit partiellem Traffic, geplante und zeitlich begrenzte Deploys, Deploy-Notizen.
• Build-Methoden — welcher Builder läuft und wie Builds zu deinen Servern passen.
• Fehlgeschlagene Deploys beheben — was jeder Fehlergrund bedeutet und wie man ihn behebt.