vendoo/docs/GITHUB_DEPLOYMENT_1_34_0.md

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.