Build-Prozess (NET/Mono)

Der Build-Prozess compiliert alle NET-Systemkomponenten (Systemprozesse, Wartungsprogramme, Websites/Webservices). Ziel des Build ist, alle ausführbaren Systemkomponenten auf dem jeweiligen System zu erstellen und das SVN-Repository nur noch für Programmcodes (PHP, CS) und Installationsfiles (SQL-Dumps, Vorlagen) zu benutzen.

NET-Programmcode installieren

Der NET-trunk befindet sich z.B im Homeverzeichnis eines Server-Nutzers und wird wie folgt ausgebucht:

cd /home/campus21
svn checkout http://www.campus21.de:8081/trunk trunk

Mono - xbuild

Der NET-Compiler ist Bestandteil der Mono-Installation und wird mit xbuild ausgeführt. xbuild ist in der Parametrisierung mit msbuild identisch. Es können Projekte (.csproj) oder Solutions (.sln) problemlos compiliert werden. Zu beachten ist, dass xbuild bei Solutions nicht automatisch die Buildreihenfolge der Projekte ermittelt (im Gegensatz zu devenv unter Windows). Deshalb muss man in den Solutions die Buildreihenfolge festlegen (MS Visual Studio > Projekt > Projektabhängigkeiten ... entsprechend Verweisen manuell bearbeiten). Bei Nichtbeachtung kommt es zu Fehlern im xbuild. Die Identifizierung der Fehlerquellen ist über die xbuild-Ausgabe möglich aber sehr versteckt.

Der folgende Build-Ablauf erzeugt den Systembereiche und die Websites für die campus21-Produkte und der kundenspezifischen Erweiterungen (Konnektoren):

cd ~/net
xbuild /property:Configuration=Release trunk/Nsoft/Nsoft.sln 

Nach Ausführen jeder Solution sollte geprüft werden, dass der Build-Prozess fehlerfrei abläuft. In der Ausgabe muss erscheinen:

Done building project "/home/campus21/trunk/Nsoft/Nsoft.sln".
Build succeeded.

bzw. am Schluss

0 Error(s)
Time Elapsed 00:00:01.2834070

Das Build erfolgt im Normalfall durch die standardmäßigen oder kundenspezifischen Build-Scripte (siehe unten). Bei geringfügigen Änderungen können Solutions bzw. Projekte einzeln kompiliert werden. Hierbei müssen die Abhängigkeiten der Runtime-Komponenten in den Build-Scripten (System, Websites) beachtet werden.

xbuild /property:Configuration=Release /home/campus21/trunk/Nsoft.His/Nsoft.His.sln
xbuild /property:Configuration=Release /home/campus21/releases/his2010/Nsoft.His.Server/Nsoft.His.Server.sln

Die Ausgabe der dll/exe/mdb-Dateien aller Nsoft-Ordner erfolgt in einen Zwischenordner /home/intranet/net/trunk/bin/Release. Die Ausgabe der Solutions-Ordner erfolgt direkt in die Release-Struktur nach ~/net/releases/his2010/System/bin.

Webservices

Webservices bestehen aus einer asmx-Datei und der Service-Assemblies. Sie werden durch die build-Scripte ebenfalls ablauffähig gemacht.

• Ein/auskommentieren des Website-Builds in build-Scripten
• php-seitiges Neuladen von WSDL forcieren
• bei Re-Build eines eines aktiven Webservice kann es zu Verklemmungen führen:
  System.MissingMethodException: Method not found: 'Npgsql.NpgsqlConnection.get_ProcessID'.

Aufgund der Include/Ausgabe-Pfade der Projekte (.csproj) in den Release-Projekten muss sich der Ordner releases neben dem Ordner trunk befinden, wie durch die SVN-Gesamtstruktur der campus21 - Anwendungsplattform vorgegeben. Bei standardmäßigen Softwareinstallation sollte diese Struktur eingehalten werden.

Ordnerstruktur

Die SVN-Struktur und aktuelle Installationsstruktur (Installationen ab 16.3) ist wie folgt:

+ campus21
  + trunk
  + releases
    + com2010
      + Nsoft.Com.Website
      + System
    + his2010
      + Nsoft.His.Website
      + System
    + node.js

campus21 ist der systemspezifische Wurzelordner (Homeverzeichnis eines Nutzers oder beliebiger Ordner).

Build-Prozess

Nach Aktualisierung des Quellcodes aus der Quellcodeverwaltung wird des standardmäßige Build wie folgt ausgeführt:

cd ~/net/his2010
./update.sh
./build.sh

Kundenspezifisches Build

Ein kundenspezifisches Build ist notwendig, wenn der Build-Prozess entweder von nicht benötigten Komponenten befreit oder um kundenspezifische Komponenten ergänzt werden soll, oder die Softwareinstallation eine abweichend Struktur aufweist. In diesen Fällen wird eine Kopie des Build-Sriptes erstellt, welche angepasst werden kann:

cd ~/net/his2010
cp build.sh build.local.sh
./update.sh
./build.local.sh

Das kundenspezifische Build-Sript muss auf die je nach Vertragsmodell abonnierten Quellkomponenten abgestimmt sein.