Masterluke77andGitHub
6f48827f4d
* docs: prepare Vendoo 1.41.2 git-ignore boundary hotfix * fix: track native source modules with root-anchored runtime ignores
77 lines
2.9 KiB
Markdown
77 lines
2.9 KiB
Markdown
# Vendoo 1.34.0 – GitHub Deployment
|
||
|
||
## Repository
|
||
|
||
- Repository: `Masterluke77/vendoo`
|
||
- Sichtbarkeit: privat
|
||
- Stabiler Branch: `main`
|
||
- Entwicklungsbranch: `develop`
|
||
- Erstimport-Branch: `release/1.34.0-initial-import`
|
||
|
||
## Kontrollierter Erstimport
|
||
|
||
Unter Windows wird `GitHub-Deploy-Assistent.bat` gestartet. Der Assistent:
|
||
|
||
1. prüft beziehungsweise installiert Git für Windows über `winget`,
|
||
2. klont die vorhandene GitHub-Baseline in einen temporären Arbeitsordner,
|
||
3. verwendet oder erstellt `release/1.34.0-initial-import`,
|
||
4. kopiert nur den bereinigten Vendoo-Quellstand,
|
||
5. blockiert `.env`, Datenbanken, Uploads, Backups, Logs, Laufzeitdaten und Modelle,
|
||
6. führt nach Möglichkeit `tools/verify-git-safety.mjs` aus,
|
||
7. zeigt alle Änderungen vor dem Commit,
|
||
8. verlangt zur Freigabe die exakte Eingabe `PUSH`,
|
||
9. pusht ausschließlich den Release-Branch,
|
||
10. öffnet den vorbereiteten Pull-Request-Vergleich im Browser.
|
||
|
||
Der Assistent löscht oder verändert keine produktiven Vendoo-Daten. Der temporäre Git-Arbeitsordner wird nach Abschluss entfernt.
|
||
|
||
## Pull Request und Merge
|
||
|
||
Der Pull Request wird gegen `main` erstellt. Vor dem Merge müssen die GitHub-Actions-Prüfungen erfolgreich sein:
|
||
|
||
- reproduzierbare Installation über `npm ci`,
|
||
- Git-Sicherheitsgate,
|
||
- JavaScript-/MJS-Syntax,
|
||
- Deployment-Gate 1.34.0,
|
||
- Datenbankmigrationstest,
|
||
- Compose-Prüfung für lokal, NAS und VPS,
|
||
- Docker-Testbuild.
|
||
|
||
Empfohlen ist ein Squash-Merge. Erst danach wird ein GitHub Release `v1.34.0` veröffentlicht.
|
||
|
||
## Release-Automation
|
||
|
||
Beim Veröffentlichen eines GitHub Releases:
|
||
|
||
- wird ein bereinigtes Release-Staging erzeugt,
|
||
- werden Einzeldatei-SHA-256-Prüfsummen erzeugt,
|
||
- wird `Vendoo_1.34.0.zip` gebaut,
|
||
- wird eine SHA-256-Datei für das ZIP erzeugt,
|
||
- werden beide Dateien an das GitHub Release angehängt,
|
||
- wird ein Multi-Arch-Container für `linux/amd64` und `linux/arm64` gebaut,
|
||
- wird das Image als `ghcr.io/masterluke77/vendoo` in die GitHub Container Registry veröffentlicht,
|
||
- wird der veröffentlichte Image-Digest mit einer GitHub-Provenienz-Attestierung versehen.
|
||
|
||
Das Release-ZIP wird nicht dauerhaft in die Git-Historie committed.
|
||
|
||
## Secrets
|
||
|
||
Produktive Secrets gehören ausschließlich in:
|
||
|
||
- die lokale `.env`, die der Installer automatisch erzeugt,
|
||
- den persistenten Runtime-Konfigurationsspeicher von Vendoo,
|
||
- gegebenenfalls geschützte GitHub Environments für spätere Deployments.
|
||
|
||
Nicht zulässig sind Secrets in Quellcode, Issues, Pull Requests, Workflow-Ausgaben oder Release-Paketen.
|
||
|
||
## Späteres Produktionsdeployment
|
||
|
||
Ein automatisches Deployment auf NAS oder VPS wird erst freigeschaltet, wenn diese Gates praktisch bestätigt sind:
|
||
|
||
- Backup und Restore auf dem Zielsystem,
|
||
- Readiness nach Update,
|
||
- Rollback auf die vorherige Container-Version,
|
||
- TLS und Domainprüfung,
|
||
- getrennte Staging- und Produktionsumgebung,
|
||
- manuelle Freigabe des GitHub Environments `production`.
|