Fortuna Entwickler Blog

Für die Master Solution braucht es einen anderen Ablauf. Damit es manuell funktioniert müssen folgende Schritte erfolgen.

Vorbereitung

Bevor die eigentliche Analyse gestartet werden kann, müssen verschiedene Schritte vollzogen werden.

1. Herunterladen des Sonarscanners. 

Damit die Zeilen von Code analysiert werden können, brauchen wir den Client von SonarCloud dazu.

Dort sollte die net4.6 Version genommen werden, aufgrund des Mixes von C++ und C# in der Solution. 

Die .zip Datei nach dem Entpacken an einen geeigneten Platz legen (z.B. unter C:\\SonarCloud). Im späteren Schritt, werden wir den Pfad noch brauchen.

2. Herunterladen des Buildwrappers

Damit die Logdateien während der Analyse gefüllt werden, wird der Buildwrapper von SonarCloud benötigt.

Die .zip Datei nach dem Entpacken an einen geeigneten Platz legen (z.B. unter C:\\SonarCloud). Im späteren Schritt, werden wir den Pfad noch brauchen.

3. Setzen der Umgebungsvariablen

Damit verschiedene Einstellungen direkt gefunden werden müssen folgende Befehle in einer Powershell Konsole ausgeführt werden:

[Environment]::SetEnvironmentVariable("SONAR_SCANNER_OPTS", "-Dhttps.proxyHost=10.98.98.222 -Dhttps.proxyPort=8080",[System.EnvironmentVariableTarget]::Machine)

[Environment]::GetEnvironmentVariable("SONAR_SCANNER_OPTS", [System.EnvironmentVariableTarget]::Machine)

3. Herunterladen des aktuellen Java JDKs

Für den Scanner wird Java mindestens in der Version 11 benötigt.

Analyse - Routine

Token können innerhalb der SonarCloud Oberfläche als Administrator erzeugt werden:

Zum Starten der Analyse muss zuerst auf der Kommandozeile in das Verzeichnis navigiert werden in der die Master Solution liegt. Folgend werden die Befehle ausgeführt:

SonarScanner.MSBuild.exe begin /k:"Master_MyLife" /o:"mylife-leben" /d:sonar.host.url="https://sonarcloud.io" /d:sonar.login="bfe291ef26f056234f4782e8660fbefe541fc12f" /d:sonar.cfamily.build-wrapper-output="build_wrapper_output_directory"

build-wrapper-win-x86-64.exe --out-dir build_wrapper_output_directory MSBuild.exe Master.sln /t:Rebuild /p:Configuration=Release /p:Platform=x64

SonarScanner.MSBuild.exe end /d:sonar.login="bfe291ef26f056234f4782e8660fbefe541fc12f" 

Um Änderungen, welche im Produktivstand durchgeführt werden (müssen), in die aktuelle Entwicklungsversion zu übernehmen, geht man wie folgt vor (am Beispiel einer web.config):

• Änderungen in der Release-Version durchführen
• Testen der Änderungen
• Eventuell publish in Testumgebung und erneutes Testen
• Publishen in Produktionsumgebung

Anschließend müssen die Änderungen auch in den aktuellen _dev-Zweig aufgenommen werden. Hierzu führt man die Änderungen nicht nochmals durch, sondern macht einen Merge:

nuGet packages

Es ist nicht sinnvoll, nuGet Packages in unsere Release-Zyklen einzubinden; dies widerspricht dem eigentlichen Sinn der nuGet Packages.

In einem Package sollen Funktionen umgesetzt werden, welche Produktunabhängig sind und allgemein Verwendet werden können, z.B. Mailversand, PDF Erstellung und Ähnliches

Empfehlung Herr Schmidt: 

• Rückführung Produktspezifischer Packages in die jeweiligen Solutions

• Neustrukturierung der Ordnerstruktur für Solutions

• Alle Solutions in einem Ordner

• Alle Webanwendungen in einem eigenen Ordner in einem Unterordner (‚web‘)

• Alle Bibliotheken in einem eigenen Ordner in einigen wenigen Unterordnern (‚logic‘, ‚data‘)

• Damit dann Kombination aus nuGet und Bibliotheken

• Builds für Projekte automatisieren

• Builds für nuGet Packages erstellen Symbole für Debugging, welche vorgehalten werden

Branches, Merges, etc.

Der aktuelle Stand kann so weiter geführt werden.

Das Verschieben von Branches kann möglicherweise in Zukunft wieder verfügbar sein. Derzeit gibt es keine andere Möglichkeit, als es so zu tun, wie wir es derzeit machen.

Herr Schmitt hat uns Alternativen zur derzeitigen Vorgehensweise aufgezeigt. Diese wären gggf. Zu diskutieren.

Event- und Fehlerlogging

Das Logging, so wie wir es derzeit betreiben ist weder performant noch sonst zu empfehlen.

Empfehlung Herr Schmidt: 

• Einsatz von NLog

• Umstellung aller Anwendungen auf einen Asynchronen Logger

• Logging gegen einen WebService (in Azure)

• Archivierung von Logs in Azure Storage

• Ggf. Automatisiertes Herunterladen aus Azure Storage

Benutzer, Security

Eine eigene Benutzerverwaltung ist aufwendig, fehleranfällig und nur schwer abzusichern.

Empfehlung Herr Schmidt:

• Microsoft Azure Active Directory

• Vergleichsweise einfache Integration in bestehende Webanwendungen

• Keine Verwendung mit VENTA möglich

• Derzeit nur für Versicherungskunden

• Integration in Azure Service Management, um APIs abzusichern (myPension z.B.)

Swagger

Der Einsatz von Swagger, so wie es derzeit bei uns verwendet wird, entspricht vorgesehenen Verwendung. Keine ToDos.

Oracle / Entities

Oracle ODP.NET ist nicht empfehlenswert, weil vergleichsweise langsam und schlechte Tool-Unterstützung.

DevArt for Oracle ist das Tool der Wahl für den Zugriff auf Oracle Datenbanken via Entities. Der fehlende Service seitens DevArt muss selbst geleistet werden: Neue Versionen als nuGet zur Verfügung stellen, eigene Versionshistorie vorhalten.

Sonstiges

Herr Schmitt empfiehlt die Anbindung unseres AD an Azure AD.

C# 7.0/8.0 bringt wenig sinnvolles Neues, was wir nicht schon kennen

ASP.NET Core bringt für uns keine Vorteile, solange wir nicht mit Docker und/oder anderen Betriebssystemen arbeiten.

Angular.js (oder React.js oder Vue) sind Frameworks, die interessant sein können und gesondert betrachtet werden müssten.

TypeScript als Ersatz für JavaScript ist empfehlenswert.

JavaScript in Webseiten selbst sollte überhaupt nicht benutzt werden, sondern immer in eigene Dateien (dann auch als TypeScript) ausgelagert werden.

Fotos