Preview-Umgebungen

pb preview up erstellt eine vollständige Kopie einer App für einen Branch: ihr eigenes Objekt, ihre eigene URL, und ihre eigene Kopie jeder Datenbank und jedes Caches, die sie nutzt, sodass ein Pull Request gegen echte Datenflüsse geprüft werden kann, ohne die Produktion anzufassen.

pb preview up shop --ref feat-login --wait
# App shop-feat-login created (preview of shop, image registry.example.com/acme/shop:feat-login, ttl 168h0m0s)
# ManagedPostgres shop-feat-login-db created (empty xs)
# Ready: https://shop-feat-login.shop.apps.acme.paasbox.app

pb preview down shop --ref feat-login
# App shop/shop-feat-login deleted; its databases follow (backups stay in the store)

Was eine Preview bekommt

• Ihre eigene App, benannt <app>-<ref> (der Branch-Name, klein geschrieben und zu einem gültigen DNS-Label gemacht), standardmäßig auf null skaliert, unter https://<app>-<ref>.<namespace>.<domain>.
• Ein Image, abgeleitet vom Image der Quell-App, mit dem Tag durch den Branch ersetzt — shop:1.4.2 wird zu shop:feat-login — oder gib --image explizit an, was die meisten CI-Pipelines tun.
• Ihre eigene Kopie jeder Abhängigkeit. Jede ManagedPostgres oder ManagedValkey, die die Quell-App über uses nutzt, bekommt eine gleich geformte Kopie, benannt <preview>-<dep>, die der Preview-App gehört — die Preview löschen löscht auch sie. Eine Datenbank-Kopie ist standardmäßig eine leere xs-Instanz; --from-prod stellt sie stattdessen aus den eigenen Backups der Quell-Datenbank wieder her, in diese neue Instanz, ohne die Quelle je anzufassen. Eine Cache-Kopie ist immer eine leere xs-Instanz — in einem Cache gibt es nichts, das sich zu kopieren lohnt.
• Eine TTL, standardmäßig sieben Tage (--ttl), nach der eine vergessene Preview automatisch gelöscht wird.

In der CI

Eine Pull-Request-Pipeline, die pb aufruft, braucht nichts Plattformspezifisches — dieselben Befehle funktionieren aus einem Forgejo-Actions- oder GitHub-Actions-Job mit einer Kubeconfig für den Cluster:

# .github/workflows/preview.yml (veranschaulichend — schreib es gegen deine eigene Pipeline)
on:
  pull_request:
    types: [opened, synchronize, closed]
jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: build and push
        if: github.event.action != 'closed'
        run: docker build -t registry.example.com/acme/shop:pr-${{ github.event.number }} . && docker push registry.example.com/acme/shop:pr-${{ github.event.number }}
      - name: preview up
        if: github.event.action != 'closed'
        run: pb preview up shop --ref pr-${{ github.event.number }} --image registry.example.com/acme/shop:pr-${{ github.event.number }} --wait
      - name: preview down
        if: github.event.action == 'closed'
        run: pb preview down shop --ref pr-${{ github.event.number }}

Blue/Green

Jede Image-Änderung an einer App erstellt eine neue Knative-Revision; ohne gesetztes spec.traffic bekommt sie sofort 100 % des Traffics. spec.traffic zu setzen, teilt ihn explizit auf:

spec:
  traffic:
    - { revision: latest, percent: 0, tag: green }
    - { revision: shop-00042, percent: 100 }

latest löst sich immer zur neuesten Revision auf, die tatsächlich bereit ist, sodass ein kaputtes Image nie versehentlich Traffic bekommt. spec.traffic per kubectl zu ändern, funktioniert heute; eine Abkürzung pb app promote, die den Prozentsatz für dich verschiebt, ist geplant.