"Massendeployment" einer Webapplikation

Hallo,

ich bin gerade am Überlegen wie wir unser Deployment einrichten sollen.

Die Webapplikation (MVC 4) liegt derzeit in SVN, ein Wechsel zu einer anderen Quellcode-Verwaltung wäre allerdings möglich.

Diese Webapplikation soll nun "einfach" auf einen Webserver (dedicated) deployed werden. Entweder in eine fertige "Site" im IIS oder am besten gleich beim Deployen eine neue "Site" anlegen.

Von Kunde zu Kunde unterscheidet sich die Webapplikation nur durch Einstellungen in der web.config (Connectionstring, Settings) alles andere ist identisch. Diese Settings sollten nach Möglichkeit auch direkt beim deployen in die web.config geschrieben werden.

Und nun kommt aber die Geschichte die das Ganze etwas komplizierter macht. Es könnnen unter Umständen sehr viele (>100) "Installationen" werden und das eventuell auch in einer loadbalanceden Umgebung mit mehreren Servern.
Erstinstallationen/Deployments werden immer einzeln gemacht. Aber wie schaffe ich es dass ich bei einem Update schnell und unkompliziert alle Installationen updaten kann.

Gibts für solche Szenarien eine "best pratice"?

thx

Vorneweg: ich hoffe, Du hast Loadbalancing in der Anwendung bereits beachtet...? Session Sharing etc.

"Best Practise" halte ich in diesem Fall für Umsetzungen wie bei phpBB oder Joomla, wo man die Anwendungen direkt in der Applikation aktualisieren kann.
Dies seh ich auch als einzigen Weg, wenn auch für die Entwicklung der Applikation sehr aufwendig, wenn Du alles rasch aktualisieren willst.

Ansonsten stehen Webserver ja meist in der DMZ und da kann man oft auch "nicht mal so" einfach was aktualisieren. Bleibt Dir halt noch die Möglichkeit von WebDeployment oder ein eigener Installer.
So ne Installation und automatische Einrichtung einer Webanwendung auf dem IIS ist ja nun nicht mit sooo viel Aufwand verbunden.

Beachte auch, dass MVC4 ja erst RC ist. Viele Kunden wollen sowas nicht.

Hi Abt,

ja die Anwendung ist für Loadbalancing ausgelegt. 😉 (sollte mit minimalen Anpassungen auch auf Azure laufen)

Aktualisieren direkt aus der Anwendung heraus wird vermutlich nicht gehen. Das Aktualisieren machen immer wir weil die Kunden damit sicherlich komplett überfordert wären.

Ich hab aber noch etwas Zeit zum tüfteln.
Das Projekt startet erst im Herbst produktiv, daher ist das mit dem RC auch nicht so tragisch.

Ich möcht nur schon vorab ein paar Möglichkeiten evaluieren, damit ich nicht im Herbst 2 Tage vor Launch noch schnell das Deployment einrichten muss..

lg

Dann würde ich nen Custom Setup verwenden, wie Wix.
Da gibts dann sicherlich auch die Möglichkeit bestimmte Parameter in einer extra Konfig zu hinterlegen, die das Setup bei der Installation in die web.config schreibt.

Kenne mich mit dem Thema nicht so aus, aber ich würde nen Windows Service schreiben, den du per Installer einmalig deployst und nach Updates frägt und die am besten Nachts installiert. So hast du auch nur Pulls. Dieser Service klönnte auch Logs usw. pushen

Gibts für solche Szenarien eine "best pratice"? Octopus Deploy arbeitet so, dass dass für eine Webseite eine NuGet-Paket erstellt wird (z.B. durch Einchecken der Webapplikation ins Quellcode-Repository + CI-Server) und dann diese Pakete automatisch (oder manuell) verteilt werden.

Selbst verwendet habe ich es noch nicht, die Idee dahinter scheint mir aber sehr interessant:

Zitat von: Octopus - an automated deployment solution for .NET applications - Paul Stovell
Instead of MSI's, Zip files or WebDeploy packages, Octopus standardizes on the NuGet package format. There are a few reasons for this:
Packaging files into a NuGet package is extremely easy

NuGet packages can be consumed via a feed, so other applications can easily query the available packages

CI tools like TFS and TeamCity will soon have support to make publishing NuGet packages easy

Zudem gestaltet es sich mittels NuGet-Paketen auch ziemlich einfach bestimmte Bereiche in der web.config anzupassen.

Gruß,
dN!3L