Automatisieren .Net-Bereitstellung mit Cruise Control. NET

Question

Ich habe derzeit CC.Net-Setup für Builds und es ist super. Aber jetzt möchte ich den ganzen Weg gehen und es auch für den Einsatz verwenden. Ich habe darüber nachgedacht, CC.Net auf dem Staging zu installieren und nachdem ein Build abgeschlossen ist und es autouploaded den forcebuild-Trigger auf Staging feuert, benutze es msbuild und die notwendigen Erweiterungen für gac, installiere Dienste ect. um die Installation zu erledigen.

Ich habe auch msdeploy gesehen, die ähnliche Ziele zu haben scheint. Was halten Sie von meinem Plan und wie machen Sie alle eine automatisierte Bereitstellung?

Hinweise

• SMB (File Shares) sind im Staging-Netzwerk deaktiviert, die die Möglichkeit psexec eliminiert. Der Grund, warum es deaktiviert ist, ist, dass wir wollten, dass das Netzwerk gesperrt wird, und als ich nach dem Öffnen fragte, wurde mir gesagt, dass zu viele Ports geöffnet werden müssen. Etwas mit der Authentifizierung zu tun?

  • Es kann der Fall sein, dass dieses Portargument Koje ist. Ich habe bereits Samba-Freigaben eingerichtet, aber ich habe noch nie mit Active Directory gearbeitet, also habe ich den Mund gehalten und gehört.

• Nur FTP, RDP und HTTP werden

  geöffnet

Answer 1

Richard, wollten wir nicht CruiseControl- irgendwo in der Nähe Staging oder Produktionsserver setzen.

Für LAN (dh interne Produktionsserver) haben wir Production Deploy CC-Aufgaben manuell ausgelöst, die IIS (Standorte und App-Pools) stoppen, die neue Site kopieren und IIS-Dateien neu starten.

Für DMZ-Implementierungen (dh Internet-Stuff, keine AD-Auth'd-Verbindungen möglich) machen wir so viel Build wie wir intern und ZIP-up die Ergebnisse, einschließlich ein NAnt-Skript, das die "letzten Schritte" . Es gibt eine interne CC-Aufgabe, die all dies erledigt und die ZIP-Datei auf die Zielserver überträgt. Um den Prozess abzuschließen, ist ein manueller Eingriff erforderlich: Loggen Sie sich remote in die Box ein, entpacken Sie sie und führen Sie dann den NAnt aus, um die Bereitstellung abzuschließen (anhalten/kopieren/starten/was auch immer).

Ich bin über GAC nicht sicher, aber IIS scheint steuerbar über .VBS Dateien

' Connect to the WMI WebAdministration namespace. 
Set oWebAdmin = GetObject("winmgmts:\\devserver.local\root\WebAdministration") 
' Specify the application pool. 
Set oAppPool = oWebAdmin.Get("ApplicationPool.Name='ProjectName'") 
' Stop the application pool. 
oAppPool.Stop 
' now website; get the application website 
Set objWebSite = GetObject("IIS://localhost/W3SVC/7") ' id of web site 
' get the app pool object for the websites app pool id 
Set objAppPool = GetObject("IIS://localhost/W3SVC/AppPools/ProjectName") 
'stop the site 
objWebSite.Stop() 
' stop the app pool 
objAppPool.Stop() 

Für Dienstleistungen, die wir psexec.exe über NAnt verwenden

<property name="Remote.Executor" value="${ToolsDir}\PSTools\psexec.exe" overwrite="false" /> 
    <!-- installs a particular windows service remotely from the command line --> 
    <target name="installWindowsServiceRemote"> 
    <echo message="${Service.Install.Action}ing ${Service.Name} on ${Deploy.TargetServer}..." /> 
    <exec program="${Remote.Executor}"> 
     <arg line="\\${Deploy.TargetServer} ${Deploy.TargetFolder}\${Service.Name} /${Service.Install.Action}" /> 
    </exec> 
    </target> 

Wie dem auch sei wahrscheinlich, diesen Ansatz Dutzende von Möglichkeiten gibt es - Das von uns automatisch/extern-manuell-Schritt-Setup durchgeführte Setup funktioniert für uns.

Answer 2

Ich stimme Craig, Sie wollen nicht CC.NET auf Ihrer Bühne Servern. Wir machen alles von einem Build-Server und Push-Out zu Dev. und Bühne. Unter Verwendung von MSBuild haben wir Ziele, die für jedes der Kompilierungen eingerichtet sind, und um alle Teile auf beide Server oder Kombinationen von Servern zu übertragen, abhängig von der jeweiligen Umgebung. So entspricht jedes Projekt auf CC.net auf dem Build-Server einem Ziel oder Traageräten in dem MSBuild plus den über alle kontinuierlichen Builds.