Deployment von ASP.net (MVC, Webforms) Websites/Applikationen...
Hi,
bei uns werden zur Zeit alle Projekte mit PHP, Smarty und MySQL umgesetzt.
Nun stehen aber einige Projekte an die wir mit ASP.net realisieren müssen
und ich hab sogar das OK wenn mit diesen .net Projekten alles passt bzw.
diese eventuell "besser" laufen (Qualität, Entwicklungszeit,...) auch alle
weiteren Projekte mit ASP.net umzusetzen. Unsere Projekte gehen von Webseiten
über Ecommerce bis zu Individual-Entwicklungen...
Zur Zeit läuft das "Deployment" so:
historische Projekte:
Kein SVN, upload direkt mit FTP auf den Webhost
aktuelle Projekte:
SVN, update der Webhosts direkt aus den jeweiligen SVN-Repositories => kein FTP
Bei den .net-Projekten muss ich mir jetzt etwas mit dem Deployment einfallen lassen. Es soll möglichst einfach aber effektiv sein.
Problem ist hierbei dass im Team mehr Webdesigner als Entwickler arbeiten
und somit bei einem neuen Projekt ab einem gewissen Zeitpunkt die Updates an CSS-Files
und HTML-Code überwiegen. Die Files (css, aspx,...) können ja auch
ohne das Projekt neu zu kompilieren geändert werden. Und diese "kleinen" Änderungen mache mir etwas Sorgen...
Ich weiss dass es CI - Tools wie CruiseControl oder Teamcity gibt.
Ich halte es aber für einen absoluten Overload, bei Änderungen an einem CSS-File
oder HTML-"Template" immer das komplette Projekt neu kompilieren und auf den Server übertragen zu lassen...
Hallo M@TUK,
Das ist der Unterschied zwischen ASP.NET und PHP. Auch wenn es die Möglichkeit mit dem Zend auch gibt.
Du solltest auf jeden Fall alles kompilieren und dann weitergeben. Wenn du NUR eine CSS Datei veränderst oder ähnliches musst du das nicht. Aber wenn du einen entsprechenden Buildprozess hast, der automatisch abläuft, sollte das dich ja nicht interessieren.
Also besonders im Team ist es schon sinnvoll, den Build- und Deployprozess zu automatisieren (CI Server, Buildscripts). Es ist nicht besonders klug, wenn jeder seine Änderungen mal so eben husch-husch auf den Server schiebt - gerade bei "wichtigen" Websites. Da ist also etwas Disziplin gefragt.
Wir handhaben das z.B. so: wir haben einen CI-Server der das Projekt kontinuierlich kompiliert und testet. Damit haben wir sichergestellt, dass es softwareseitig funktioniert. Die so erstellte Site reviewen wir dann "von Hand" um sicherzustellen, dass das optische Design in Ordnung ist. Wenn alles in Ordnung ist und ein Deployment ansteht, starten wir eine andere Buildconfig, die ebenfalls alles kompiliert und testet und dann ein Deployment ausführt. Das Deployment machen wir momentan über MS Web Deploy (http://learn.iis.net/page.aspx/346/web-deploy/), das klappt schmerzfrei und schnell, da nur das Benötigte hochgeladen wird.
Man kann das Deployment auch direkt aus Visual Studio vollziehen. Angenommen, das Team ist sehr klein und der Buildprozess ist sehr einfach, dann ginge das auch. Siehe http://weblogs.asp.net/gunnarpeipman/archive/2009/06/18/visual-studio-2010-web-application-packaging-and-publishing.aspx In dem Fall sollte aber nur eine Person für das finale Publishing verantwortlich sein. Wie gesagt, es hat schon seinen Sinn, in dieser Sache Disziplin zu zeigen und nicht wie die Hottentotten drauf los zu deployen.