Konzepte¶
Vier zentrale Objekte: Tenants, Projekte, Environments, Deployments.
Tenant¶
Top-Level-Container. Ein Tenant entspricht einer Organisation oder einem Workspace. Alles haengt am Tenant: Members, Billing, Audit-Logs, API-Keys.
- Tenant-Slug ist global eindeutig
- Sub-Tenants (z.B. fuer grosse Organisationen mit mehreren Teams) sind moeglich
- Cross-Tenant-Sharing ist explizit, nichts ist per Default sichtbar
Projekt¶
Ein Projekt ist eine deploybare Einheit innerhalb eines Tenants. Beispiele: eine Website, eine API, ein Worker.
- Projekt haengt an einem Repository (Git) oder ist Empty (manueller Push via CLI)
- Projekte haben mindestens eine Stack-Konfiguration (Build, Runtime, Env-Vars)
- Projekte koennen mehrere Environments haben
Environment¶
Eine Variante eines Projekts. Standard-Environments:
- production - immutable, an
main-Branch gekoppelt, hat Custom-Domain - preview - flexibel, an Feature-Branches/PRs gekoppelt, eigene
*.preview.kombify.io-URL pro PR
Custom-Environments lassen sich anlegen fuer Staging, QA, Demo, etc. Promotions zwischen Environments laufen ueber explizite Promote-Aktionen.
Deployment¶
Ein einzelner Build-+-Release-Lauf. Jedes Deployment hat:
- Eindeutige Deployment-ID
- Source-Commit-SHA
- Build-Logs
- Runtime-Logs
- Status (
pending,building,live,failed,superseded,rolled_back)
Rollbacks: ein altes Deployment per Klick wieder live setzen, ohne Rebuild.
Hierarchie¶
Tenant
├── Project A
│ ├── Environment: production
│ │ ├── Deployment #142 (live)
│ │ ├── Deployment #141 (superseded)
│ │ └── ...
│ └── Environment: preview
│ └── Deployment #99 (live, branch=feat/login)
└── Project B
└── ...
Members und Permissions¶
Permissions sitzen am Tenant, nicht am Projekt. Ausnahme: Project-Visibility kann eingeschraenkt werden ("nur diese Members sehen dieses Projekt").
Rollen: owner, admin, developer, viewer. Details: Account erstellen.
Billing¶
Billing ist tenant-weit. Ressourcenverbrauch wird pro Projekt aggregiert, abgerechnet auf Tenant-Ebene. Details: Pricing.