CMI MigrationTool

Das CMI MigrationTool ist eine simple EVA Konsolenapplikation und wird für den Import von Daten aus einem anderen CMI-Mandant oder aus einem Drittsystem (z.B. Lehreroffice, iCampus, Scolaris) in ein spezifisches CMI-Zielsystem verwendet.

Allgemeines

• Status: Freigegeben
• Fachliche Ansprechperson: Vanja Decurtins
• Technische Ansprechperson: Andreas Zingg, Heinz Bigler
• Nur für speziellen Kunden: Nein

Strategische Einordnung

Durch das CMI MigrationTool soll eine standardisierte Migration von Daten aus Drittsystemen oder anderen CMI-Mandaten in ein CMI-System zur Verfügung stehen, welche das Kundenteam ohne zusätzlichen Programmieraufwand durchführen kann.

Technisches

Eigenschaften

Die Komponente erfüllt folgende Eigenschaften:

• Stateless: ja
• Skalierbar/Multiinstanzfähig: nein
• Mehrmandantenfähig: nein
• Proxyfähig: nein
• Laufzeitverhalten: Die Applikation ist eine simple EVA-Konsolenapplikation.

Abhängigkeiten

Das CMI MigrationTool ist ab Version 4.0 so konzipiert und benannt, dass alle möglichen Arten von Migrationen durchgeführt werden können. Frühere Versionen sind spezifisch im Schulbereich eingesetzt worden.

Deshalb werden hier nur MigrationTool-Versionen ab 4.0 dokumentiert. Frühere Versionen sollten nicht mehr verwendet werden.

Weil das CMI MigrationTool Datenprüfungen gegen das Zielsystem durchführt und DirectImport-Dateien erstellt, muss das CMI-Zielsystem das Ausführen von Datenprüfungen unterstützen und die Update-Funktionalität im DirectImport-Vorgang unterstützen. Deshalb ist das CMI MigrationTool ausschliesslich mit folgenden CMI-Serverversionen kompatibel:

Version MigrationTool	Version CMI Server
4.0	>= 24.0.3 (resp. ausnahmsweise 22.0.20)

Fehlertoleranz

Fehlerhafte Request oder fehlerhaftes Dateihandling werden ins Logfile geschrieben und die Applikation wird terminiert.

Technologiestack

Folgende Technologien werden eingesetzt: * .NET 8.0

Release erstellen

Benötigte Änderungen werden via PRs ganz normal via Squash Merge nach develop gemerged. Um ein neuen Release Build zu erstellen, soll wie folgt vorgeangen werden:

• Für den neuen Release/Build die Version erhöhen
  • Wie gewöhnlich einen Feature-Branch von develop erstellen
  • In Datei src\version.json die Version erhöhen
  • Änderungen committen, Pull Request für Branch erstellen und Änderungen nach develop mergen
• Via Github einen neuen Pull Request erstellen
  • Für Merge von Branch develop nach master
  • Titel: [Release] {Versionsnummer}
    • Beispiel: [Release] 4.2
  • Assignees setzen
• Prüfen ob Checks durchlaufen, sonst analysieren was das Problem ist
• Reviewers eintragen und warten bis Approval erfolgt
• Wenn approved den PR mittels einem Merge Commit nach master mergen (eine andere Art sollte durch die Policies in Github gar nicht mehr möglich sein)
• Eine Action sollte nun automatisch den neuen Release builden, welcher dann unter Releases verfügbar ist

Dokumentation

Die komplette Dokumentation ist im Ordner docs zu finden.

Troubleshooting

Mögliche Fehlerquellen sind im Wiki beschrieben.