[VP] Source-Code und Versionierung - DRAFT

Versionsverwaltung: Wo liegt der Quellcode für das "Grundprodukt"

Aktuell in 'Repos' auf dev.azure
Zusätzlich sind noch einige Quino-Libraries nötig, die man separat dazuladen muss. Hierfür können wir jederzeit einen Zugang haben. 

Deployed werden die Encodo Libraries über NuGet Packages

Versionsverwaltung: Wo liegen die Anpassungen, welche innerhalb des "Grundproduktes" gemacht werden?

Versionierung: Wie wird das "Grundprodukt" versioniert?

Versionierung: Wie werden die Anpassungen innerhalb des "Grundproduktes" versioniert?

Die Version des Quino-Frameworks und Produkte unter Kontrolle Encodo haben den folgenden Versions-Aufbau: 10.23.0523: Quino v. 10 vom 23. Mai 2023

Test und Build sind identisch, nur unterschiedlich deployed

Unserer Erweiterungen sind implementiert als sogenannte Artifacts und wären auch in Packages ladbar, diese Anpassung wäre aber ohne grösseren Nutzen.

Build: Wie / wo wird das Produkt gebaut?

Wie aufwändig wäre ein Build unter TeamCity (oder GitLab), so dass es den internen Entwicklern im gewohnten Rahmen zugänglich wäre?

Der Build ist laufend in Azure DevOps, auf der Instanz von Encodo.

Die meisten Kunden von Encodo lassen die Source Codes auf Azure wegen der Unterstützung durch Encodo.

GitLab und Team kommt bei ihren Kunden auch vor, benötigt würde dafür ca. 1 Tag initialer Aufwand, Das Repository liesse sich clonen mit einem Azure Feed.

Deployment: Welche Bestandteile müssen für eine einzelne Kunden-Instanz vorhanden sein? → DB, BPE, Azure, etc.

• VinX ADM Executable - das ist die Version, die wir in unserer Azure-Instanz sehen und aktivieren. Sie läuft in unserer Azure Instanz.
• App Server (Web Server, basierend auf IIS) und ist Bestandteil unserer Azure-Instanz
• Hybrid Connection auf dem Server des Kunden
• Datenbank auf dem Kunden-Server
• Zugrunde liegende Konfiguration AppSettings basierend auf iConfiguration. Diese liegen auf unserer Azure Instanz.

ECUI kennt zwei Rollen in der Entwicklung

• Entwickler: Schreibt Backend und View Logik in DotNet
• Customizer: Erstellt Views in der Lösung und parametrisiert die Systemeinstellungen. 

Die Entwicklerarbeiten sind engecheckt im Azure Devops.

Die Customizer Tätigkeit wird im Portal unter 'Ansichten'. Dies ist in der Kundendatenbank in der Tabelle QuinoLayout. Von dort kann Sie mittels XML Export gesichert werden. Eingecheckt sind sie in Subversion im Trunk unter VinX\Portal, also in Nachbarschaft zu den Modulen.

Deployment: Welche Infrastruktur wird für DEVs verwendet, welche für Freigabetests, etc.?

Von allen Kunden wird eine Test und und Prod-Instanz angelegt, die auf das entsprechende Dev und Prod System des Kunden zeigen. 

Diese Instanzen laufen analog Performa mit einem konfigurierbaren Approval Prozess.

In Azure unter https://dev.azure.com/encodo/I-AG/_release?_a=releases&view=mine&definitionId=1

Es gibt eine Konfigurationsmöglichkeit von Wartungs-Fenstern-Meldungen mit frühzeitigen Ankündigungen.

Löschen in Azure räumt die Applikation mit den Settings weg.

Hybrid-Connection, Portal-Addin, Datenbank sind auf dem Kunden-Server und dort wegzuräumen.

Health Check in Azure wurde für Performa aufgesetzt, fehlt bei uns noch - Aufwand geschätzt ca. 2 - 4 h

Diverse Applikations-interne Checker vorbereitet, liesse sich mit automatischem Mail-Versand umsetzen.

Alle Kundeninstallation sind jetzt schon unserem Azure Bereich

Nur die Sourcecode und Pipelines sind im Encodo-Bereich. Sie deployen / pipelinen dann aus ihrem Bereich zu unserer Subskription.