| 

.NET C# Java Javascript Exception

7

Vorab

Für ein aktuelles Projekt ist es nötig, schnell auf reale Umgebungen auszuliefern. In einen Fall soll der Entwicklungsstand (DEV) auf eine Instanz ausgeliefert werden, in der wir Entwickler nochmals testen und ggf. debuggen können und im nächsten Fall soll ein Zwischenstand (QS, mit fertigen Features) zum Testen und für Kundenabnahmen auf eine weitere Instanz ausgeliefert werden. Im letzten Fall, soll der abgenommene Stand (PROD) auf das Produktiv-System ausgeliefert werden.

Es soll allerdings nicht nur ausgeliefert werden. Sowohl die Website als auch drum herum entstandene Projekte sollen auch gebaut und anschließend getestet werden.

Wir haben hier drei - nahezu identische – Deployments auf fast identische Umgebungen. Die unterschiede sind minimal:

  • DEV:
    • voll automatisiert
    • baut im Debug-Modus
  • QS:
    • voll automatisiert
    • baut im Release-Modus
  • PROD:
    • automatischer Build
    • manueller Build-Trigger
    • baut im Release-Modus

Die Versionierung lasse ich in diesem Beitrag mal aus.

Die ersten beiden Builds laufen nach dem Commit in den entsprechenden Branch. Der letzte Build wird manuell angestoßen, wenn die Features getestet und abgenommen sind und dieser Stand in den master-Branch comittet sind.

Alternativ zu den Varianten mit Visual Studio Online die aktuelle überall beschrieben sind, stelle ich hier eine andere, offenere und – aus meiner Sicht – leichtgewichtigere  Variante vor.

Jenkins

Als Build-Server dient eine Jenkins-Installation auf einer VM auf Azure. Dort sind drei Build-Jobs angelegt, von denen zwei auf Änderungen im entsprechenden Branches im Git-Repository reagieren und einer auf den manuellen Start wartet.

Jenkins ist ein sehr Leichtgewichtiger und schneller Build-Server, den ich schon seit Ewigkeiten (Noch unter dem Namen Hudson) eingesetzt habe. Die UI ist zwar nicht sehr hübsch, allerdings ist er leicht zu bedienen und schnell installiert. Für Windows gibt es einen kompletten Installer von Bitnami, für alle denen selbst die manuelle Installation noch zu schwer ist ;-)

Alle Build-Jobs ziehen sich den aktuellen Stand des jeweiligen Branches und rufen ein FAKE-Skript mit Parametern auf. Die Parameter sind unter anderem:

  • Build-Nummer
  • Build-Configuration (debug oder release)
  • Name der entsprechenden Azure Deployment Configuration
  • Das Publish-Passwort

FAKE hatte ich in einem separaten Beitrag kurz vorgestellt und kommt bei mir in privaten Projekten immer zum Einsatz. Im Geschäft ist dies der erste Einsatz von FAKE. Ich gehe hier nur auf den Deploiyment Teil in FAKE ein, nicht auf die Konfiguration des Builds und der Tests, da das nicht sehr von dem abweicht, was in der Dokumentation zu FAKE steht. Die Reihenfolge (Konfigurieren, Bauen, Testen und Ausliefern) ist eh klar.

Der Aufruf des FAKE-Scripts in Jenkins erfolgt über ein Batch-Task, Hier wird ebenfalls nur ein Batch-Script aufgerufen, das – bevor das FAKE-Skript gestartet wird – FAKE aktualisiert, in dem es die aktuellen NuGet Packages zieht. War das update erfolgreich wird das FAKE-Script wie folgt aufgerufen:

CI\build.bat bn=%BUILD_NUMBER% conf=Debug pubprofile="MyMvcProject - Web Deploy.pubxml" pubpwd=%PUBLISH_PASSWORDD%

Deployment mit FAKE

Die Auslieferung war etwas Tricky, wir mussten zuerst herausfinden, wie das mit MS-Build gelöst werden kann. Am Ende war es klar: Wir mussten die Web App nochmals bauen mit den Targets Publish und der Angabe der Azure Deployment Configurations. Also ein Web-Deployment direkt auf die Azure Web App.

Wir haben im FAKE-Script wieder einen MsBuild Aufruf, diesmal mit den erwähnten zusätzlichen Parametern:

let setParamsWeb = [
        "DebugSymbols", "True"
        "Configuration", buildConf
        "Platform", "Any CPU"
        "PublishProfile", publishProfile
        "DeployOnBuild", "true"
        "Password", publishPassword
        "AllowUntrustedCertificate", "true"
        "IgnoreDatabaseSettingOutOfSync", "true"
]

// Publish the application
Target "PackageApp" (fun _ –>
    MSBuild buildDir "Build" setParamsWeb ["MySolution/MyMvcProject/MyMvcProject.csproj"]
      |> Log "AppBuild-Output: "
)

Fazit

Im Grunde war es das auch schon. Dieses Setup ist schnell aufgesetzt, einfach zu warten und läuft auch relativ schnell durch. Das Continuous Deployment an sich ist also angenehm leichtgewichtig. Projektverantwortliche und Kunden können schnell auf den aktuellen Stand schauen und schnell Feedback geben. Was im aktuellen Projekt hervorragend funktioniert hat.

Nach Möglichkeit sollte dieses Setup nun in allen zukünftigen .NET-Projekten genutzt werden. Durch FAKE spart man sich eine übermäßige Konfiguration im Jenkins und kann den gesamten Build- und Deployment-Prozess bequem im Visual Studio bearbeiten. Beim nächsten Commit in den jeweiligen Branch wird das FAKE-Script sofort angewendet.

.net asp.net azure build jenkins continous-integration azure-website buildserver jenkins-ci continous-delivery fake
Schreibe einen Kommentar:
Themen:
fake continous-delivery jenkins-ci buildserver azure-website continous-integration jenkins build azure asp.net .net
Entweder einloggen... ...oder ohne Wartezeit registrieren
Benutzername
Passwort
Passwort wiederholen
E-Mail
TOP TECHNOLOGIES CONSULTING GmbH