Skip to content

Entwicklerhinweise

Inhaltsverzeichnis

NuGet

Die NuGet Sources werden in der Pipeline dynamisch gesetzt. Für die Aktualisierung der lokalen Sources für die lokale Entwicklung muss metabeta ausgeführt werden. Alternativ kann die NuGet.Config manuell angelegt werden, siehe hier.

Git Branch Konzept

In diesem Repository wird nach dem Gitflow Workflow gearbeitet.

Build

Der CI-Build erfolgt per Github Actions als Docker build. Das Buildergebnis wird aus dem entstandenen Docker-Image herauskopiert und steht bei der Build-Pipeline zum Download bereit. Releases können als ZIP-File von Github heruntergeladen werden.

Es stehen die folgenden GitHub-Actions zur Verfügung:

  • CI Build
  • Release Build
  • Validate Codestyle
  • Validate Codestyle ClientApp
  • PR von Codeowner reviewed

EF Core

Das Projekt verwendet zwei verschiedene DbContext, einen für MSSQL und einen für PostgreSQL. MSSQL wird für On Premise Installationen angeboten, PostgreSQL ist primär für den Betrieb in unserer Cloud. Migrationen und zugehörige DB-Scripts können mit der .NET CLI generiert werden. Der Befehl ist je nach DbContext unterschiedlich und damit auch die DI-Registrierungen, daher muss vor Ausführung die Konfiguration für den entsprechenden Provider eingestellt werden. Im Anschluss werden einige Beispielbefehle gegeben.

dotnet ef migrations add 1 --context MssqlReportDbContext --project .\src\CMI.Reporting.Service\CMI.Reporting.Service.csproj --configuration DebugWithoutClientApp --output-dir Infrastructure\Data\MSSQL\Migrations
dotnet ef migrations add 1 --context PostgresqlReportDbContext --project .\src\CMI.Reporting.Service\CMI.Reporting.Service.csproj --configuration DebugWithoutClientApp --output-dir Infrastructure\Data\PostgreSQL\Migrations
dotnet ef migrations script --configuration DebugWithoutClientApp --context MssqlReportDbContext --project .\src\CMI.Reporting.Service\CMI.Reporting.Service.csproj --idempotent --output scripts\mssql\20231117063519_1.sql
dotnet ef migrations script --configuration DebugWithoutClientApp --context PostgresqlReportDbContext --project .\src\CMI.Reporting.Service\CMI.Reporting.Service.csproj --idempotent --output scripts\postgresql\20231117063459_1.sql

Entwickler Flow

Entwicklung am Backend

Bei einem Debug-Build wird vorgängig geprüft, ob Node.js installiert ist. Ist dies nicht der Fall, wird der Build nicht gestartet. War diese Prüfung erfolgreich, wird als erstes die ClientApp (Angular App) gebuildet, welche im Pfad ./src/CMI.Reporting.Service/ClientApp zu finden ist. Anschliessend wird der normale .NET Build durchgeführt. Dies führt dazu, dass der Reporting Service nach dem Build komplett funktionsfähig ist inkl. der ClientApp.

Wird die Solution Configuration DebugWithoutClientApp ausgewählt, wird immer nur der .NET Build durchgeführt. Das ist hilfreich, wenn primär am Backend gearbeitet wird und das ständige Erstellen des Frontends nicht notwendig ist.

Entwicklung am Frontend

Die ClientApp ist eine Angular App, welche nach den gleichen Coding Guidelines wie die aus CMI-Weblients entwickelt werden muss. Für die lokale Entwicklung startet man als Erstes den .NET Service CMI.Reporting.Service und anschliessend die Angular App mittels npm run watch. Die App ist dann unter der Url https://localhost:7000/{tenant}/ erreichbar und Änderungen am Frontend-Code werden ohne Neustart wirksam.

DevExpress Updates

Einige Dinge die wir verwenden sind nicht dokumentiert oder compile time safe und müssen manuell überprüft werden, wenn die DevExpress Komponenten aktualisiert werden. - Ausblenden aller Menü-Aktionen ausser Speichern: report-designer.component.ts -> onCustomizeMenuActions - Ausblenden aller Buttons in der Feld-Liste: report-designer.components.ts -> onCustomizeFieldListActions - Ausblenden von nicht funktionierenden Elementen: report-designer.component.ts -> onCustomizeElements - Ausblenden von unerwünschten Properties: report-designer.component.ts -> onCustomizeToolbox