Ich versuche herauszufinden, wie msdeploy mit meiner MVC-Site verwendet werden kann, um die Bereitstellungen einschließlich der Einrichtung von IIS auf dem Remote-Server zu automatisieren.
Ich verwende den folgenden Befehl, um das Paket zu erstellen:
%Vor%Meine Einrichtung ist wie folgt:
%Vor%Wenn ich das Kontrollkästchen "IIS-Einstellungen wie in IIS konfigurieren" und "Von diesem Webprojekt verwendete Anwendungspool-Einstellungen einschließen" ankreuze und das Paket auf meiner Entwicklungsumgebung baue, kann es von dort aus veröffentlicht werden. Hier ist der Befehl, den ich verwende:
%Vor%Dies erstellt das virtuelle Verzeichnis auf meinem UAT-Server und alles ist gut. Das Problem ist, wenn ich mich an github verpflichte und der CI-Server es herunterlädt und erstellt. Natürlich ist das virtuelle Verzeichnis nicht auf dem CI-Server eingerichtet, so dass das Build / Paket fehlschlägt.
Ich möchte die von mdeploy angegebenen Pakete verwenden und die Site und IIS remote bereitstellen. Ich denke, es gibt ein paar Optionen:
1) Ändern Sie die MVC-Projektdatei, um die Einstellungen fest zu codieren, damit das XML-Paket bei jeder Ausführung des Build-Pakets mit den richtigen Einstellungen erstellt wird, sodass es von jedem beliebigen Computer bereitgestellt werden kann. Ich denke, dass dies möglicherweise mit der Datei package.xml im Stammverzeichnis des Projekts erledigt werden kann, aber ich habe keine Ahnung, wie ich alle Einstellungen für den App-Pool und das virtuelle Verzeichnis eingerichtet habe. Fühle mich, als wäre ich auf halbem Weg, aber ich kann nicht den letzten Schub über die Linie bekommen.
2) Verwenden Sie Powershell, um erstellte Paket-XML-Dateien zu ändern, sodass die IIS-Einstellungen zum Extrahieren hinzugefügt werden.
Die erste Option ist vorzuziehen, da sie alle Informationen an einem Ort enthält und Sie nicht daran denken müssen, vor der Bereitstellung ein zusätzliches Skript auszuführen.
Ich glaube, ich könnte die zweite Option herausfinden, indem ich VS benutze, um das Paket zu erstellen und die Einstellungen zu bekommen, die ich brauche, dann skript es, aber ich habe keine Ahnung und habe eine Weile damit verbracht, darüber ohne Erfolg zu lesen Ich würde Option eins tun.
N.B.
Wenn ich einige der vorgeschlagenen Fragen lese, bevor ich das gepostet habe, sehe ich einige Möglichkeiten:
MSdeploy implementiert eine MVC 2-Anwendung mit Falscher virtueller Verzeichnisname
Diese Frage bezieht sich auf das Übergeben von zusätzlichen Werten für den Befehl msdeploy. Sie scheint in Ordnung zu sein, aber nicht sozusagen intern im Buildprozess. Ich bin mir nicht sicher, alle Befehle zu verwenden, kann aber googlen, dass ich mir sicher bin.
Dieser Link scheint mit dem oben genannten fortzufahren: Ссылка
Auf dieser Seite werden die Möglichkeiten für Option 2 erläutert. Ссылка
Denken Sie, das ist der Weg: Verwenden von parameters.xml in der Wurzel der Website für Projekte: Ссылка
BEARBEITEN
Ich habe das weiter gelesen und getestet. Mit der Datei parameters.xml im Stammverzeichnis des Projekts kann ich die Parameter ziemlich genau dort finden, denke ich. Mein Problem scheint die Datei archive.xml zu sein. Dies ist sehr unterschiedlich und führt dazu, dass das Paket nicht korrekt installiert wird, wenn das Kontrollkästchen "IIS-Einstellungen verwenden" nicht aktiviert ist. Ich habe begonnen, über [Projekt] .wpp.targets Datei zu lesen, die helfen könnte, aber ziemlich verdammt verloren mit diesem atm.
BEARBEITEN 2
Ich denke also, ich muss die Datei [project] .sourcemanifest.xml holen, um einige ihrer Einstellungen zu ändern. Ich glaube, dass das die archive.xml antreibt, was jetzt anders ist. Ich habe die parameter.xml funktioniert richtig, denke ich.
Wenn Sie IIS NICHT verwenden, sieht die sourcemanifest.xml so aus:
%Vor%Aber wenn ich die IIS-Einstellungen ankreuze, sieht das so aus:
%Vor%Ich bin mir nicht sicher, wie ich es ändern könnte, indem ich an der Datei [project] .wpp.targets arbeite, aber im dunklen atm fummle.
EDIT 3
OK, also dachte ich, ich hätte es für eine Minute. In meiner [Projekt] .wpp.targets Datei habe ich:
%Vor%Was erstellt, erstellt ein Bereitstellungspaket, das ich dann aus meiner Entwicklungsumgebung auf dem UAT-Server bereitstellen kann und es funktioniert. Aber wenn ich es auf meinem CI-Server ausführe, wird es das Bereitstellungspaket nicht erstellen, es wird in der Manifeststufe mit dem Fehler abgebrochen:
%Vor%Die Manifestdatei sieht folgendermaßen aus:
%Vor%Ich vermute, es ist, weil es immer noch die IisApp sowie die AppHostConfig, die ich hinzugefügt habe. Ich denke nur darüber nach und weiß nicht, wie ich das noch entfernen soll.
EDIT 4
OK, also habe ich die Einstellung gefunden, um IISAPP aus dem Manifest und den Parametern zu entfernen:
%Vor%Dies geht in die Datei wpp.targets.
Dies hat jetzt ein neues Problem erstellt, das nicht mehr bereitgestellt wird. Ich glaube, das hat etwas damit zu tun, dass apphostconfig mit Sites und iisapp mit virtuellen Verzeichnissen umgeht.
EDIT 5
Ich habe also die Unterschiede zwischen dem IIS und dem benutzerdefinierten IIS durchgespielt.
sourcemanifest.xml-Dateien sind identisch systeminfo.xml sind die gleichen
setparameter.xml:
Der Name der IIS-Webanwendung ist anders. Mit IIS-Version hat die "Default Web Site / Pokerleague" -Wert, aber meiner hat "C: \ Websites \ Pokerleague".
Ich denke, das ist es, was den Fehler in der parameter.xml verursacht:
Die IIS-Webanwendung hat die gleichen Werte und das Attribut tags hat physisch statt iisapp.
Ich habe ähnliche Tools und automatisiere Build und Deployment:
Ich unterscheide die Build-, Packaging- und Deployment-Schritte. Ich verwende die Msdeploy-XML-Dateien nicht, aber mache dasselbe auf der Kommandozeile.
Das sind meine Schritte:
Klicken Sie mit der rechten Maustaste auf das Projekt "MyAppName" - & gt; Eigenschaften ..., Registerkarte "Paket / Web veröffentlichen" ...
Ich erstelle die IIS-Website beim ersten Mal manuell (vielleicht können Sie automatisieren, ich nicht). Wenn Sie MSDeploy verwenden, wird Ihre App auf den entsprechenden Website-Namen verschoben - Sie müssen keine Zielordnerpfade oder Ähnliches fest codieren.
Speichern Sie es mit Ihrem Projekt, und stellen Sie sicher, dass Ihre Änderungen in Git (an den Ursprung / Master geschoben) überprüft werden. Diese Einstellungen werden von der Versionskontrolle übernommen, wenn der CI-Server die Build-Schritte ausführt.
Ich bearbeite die Build-Schritte und füge einen zweiten Build-Schritt hinzu, um die MyAppName.sln direkt zu erstellen, mit Msbuild. Sie können ändern, wie Sie möchten, da Sie dies wahrscheinlich schon irgendwie tun.
Grundsätzlich müssen wir entweder VS auf dem Build-Server installieren, Dateien manuell kopieren oder Microsoft Visual Studio 2010 Shell (Integriertes) Redistributable-Paket .
Microsoft.WebApplication.targets wurde auf dem Build-Server nicht gefunden. Was ist Ihre Lösung?
Damit wird es gebaut. Noch immer keine Bereitstellung auf einem Server.
Ich erhalte das Webbereitstellungstool hier und installiere es. Nach dem Neustart hat die TeamCity-Anmeldung einen 404-Fehler. Es stellt sich heraus, dass Web Deploy über einen Dienst verfügt, der Port 80 überwacht, aber auch TeamCity Tomcat Server. Kurzfristig stoppe ich den Web Deploy-Webdienst in der Systemsteuerung und starte den TeamCity-Webdienst. Der Zweck des Web Deployment Agent-Diensts besteht darin, Anforderungen von anderen Servern an diesen Server zu akzeptieren. Wir brauchen das nicht, da der TeamCity-Server als Client fungiert und auf anderen Webservern eingesetzt wird.
Das Web Deployment Tool muss ebenfalls auf dem Ziel-Webserver installiert sein. Ich werde hier nicht zu sehr ins Detail gehen, aber Sie müssen den Dienst so konfigurieren, dass er auch zuhört. Wenn Sie also den Befehl deployment ausführen, wird er akzeptiert und auf dem Server installiert. Für den Server habe ich ein neues Konto mit dem Namen 'webdeploy' mit der Berechtigung zur Installation eingerichtet.
Ich teile separate Schritte für das Packen und Deployment. Dadurch können Sie Fälle erstellen, in denen Sie ein Release-Paket erstellen, es jedoch manuell bereitstellen können.
Dies ist der Paketbefehl msbuild:
%Vor%Lassen Sie mich die Befehlsteile erklären:
MyAppName.csproj: Pfad zur zu erstellenden VS-Projektdatei. Dort sind wichtige Optionen, die auf den Projekteigenschaften-Registerkarten festgelegt werden.
/ T: Paket: Erstellen Sie ein ZIP-Paket
/ P: Konfiguration = Debug; PackageLocation = ***: Führen Sie die Debug-Konfiguration aus. Dies entspricht der Erstellung in Visual Studio mit der Einstellung "Debuggen". Der 'Package Location' ist was er erstellt hat. Wir werden später im Implementierungsbefehl auf die Paketdatei verweisen.
Dieser Befehl sollte auch im Detail erklärt werden:
-verb: sync: Synchronisiert die Website von der Quelle zum Ziel
-source: package="C: \ Build \ MeineAppName.Debug.zip": source ist ein MSBuild Zip-Dateipaket
-dest: auto, wmsvc = Webservername: Verwenden Sie die Einstellungen in der Paketdatei, um sie auf dem Server bereitzustellen. Das Benutzerkonto ist ein Konto auf Betriebssystemebene mit Berechtigung. Der Hostname wird angegeben, jedoch nicht der Name der IIS-Website (der zuvor in der MSBuild-Projektdatei in den Projekteigenschaften angegeben wurde).
Nach der Bereitstellung habe ich die IIS-Webserver-Dateien überprüft, um sicherzustellen, dass sie über die neuesten DLLs und die Datei web.config verfügen.
Da es jetzt zwei gute Befehle gibt (MSBUILD.exe zum Packen, MSDEPLOY.exe zum Bereitstellen), fügen Sie sie den Build-Schritten hinzu. Ich benutze den Befehlszeilen-Runner und gebe einfach den gleichen Befehl wie die vorherigen 2 Schritte ein.
Wenn Sie den Build mit diesen Schritten ausführen, haben Sie eine automatische Bereitstellung direkt aus git, wenn sie erfolgreich sind.
Jedes Mal, wenn neuer Code zusammengeführt und an den Ursprung / Master-Zweig gesendet wird, wird der Entwicklungsserver automatisch erstellt und bereitgestellt.
Wie Sie sehen, vermeidet dies das ursprüngliche Problem:
Das Problem ist, wenn ich mich zu github verpflichte und der CI-Server herunterlädt und baut es auf. Natürlich ist das virtuelle Verzeichnis nicht auf dem CI eingerichtet Server, so dass das Build / Paket fehlschlägt.
Der CI-Server baut und packt nur. Dann wird es auf dem Ziel-Webserver bereitgestellt.
Sehen Sie sich Appveyor an. Wir haben gerade v2.0 und IMHO veröffentlicht, es ist eine wirklich starke Alternative zu WebDeploy. Der gesamte Bereitstellungsprozess kann über die PowerShell auf dem CI-Server gesteuert werden, und es gibt PS-Hooks, mit denen Sie den Prozess anpassen können.
Haftungsausschluss: Ich bin Entwickler von Appveyor. Ich versuche hier nicht zu werben, aber es wäre schön zu sehen, ob das für dich funktioniert.
Tags und Links asp.net-mvc iis msdeploy