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
Themen_Workshop.pptx (578,3KB)