77 lines
3.6 KiB
Markdown
77 lines
3.6 KiB
Markdown
# 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
|
|
|
|
1. Aktuellen TFS-Stand in ein separates Verzeichnis holen.
|
|
2. In Git den Branch `sync/tfs-legacy` vom zuletzt integrierten Stand erstellen.
|
|
3. Nur die verwalteten Legacy-Quellen importieren:
|
|
|
|
```powershell
|
|
.\tools\Sync-TfsLegacy.ps1 `
|
|
-TfsExportRoot 'C:\Workspace\C4IT FASD\F4SD_M42WebApi\sonstiges\F4SD_M42WebApi_TFS' `
|
|
-Changeset '<TFS-Changeset>'
|
|
```
|
|
|
|
4. Diff pruefen und den Snapshot als eigenen Commit einchecken.
|
|
5. Den Sync-Branch per normalem Drei-Wege-Merge in den Entwicklungsbranch integrieren.
|
|
6. 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:
|
|
|
|
1. Finalen Git-Diff der Legacy-Dateien pruefen.
|
|
2. Die betroffenen Legacy- und gemeinsamen Dateien in den lokalen TFS-Workspace uebernehmen.
|
|
3. In Visual Studio unter Pending Changes kontrollieren, welche Dateien geaendert werden.
|
|
4. Legacy-Solution aus dem TFS-Workspace bauen und testen.
|
|
5. Check-in-Kommentar mit Git-Commit und Paketversion versehen.
|
|
6. Den TFS-Check-in manuell in Visual Studio ausfuehren.
|
|
|
|
Automatische `tf checkin`-, Reconcile- oder Upload-Skripte sind fuer dieses Repository nicht zulaessig.
|
|
|
|
## Builds
|
|
|
|
```powershell
|
|
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.
|