Installation und Konfiguration von Zeta Test Management Web

Zeta Test Management Web stellt zentrale Testprojekte im Browser bereit. Die Anwendung basiert auf ASP.NET Core und .NET 10. Windows-Client und Weboberfläche greifen auf dieselben Projekte zu, haben jedoch keinen identischen Funktionsumfang.

Für einen produktiven zentralen Betrieb verwenden Sie das IIS-Paket zetatest-web.zip. Das separate Web-EXE-Setup richtet eine lokale Demo-/Einzelplatzvariante mit Kestrel ein; es ersetzt keine abgesicherte IIS-Installation.

Diese Anleitung beschreibt die produktive Bereitstellung, HTTPS, Berechtigungen, Konfigurationsdateien, Updates und optionale Client-/Server-Pfadzuordnungen.

Bereitstellungsvarianten

Wählen Sie die Bereitstellungsform vor der Installation bewusst aus:

Lokale Demo-/Einzelplatzvariante: Das Web-EXE-Setup startet die mitgelieferte Webanwendung lokal über Kestrel. Diese Variante eignet sich für Evaluierung und einen einzelnen Windows-Benutzer, nicht als zentraler Produktionsserver.
Zentrale IIS-Variante: Entpacken Sie zetatest-web.zip auf einem Windows Server und betreiben Sie den enthaltenen Ordner Website als IIS-Anwendung. Dies ist der empfohlene Produktionsweg.
Reverse Proxy: Ein vorgeschalteter Proxy kann TLS terminieren und die Anwendung veröffentlichen. Proxy, Weiterleitungen und vertrauenswürdige Header müssen dabei bewusst administriert und getestet werden.

Halten Sie Programmdateien, Konfiguration, Protokolle und Projektdaten in klar getrennten, gesicherten Pfaden. Das erleichtert Updates und Rollbacks.

Funktionsumfang und Vorabbereiche

Der Windows-Client bleibt die vollständige Oberfläche für Projektadministration und alle Desktop-Funktionen. Die Weboberfläche unterstützt browserbasierte Arbeitsabläufe, ist aber keine funktionsgleiche Kopie des Windows-Clients.

Zusätzliche Webbereiche können als Vorschau ausgeliefert werden. In der Produktionsauslieferung ist AppSettings.ExperimentalWebAreas.Enabled standardmäßig false. Aktivieren Sie Vorschaufunktionen nur gezielt, dokumentieren Sie die freigegebenen Bereiche und testen Sie Rechte, Daten und Rollback vor dem Einsatz.

Planen Sie deshalb vor dem Rollout, welche Aufgaben im Web und welche weiterhin im Windows-Client durchgeführt werden.

Voraussetzungen und Vorbereitungen

Prüfen Sie vor der Installation die jeweils aktuellen Systemvoraussetzungen. Für die aktuelle Auslieferung benötigen Sie insbesondere:

einen unterstützten Windows Server, derzeit Windows Server 2019 oder 2022, mit aktuellen Sicherheitsupdates;
Microsoft IIS und administrative Rechte für die Einrichtung von Site, Anwendungspool, Bindings und Zertifikat;
das zum Zeta-Test-Management-Release passende Microsoft-.NET-10-Hosting-Bundle; es installiert auch das ASP.NET Core Module V2 für IIS;
einen stabilen DNS-Namen und ein vertrauenswürdiges TLS-Zertifikat für HTTPS;
eine gesicherte Projekt- und Datenbankbasis; für den Webbetrieb wird Microsoft SQL Server 2017 oder neuer empfohlen;
eine eigene technische Identität mit nur den erforderlichen Datei- und Datenbankrechten.

Legen Sie vor der ersten Bereitstellung Backup, Wiederherstellung, Updatefenster und einen technischen Verantwortlichen fest.

Erstinstallation mit dem IIS-Paket

Installieren Sie IIS und anschließend das zum Release passende .NET-10-Hosting-Bundle. Starten Sie den Server neu, wenn das Hosting-Bundle dies verlangt.
Entpacken Sie zetatest-web.zip zunächst in einen Staging-Ordner. Der IIS-Pfad zeigt später auf den enthaltenen Ordner Website.
Konfigurieren Sie Config.json, appsettings.json und bei Bedarf foldermappings.json. Verwenden Sie für produktive Projekte einen stabilen Datenpfad außerhalb des austauschbaren Release-Ordners.
Erstellen Sie einen eigenen IIS-Anwendungspool mit „Kein verwalteter Code“. Setzen Sie „32-Bit-Anwendungen aktivieren“ auf False und weisen Sie eine dedizierte Identität zu.
Erstellen Sie die IIS-Site beziehungsweise -Anwendung mit dem physischen Pfad zum Ordner Website. Die ausgelieferte web.config mit AspNetCoreModuleV2 bleibt maßgeblich.
Vergeben Sie die benötigten Datei- und Datenbankrechte und richten Sie das HTTPS-Binding mit dem vorgesehenen Zertifikat ein.
Starten Sie Anwendungspool und Site. Öffnen Sie die HTTPS-Adresse zuerst als Administrator und prüfen Sie Startseite, Anmeldung, Projektliste und ein freigegebenes Testprojekt.

Gehen Sie erst nach erfolgreichem Pilotbetrieb in den breiten Rollout.

Update und Rollback

Behandeln Sie ein Webupdate wie eine kontrollierte Serveränderung:

Sichern Sie Projekte, Datenbank, Websitekonfiguration und gegebenenfalls Protokolle. Notieren Sie die bisherige Produktversion und den aktiven Websitepfad.
Entpacken Sie das neue zetatest-web.zip in einen parallelen Release-Ordner.
Übernehmen Sie Config.json, appsettings.json und foldermappings*.json nicht blind. Vergleichen Sie die neuen Standarddateien und führen Sie Ihre umgebungsspezifischen Werte kontrolliert zusammen. Verwenden Sie die neue ausgelieferte web.config.
Stoppen Sie den Anwendungspool, schalten Sie den IIS-Pfad auf den neuen Ordner Website um und starten Sie den Pool wieder.
Prüfen Sie HTTPS, Anmeldung, Projektliste, Rechte und einen typischen Testablauf. Beobachten Sie Ereignisanzeige und aktivierte Anwendungsprotokolle.

Für den Rollback stoppen Sie den Pool, stellen den vorherigen Websitepfad und bei notwendigen Datenmigrationen auch die dazugehörige Datensicherung wieder her. Löschen Sie den vorherigen Release-Ordner erst nach dem vereinbarten Rückfallzeitraum.

IIS und HTTPS konfigurieren

Anwendungspool: „Kein verwalteter Code“, 32-Bit-Anwendungen deaktiviert, eigene Identität und ein zur Betriebsplanung passender Startmodus.
ASP.NET Core: Das .NET-Hosting-Bundle stellt AspNetCoreModuleV2 bereit. Wenn das Modul fehlt, reparieren oder installieren Sie das Hosting-Bundle und starten IIS beziehungsweise den Server neu.
Physischer Pfad: Verweisen Sie auf den Ordner Website des aktiven Releases. Die Projekte selbst liegen nicht im öffentlich auslieferbaren Websitepfad.
HTTPS: Binden Sie den produktiven DNS-Namen an Port 443 und ein vertrauenswürdiges Zertifikat. HTTP bleibt höchstens als ausdrücklich konfigurierter Redirect-Endpunkt bestehen.
Anwendungseinstellungen: Bei direkter HTTPS-Terminierung in IIS können Sie UseHttpsRedirection aktivieren und AllowInsecureCookies deaktivieren. Bei einem Reverse Proxy muss die Weiterleitung am Proxy und in der gesamten Kette getestet werden.

Das IIS-Modul „URL Rewrite“ ist keine Voraussetzung von Zeta Test Management Web. Setzen Sie es nur ein, wenn Ihre eigene Redirect- oder Proxykonfiguration es benötigt.

Berechtigungen nach dem Least-Privilege-Prinzip

Vergeben Sie der Anwendungspool-Identität nur die tatsächlich benötigten Rechte:

Programmordner: Lesen und Ausführen auf dem aktiven Ordner Website.
Projektwurzeln: Ändern auf den in projectSearchFolderPaths freigegebenen Projekten, soweit die vorgesehenen Webfunktionen schreiben müssen.
Benutzerablagen, Anhänge und Protokolle: Ändern nur auf den hierfür konfigurierten Ordnern.
SQL Server: Ein eigenes Login beziehungsweise Dienstkonto mit den für die verwendeten Datenbanken erforderlichen, minimalen Rechten.

Für UNC-Pfade verwenden Sie eine Domänen- oder Dienstidentität, die den Share und die NTFS-Rechte tatsächlich besitzt. Vermeiden Sie persönliche Administratorenkonten und globale Vollzugriffe.

Sicherheitsgrenze: Projektdateien, Konfigurationsdateien, Backups und Protokolle dürfen nicht als statische Dateien über die Website erreichbar sein.

Config.json und appsettings.json konfigurieren

Config.json enthält die klassischen Zeta-Test-Management-Anwendungseinstellungen. Mehrere Projektwurzeln in projectSearchFolderPaths werden durch Semikolon getrennt:

{
  "settings": [
    {
      "name": "projectSearchFolderPaths",
      "value": "D:\\ZetaTest\\Projects;\\\\fileserver\\ZetaTest\\Projects"
    },
    {
      "name": "alternativeCurrentUserStorageBaseFolderPath",
      "value": "D:\\ZetaTest\\UserStorage"
    },
    {
      "name": "forbiddenProjectNames",
      "value": "Archive;Templates"
    }
  ]
}

appsettings.json steuert ASP.NET-Core-Funktionen, unter anderem HTTPS, Cookies, Logging, Sprache und optionale Vorabbereiche:

{
  "AppSettings": {
    "UseHttpsRedirection": true,
    "AllowInsecureCookies": false,
    "ExperimentalWebAreas": {
      "Enabled": false,
      "ShowLabels": true
    }
  }
}

Die Werte sind Beispiele und müssen zu Ihrer Topologie passen. Lassen Sie nicht benötigte Auto-Login-Optionen deaktiviert. Behandeln Sie serviceApiKey und andere Schlüssel als Geheimnisse; legen Sie sie weder in öffentlich erreichbaren Ordnern noch in einer ungeschützten Versionsverwaltung ab.

Nach Änderungen recyceln Sie gezielt den Anwendungspool und prüfen die Startseite sowie die betroffenen Funktionen.

Client-/Server-Pfade mit foldermappings.json zuordnen

foldermappings.json ist nur erforderlich, wenn ein vom Windows-Client übertragener Projektpfad auf dem Webserver anders lautet. Die Anwendung ersetzt den passenden Anfang des Clientpfads durch den Serverpfad:

{
  "startsWithMappings": [
    {
      "client": "\\\\fileserver\\ZetaTest",
      "server": "D:\\ZetaTest"
    }
  ]
}

Im Beispiel wird \\fileserver\ZetaTest\ProjektA auf D:\ZetaTest\ProjektA abgebildet. Beide Pfade müssen dasselbe Projekt bezeichnen; Groß-/Kleinschreibung ist unter Windows nicht ausschlaggebend.

Legen Sie die Datei im Ordner Website ab.
Verwenden Sie möglichst wenige, eindeutige Präfixe und vermeiden Sie überlappende Zuordnungen.
Prüfen Sie die Zielpfade aus Sicht der Anwendungspool-Identität.
Recyceln Sie nach einer Änderung den Anwendungspool; ein pauschales IISRESET ist nicht erforderlich.