Regression aus dem vorigen Commit - /api/license/v1/validate lieferte die Antwort im neuen status/error-Umschlag. Der Vertrag dieses Endpunkts ist aber bereits ausgerollt: das Feld "status" auf oberster Ebene trägt den Lizenzzustand (valid, revoked, expired ...). LicenseClient las dadurch "success" statt "valid" — jeder ausgelieferte Client hätte seine Lizenz für ungültig gehalten. Die Lizenz-Endpunkte antworten jetzt wieder ohne Umschlag (Http::raw). Gefunden durch Ausführen der projekteigenen Test-Suite gegen den Server. Packager - FTP-Zugangsdaten standen als Standardwerte im Quelltext und zusätzlich in packager.config.json und in der Integrationsanleitung. Alle drei Fundstellen bereinigt; die Konfigurationsdatei ist nicht mehr versioniert. Zugangsdaten kommen aus Datei, Umgebungsvariablen oder CLI-Argument, sonst bricht das Programm mit einer klaren Meldung ab. - Das Veröffentlichen sendet jetzt ein Token (updateservice:publish) und nutzt den Endpunkt /api/updateservice/v1/publish. - Fehler wurden von einem leeren catch verschluckt, und ohne Erfolgsfall wurde gar nichts ausgegeben. Das Werkzeug meldete am Ende immer Erfolg und lieferte Rückgabewert 0, selbst wenn FTP-Upload und API-Aufruf fehlgeschlagen waren. Jetzt ehrliche Meldungen und Rückgabewerte 0/1/2. - packager.config.json wurde vom csproj nie ins Ausgabeverzeichnis kopiert, weshalb sie dort nie gefunden wurde und stets die hartkodierten Werte griffen. UpdateClient - IsVersionNewer entfernte die Vorabkennung, aber kein führendes "v". Damit scheiterte Version.TryParse bei "v1.4.2" und es wurde auf einen alphabetischen Vergleich zurückgefallen, in dem "v1.9.0" als neuer gilt als "v1.10.0" — derselbe Fehler wie zuvor serverseitig im SQL. Ersetzt durch einen vollständigen semantischen Vergleich, verifiziert mit 16 Testfällen. - Der Rückfall auf die API lag in einem catch-Block, aber GetAsync wirft bei einem 404 keine Exception. Fehlte die statische latest.json, brach die Prüfung ab, statt die API zu befragen. Dokumentation - BUGTRACKER_INTEGRATION_GUIDE.md beschrieb denselben Workflow ein zweites Mal und war bereits auseinandergelaufen: Aufrufe ohne Token, alte Pfade, weder Claim/Lease noch Idempotenz. Ersetzt durch einen Verweis auf das gepflegte Agenten-Handbuch samt Übersicht der Änderungen. - UPDATESERVICE_INTEGRATION_GUIDE.md um Token, Umgebungsvariablen und Rückgabewerte ergänzt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6.0 KiB
Deploymentcenter — UpdateService Integration & Deployment Guide
⚠️ Geändert in Version 2.0 — Das Veröffentlichen eines Releases läuft jetzt über
POST /api/updateservice/v1/publishund verlangt ein Token mit dem Scopeupdateservice:publish(zuvor völlig ungeschützt). Der Versionsvergleich folgt jetzt der semantischen Versionsordnung,1.10.0gilt also korrekt als neuer als1.9.0. Umstellungsschritte: UPGRADE.md.
Das UpdateService-Modul des Deploymentcenters bietet ein unternehmensweites, leichtgewichtiges Update-, Rollback- und Reparatur-Schema auf Basis eines LEMP-Stacks (Nginx Static Files + PHP API).
1. Übersicht & Architektur
- Kein dauerhafter Background-Dienst: Hauptanwendungen prüfen beim Start einmalig schnell und netzwerktolerant auf verfügbare Updates und Dateiintegrität.
- Entkoppelte Ausführung: Bei Handlungsbedarf beendet sich die Hauptanwendung sauber und übergibt die Kontrolle an den eigenständigen Console Agent (
update-agent.exe/update-agent). - 3-Kanal-System: Kanäle
prod(Produktiv),beta(Vorab-Test),dev(Entwicklung). - Statische LEMP-Verteilung: Downloads und Versionen-Manifeste (
latest.json,manifest.json,package.tar.gz) werden über Nginx extrem performant bereitgestellt.
2. Integration in .NET Client-Anwendungen
A. Referenz auf Deploymentcenter.Client
Binde das Projekt oder Paket Deploymentcenter.Client in deine Anwendung ein.
using Deploymentcenter.Client;
using Deploymentcenter.Client.Models;
// Early Start Hook in Program.cs (oder App.xaml.cs)
var updateClient = new UpdateClient();
var checkResult = await updateClient.CheckForUpdateAsync(
baseUrl: "https://dc.mhdf.de",
projectId: "myapp",
currentVersion: BuildInfo.Version,
channel: "prod"
);
if (checkResult.UpdateAvailable)
{
Console.WriteLine($"[UPDATE] Neues Release v{checkResult.LatestRelease.Version} verfügbar!");
// UpdateAgent starten und Hauptanwendung beenden
UpdateClient.LaunchUpdateAgent(
agentPath: "update-agent.exe",
projectId: "myapp",
channel: "prod",
action: "update",
version: "latest",
exitCurrentApp: true
);
}
B. MSBuild BuildInfo Generierung
Binde das Deploymentcenter.BuildInfo.targets Script in deine .csproj ein, damit Version, UTC-Build-Datum und Git Commit-Hash automatisch zur Übersetzungszeit generiert werden:
<Import Project="..\Deploymentcenter.Client\Deploymentcenter.BuildInfo.targets" />
3. Packaging & Deployment CLI (pack-and-deploy)
Das Packaging-Tool verpackt den dotnet publish-Output, berechnet Hashes, erzeugt das manifest.json und lädt alles per FTP auf den LEMP-Server.
Aufruf-Beispiel:
# Automatisierter Release-Publish via CLI
pack-and-deploy --project myapp --version 1.4.0 --channel prod --publish-dir ./bin/Release/net8.0/publish --changelog "Fehlerbehebungen und Performance-Optimierung"
Konfiguration (packager.config.json)
Diese Datei enthält Zugangsdaten und ist per
.gitignorevon der Versionskontrolle ausgeschlossen. Vorlage:packager.config.example.json. In der vorherigen Fassung standen die echten FTP-Zugangsdaten sowohl hier in der Anleitung als auch als Standardwerte im Quelltext vonProgram.cs.
{
"ftpHost": "ftp.example.com",
"ftpPort": 21,
"ftpUser": "ftp-user",
"ftpPass": "ftp-password",
"ftpRemoteBaseDir": "/public_html/releases",
"apiBaseUrl": "https://dc.mhdf.de",
"apiToken": "dc_sub_...",
"excludePatterns": [
"*.pdb",
"*.xml",
"appsettings.Development.json",
"*.log",
"logs/**"
]
}
apiToken braucht das Recht updateservice:publish. Ohne Token baut und lädt
der Packager das Paket zwar hoch, meldet es aber nicht beim Deploymentcenter an
und beendet sich mit Rückgabewert 2.
Alternative: Umgebungsvariablen
Für CI-Läufe, in denen keine Datei abgelegt werden soll — sie haben Vorrang vor der Konfigurationsdatei:
export DC_FTP_HOST=ftp.example.com
export DC_FTP_USER=ftp-user
export DC_FTP_PASS='...'
export DC_TOKEN='dc_sub_...'
pack-and-deploy --project myapp --version 1.4.0 --channel prod \
--publish-dir ./bin/Release/net8.0/publish
Rückgabewerte
| Wert | Bedeutung |
|---|---|
0 |
Paket gebaut, hochgeladen und im Deploymentcenter registriert |
1 |
Konfiguration unvollständig oder Publish-Verzeichnis fehlt — nichts wurde ausgeführt |
2 |
Teilweise fehlgeschlagen: FTP-Upload oder Registrierung ging schief |
Zuvor lieferte das Werkzeug in allen Fällen 0 und meldete „successfully
published", selbst wenn FTP-Upload und API-Aufruf beide fehlgeschlagen waren.
4. Standalone UpdateAgent (update-agent)
Der update-agent kann sowohl interaktiv (Spectre.Console Terminal UI) als auch im Headless CLI-Modus betrieben werden.
CLI Modus Befehle:
# Nach Updates suchen
update-agent --project myapp --channel prod --action check
# Auf neueste Version aktualisieren
update-agent --project myapp --channel prod --action update --version latest --target-dir /opt/myapp
# Rollback auf ältere Version
update-agent --project myapp --channel prod --action update --version 1.3.2
# Integritäts-Reparatur der aktuellen Installation
update-agent --project myapp --channel prod --action repair
# Alle verfügbaren Versionen auflisten
update-agent --project myapp --channel prod --action list
5. LEMP Verzeichnisstruktur auf dem Server
/var/www/releases/ (oder /public_html/releases/)
└── {ProjectId}/ # z.B. myapp, polytrader
├── prod/
│ ├── latest.json # Kanal-Übersicht & neueste Version
│ ├── 1.4.0/
│ │ ├── package.tar.gz # Das gezippte Release
│ │ ├── package.tar.gz.sha256
│ │ └── manifest.json # Einzeldateien + Hashes
│ └── 1.3.9/
├── beta/
└── dev/