Zurück zu ogschaut

GitHub-Deployment-Plattform

GitHub-Deployment mit prüfbarer Preview vor Production

Ein GitHub-Deployment auf ogschaut beginnt mit einem signierten Push oder Pull Request. Der exakte Commit wird isoliert gebaut, als unveränderlicher Image-Digest gespeichert und als Preview veröffentlicht. Production erhält diesen geprüften Digest ohne versteckten Rebuild.

GitHub verbinden Alternativen vergleichen

Vom GitHub-Ereignis zur Production-Route

Die Quellcode-Zugangsdaten existieren nur während des Checkouts. Build und Runtime bleiben getrennte Vertrauensgrenzen.

  1. 1

    GitHub prüfen

    GitHub-App-Installation, Repository-Identität, Webhook-Signatur, Ref und Commit werden geprüft, bevor Arbeit in die Warteschlange gelangt.

  2. 2

    Den exakten Commit bauen

    Ein Rootless-BuildKit-Worker erhält ein kurzlebiges Installation-Token und begrenzte Build-Variablen. Er pusht ausschließlich einen unveränderlichen Image-Digest.

  3. 3

    Eine unabhängige Preview veröffentlichen

    Jede Preview erhält einen eigenen Workload und eine eigene URL. Die Readiness-Prüfung muss erfolgreich sein, bevor die Route an den Pull Request zurückgegeben wird.

  4. 4

    In der richtigen Reihenfolge übernehmen

    Production-Traffic wechselt ausschließlich zur höchsten akzeptierten Release-Sequenz. Ein langsamer älterer Build kann kein neueres Release ersetzen.

  5. 5

    Rollback ohne Rebuild

    Ein bekannter Image-Digest wird zu einem neuen, geordneten Production-Release. Der vorherige Workload bleibt gestoppt und wiederherstellbar.

Unterstützte Quelle

GitHub-App-Repositories und signierte Push- oder Pull-Request-Ereignisse

Unterstützte Builds

Dockerfile, Node, Next.js und Static; adapterbasierte Projekte mit einem Production-Startbefehl

Runtime-Vertrag

Nicht-Root-Container, Port 8080, Readiness vor Traffic und explizite CPU-/Arbeitsspeicherlimits

Fragen zum GitHub-Deployment

Baut Production das Repository erneut? Nein. Production erhält den vom Deployment erstellten unveränderlichen Image-Digest. Auch ein Rollback verwendet einen gespeicherten Digest erneut.
Können mehrere Pull-Request-Previews gleichzeitig laufen? Ja. Preview-Workloads und Hosts sind deployment-spezifisch. Die Production-Release-Reihenfolge fasst unabhängige Previews nicht zusammen.
Werden GitHub-Tokens in Deployments gespeichert? Nein. Ein kurzlebiges Installation-Token wird für einen einzelnen Checkout angefordert und weder im Deployment noch im Build-Ergebnis oder Runtime-Payload gespeichert.