Automating .Net deployment using Cruise Control .Net

Question

I've currently got CC.Net setup for doing builds and it's awesome. But now I want to go all the way and use it for deployment as well. I was thinking about installing CC.Net on staging and after a build completes and it's autouploaded fire the forcebuild trigger to staging and have it use msbuild and the necessary extensions to gac, install services ect. to get the install done.

I've also seen msdeploy which seems to have similar goals. What do you think of my plan and how are you all doing automated deployment?

Notes

• SMB (File Shares) are disabled in the staging network which eliminates the possibility of psexec. The reason it is disabled is we wanted the network to be locked down and when I asked about opening I was told too many ports need to be opened. Something to do with the authentication?

  • It may be the case that this port argument is bunk. I've setup Samba shares before but I've never worked with Active Directory so I shutup and listened.

• Only FTP, RDP and HTTP are opened

Answer 1

Richard, we didn't want to put CruiseControl anywhere near staging or production servers.

For LAN (ie. internal production servers) we have manually triggered Production Deploy CC tasks which stop IIS (sites and app-pools), copy the new site across and restart IIS stuff.

For DMZ deployments (ie. internet stuff, no AD-auth'd connections possible) we do as much of the build as we can internally and ZIP up the results, including a NAnt script which does the 'final steps'. There is an internal CC task which does all that and FTPs the ZIP out to the target servers. To complete the process requires manual intervention: logging in to the box remotely, unzipping and then running the NAnt to 'complete' deployment (stop/copy/start/whatever).

I'm not sure about GAC, but IIS seems controllable via .VBS files

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

For services we use 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>

Anyway there's probably dozens of ways to approach this - the internally-automated/external-manual-step-required setup works for us.

Answer 2

I Agree with Craig, You don't want CC.NET on your stage servers. We do everything from a build server and pushout to dev. and stage. Using MSBuild we have targets set up for each of the compiles, and for pushing any and all parts out to both servers or combinations of servers depending on which environment. So each project on CC.net on the build server corresponds to a target or tragets in the MSBuild plus the over all continuous builds.