Legacy- und Sandbox-Entwicklung

Unterstuetzte Varianten

Variante	Matrix42 ESM	Runtime	Solution	Paket
Legacy	12.1.3 bis 25.x	.NET Framework 4.7.2	`C4IT - F4SD - M42WebApi.Legacy.sln`	`artifacts/Legacy/<Configuration>/`
Sandbox	26.1 und neuer	.NET 8	`C4IT - F4SD - M42WebApi.sln`	`artifacts/<Configuration>/`

Beide Varianten verwenden dieselbe Version aus SharedAssemblyInfo.cs. Die Webservice-spezifischen Ticketvertraege liegen in F4SDHelper/Common/C4IT.F4SD.WebApi.Contracts.cs. Die externe _Common/C4IT.F4SD.Base.Ticket.cs bleibt unveraendert, da sie auch F4SD Client und Server verwenden.

Entwicklungsregeln

Fachliche Aenderungen werden in beiden Hosts umgesetzt und mit derselben Postman-Collection getestet.
Matrix42-Abhaengigkeiten, Controller-Rueckgaben, Journalzugriff und Paketformat bleiben host-spezifisch.
Bestehende SID-Routen bleiben kompatibel; neue Funktionen sollen bevorzugt die userId-Routen verwenden.
Matrix42-Operation-IDs bestehender Routen duerfen nicht geaendert werden.
Eine neue Operation erhaelt einmalig eine feste ID, die in Legacy- und Sandbox-Paket identisch ist.
Legacy wird gegen die Bibliotheken der 12.1.3-Umgebung gebaut. Die Laufzeitkompatibilitaet muss zusaetzlich auf einer aktuellen 25.x-Installation geprueft werden.

TFS nach Git

Aktuellen TFS-Stand in ein separates Verzeichnis holen.
In Git den Branch sync/tfs-legacy vom zuletzt integrierten Stand erstellen.
Nur die verwalteten Legacy-Quellen importieren:

.\tools\Sync-TfsLegacy.ps1 `
  -TfsExportRoot 'C:\Workspace\C4IT FASD\F4SD_M42WebApi\sonstiges\F4SD_M42WebApi_TFS' `
  -Changeset '<TFS-Changeset>'

Diff pruefen und den Snapshot als eigenen Commit einchecken.
Den Sync-Branch per normalem Drei-Wege-Merge in den Entwicklungsbranch integrieren.
Fachliche Konflikte im gemeinsamen Verhalten aufloesen; Legacy-Projektdateien niemals ueber Sandbox-Projektdateien kopieren.

Das Skript importiert ausschliesslich vom TFS nach Git. Es fuehrt keinen TFS-Check-in aus.

Git nach TFS

Der Rueckweg ist absichtlich manuell:

Finalen Git-Diff der Legacy-Dateien pruefen.
Die betroffenen Legacy- und gemeinsamen Dateien in den lokalen TFS-Workspace uebernehmen.
In Visual Studio unter Pending Changes kontrollieren, welche Dateien geaendert werden.
Legacy-Solution aus dem TFS-Workspace bauen und testen.
Check-in-Kommentar mit Git-Commit und Paketversion versehen.
Den TFS-Check-in manuell in Visual Studio ausfuehren.

Automatische tf checkin-, Reconcile- oder Upload-Skripte sind fuer dieses Repository nicht zulaessig.

Builds

msbuild '.\C4IT - F4SD - M42WebApi.Legacy.sln' /restore /p:Configuration=Debug
msbuild '.\C4IT - F4SD - M42WebApi.sln' /restore /p:Configuration=Debug

Verfuegbare Konfigurationen fuer beide Varianten:

Debug: Debug-DLLs und Debug-Paket
Release: optimiertes, unsigniertes Paket
Release_signed: optimiertes und signiertes Paket

Das Signing ist nur in Release_signed automatisch aktiv und signiert alle Paket-DLLs in einem Aufruf.

Abnahmetests

Beide Solutions bauen.
Paket- und Assembly-Version stimmen ueberein.
Bestehende SID-Routen funktionieren weiterhin.
userId-Routen liefern fuer denselben Benutzer fachlich dieselben Ergebnisse.
Leere Ticketlisten liefern [].
Alle Query-Parameter werden gebunden.
Ticketdetails, Journal, Pickup, Rollen, Direct Links und isAlive werden getestet.
Operationsdateien sind in install.xml registriert und erzeugen nach Service-Synchronisierung keine Duplikate.

3.6 KiB Raw Blame History