Automazione. Distribuzione di rete tramite Cruise Control .Net

Question

Attualmente ho installato CC.Net per creare build ed è fantastico. Ma ora voglio andare fino in fondo e usarlo anche per la distribuzione. Stavo pensando di installare CC.Net su staging e dopo che una build è stata completata ed è stata caricata automaticamente l'attivazione del trigger di forcebuild in staging e si è dovuto usare msbuild e le estensioni necessarie per gac, installare servizi ect. per completare l'installazione.

Ho anche visto msdeploy che sembra avere obiettivi simili. Cosa ne pensi del mio piano e come stai facendo un deployment automatico?

Note

• SMB (File Share) sono disabilitati nella rete messa in scena, che elimina la possibilità di psexec. Il motivo per cui è disabilitato è che volevamo che la rete fosse bloccata e quando ho chiesto di aprire mi è stato detto che molte porte devono essere aperte. Qualcosa che ha a che fare con l'autenticazione?

  • È possibile che questo argomento di porta sia a castello. Ho già configurato le condivisioni di Samba, ma non ho mai lavorato con Active Directory, quindi chiudo e ascolto.

• Solo FTP, HTTP e RDP sono aperti

Answer 1

Richard, non volevamo mettere CruiseControl nessuna parte vicino a server di gestione temporanea o di produzione.

Per LAN (ovvero server di produzione interni) abbiamo attivato manualmente le attività di Production Deploy CC che interrompono IIS (siti e pool di app), copiano il nuovo sito e riavvia IIS roba.

Per le distribuzioni DMZ (ad esempio, roba su Internet, nessuna connessione AD-auth possibile) eseguiamo il maggior numero di build possibile internamente e ZIP i risultati, incluso uno script NAnt che esegue i "passaggi finali" . Esiste un task CC interno che esegue tutto ciò e FTP l'ZIP verso i server di destinazione. Per completare il processo è necessario un intervento manuale: accedere alla casella da remoto, decomprimere e quindi eseguire il NAnt per completare la distribuzione (stop/copia/avvio/qualunque).

io non sono sicuro di GAC, ma IIS sembra controllabile tramite file VBS

' 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() 

Per i servizi che usiamo psexec.exe via NAnt

<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> 

Comunque c'è probabilmente decine di modi per affrontare questo - L'installazione automatica/esterna-manuale-step-richiesta funziona per noi.

Answer 2

Sono d'accordo con Craig, Tu non vuoi CC.NET sui tuoi server di scena. Facciamo tutto da un server di build e pushout a dev. e stage. Usando MSBuild abbiamo gli obiettivi impostati per ciascuna delle compilazioni, e per spingere qualsiasi e tutte le parti verso entrambi i server o combinazioni di server a seconda di quale ambiente. Quindi ogni progetto su CC.net sul server di costruzione corrisponde a un target o traget nel MSBuild più le build continue.