﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Josh Robb commented on How do you deploy</title><description>Are you using web deployment projects for the msbuild task? 
</description><link>http://ayende.com/2220/how-do-you-deploy#comment12</link><guid>http://ayende.com/2220/how-do-you-deploy#comment12</guid><pubDate>Fri, 23 Mar 2007 12:42:59 GMT</pubDate></item><item><title>Jay Flowers commented on How do you deploy</title><description>I have had years of success with rcmd and rcmdsvc. They are Windows Resource Kit tools. Normally I copy a set of scripts to the remote machine and execute it with rcmd. The trick to rcmd is you have to pipe all the commands that you want to execute to it from a file. Like this:
  
  
rcmd \\machinename &lt;InstallCommands.txt
  
  
Hope that helps.
  
Jay
</description><link>http://ayende.com/2220/how-do-you-deploy#comment11</link><guid>http://ayende.com/2220/how-do-you-deploy#comment11</guid><pubDate>Sun, 18 Mar 2007 19:59:18 GMT</pubDate></item><item><title>Marius Popescu commented on How do you deploy</title><description>Hi,
  
  
We're using a visual deployment tool called FinalBuiilder. It has lots and lots of actions you can use, lets you add your actions, it runs o Windows only, can get sources from a lot of source servers, can check .Net, IIS, start and stop services, install, start and stop COM+ objects, upload to FTP, send msn messages and use VisualStudio, Java or Delphi IDEs to build or compile projects and a lot of other stuff.
  
  
Plus, the editor is reaaaaly great, you can extract actions in a kind of procedure, you can surround groups of actions with try..catch - like actions, etc.
  
  
There is another benefit from using it, the build script can be printed and attached to project documentation, as a deployment procedure.
  
  
It costs about $400/$1000 depending on versions.
  
  
Try it for 30 days, we did it and never regret it.
  
  
Regards,
  
Marius
</description><link>http://ayende.com/2220/how-do-you-deploy#comment10</link><guid>http://ayende.com/2220/how-do-you-deploy#comment10</guid><pubDate>Sat, 17 Mar 2007 12:49:03 GMT</pubDate></item><item><title>Andreas &amp;#214;hlund commented on How do you deploy</title><description>In TFS changing build quality is something that is done manually and can also be restricted to certain users so it's nothing that happens "automatically" and I can't see that it has anything to do with CI.  
  
  
Eg. when the testmanager reports that all changes has been verified successfully in acceptance test the release manager will decide when it's appropriate to deploy to production. And at that time change the build quality to "Production" -&gt; and there by starting the deployment. (which of course should start by backing up everything). But I agree that the most appropriate use for this is deploying the different test environments...
  
  
Just my 50 cents....
  
  
  
</description><link>http://ayende.com/2220/how-do-you-deploy#comment9</link><guid>http://ayende.com/2220/how-do-you-deploy#comment9</guid><pubDate>Sat, 17 Mar 2007 12:13:44 GMT</pubDate></item><item><title>Luke Melia commented on How do you deploy</title><description>You might take a look at Capistrano in the Ruby on Rails world. It's a great solution for doing what you're after. If you're willing to install ssh and learn how to use it, it can be used for Windows deployments of non-Rails app. Or, it might just be good for inspiration.
</description><link>http://ayende.com/2220/how-do-you-deploy#comment8</link><guid>http://ayende.com/2220/how-do-you-deploy#comment8</guid><pubDate>Sat, 17 Mar 2007 03:05:55 GMT</pubDate></item><item><title>Bil Simser commented on How do you deploy</title><description>I'm pretty happy with our process. We build Smart Client apps using the CAB framework along with some other 3rd party tools. Took me a few tries and lots of pain but finally came up with a combination of NAnt tasks and an MSBuild script and some additional files but it's now one command line option:
  
  
tools\NAnt\Nant.exe deploy-XXX
  
  
where XXX is localhost, QA, UAT, or Production.
  
  
It syncs up with a configuration in the solution for each environment (which will pull in the appropriate settings and connection string files for each environment).
  
  
Used to take 4 hours to deploy, takes 5 minutes now.
</description><link>http://ayende.com/2220/how-do-you-deploy#comment7</link><guid>http://ayende.com/2220/how-do-you-deploy#comment7</guid><pubDate>Sat, 17 Mar 2007 00:06:49 GMT</pubDate></item><item><title>Ayende Rahien commented on How do you deploy</title><description>What you describe is a CI process. Watching the source repository and running a script when it changes.
  
Part of the CI process in your case is to deploy to a server.
  
  
I am not sure that I would want production deployment to happen just because I changed something. I would want to start the process manually. (And sure as hell the first step of this script is going to be a full backup).
  
</description><link>http://ayende.com/2220/how-do-you-deploy#comment6</link><guid>http://ayende.com/2220/how-do-you-deploy#comment6</guid><pubDate>Fri, 16 Mar 2007 21:46:13 GMT</pubDate></item><item><title>Andreas &amp;#214;hlund commented on How do you deploy</title><description>I don't see why a "TFSDeployer"-like solution can't be used to deploy to production. 
  
  
1. Install the service on your production machine(s)
  
2. When a build quality is changed to "production" (i don't know of CruiseControl have the notion of "build qualities") the service will download the build-output and execute the powershell script associated with "production" on the specific server. 
  
  
(TFSDeployer is not about CI, we are using "TFSIntegrator" for CI)
  
</description><link>http://ayende.com/2220/how-do-you-deploy#comment5</link><guid>http://ayende.com/2220/how-do-you-deploy#comment5</guid><pubDate>Fri, 16 Mar 2007 21:39:10 GMT</pubDate></item><item><title>Jeff Brown commented on How do you deploy</title><description>In our case the CI build server produces a ZIP file containing the build image.  Then we run a command on a master deployment machine which pulls the latest build ZIP (or a specified version) and uses the WSHController COM object to fire off commands on the individual servers to deploy that version, also providing additional information about the environment.
  
  
I wrote a prototype batch deployment tool using Ruby on Rails two weeks ago which will eliminate the step of remoting into the master deployment machine.  This needs to be under partial manual control because we use the same process in production, so it's not just for CI.
  
  
The CI integration deployment is much simpler.  The CCNet instance on the build server fires a message over to force the CCNet instance on the integration server to deploy the latest build image and run the tests.  Pretty simple.
  
  
The remote deployment trick with WSHController has worked fine for 5 years.  Unfortunately we started having reliability issues with WSHController which occasionally crashes or hangs (apparently due to a buffer overflow in its handling of environment variables).  Yesterday I spend 2 hours rewriting the remote deployment script to use PsExec instead.  Then I spent 14 hours trying to figure out why it also crashes (C0000409) or hangs (when its output is redirected to a pipe).  And today I've spent a couple more hours.  It really makes me wish we were just deploying to a Unix environment via SSH!  I'm left wondering which patch, upgrade, or service pack might have caused my current woes.
  
  
So... now I'm going to take a break, take a walk, try to do something about my sinus headache and get down to working on MbUnit v3.
</description><link>http://ayende.com/2220/how-do-you-deploy#comment4</link><guid>http://ayende.com/2220/how-do-you-deploy#comment4</guid><pubDate>Fri, 16 Mar 2007 20:04:47 GMT</pubDate></item><item><title>Ayende Rahien commented on How do you deploy</title><description>Sorry, I am not talking about continuous integration, I use CC.Net for this.
  
I am talking about "pushing to production".
</description><link>http://ayende.com/2220/how-do-you-deploy#comment3</link><guid>http://ayende.com/2220/how-do-you-deploy#comment3</guid><pubDate>Fri, 16 Mar 2007 19:01:13 GMT</pubDate></item><item><title>Andreas &amp;#214;hlund commented on How do you deploy</title><description>"TFSDeployer" solves this in a nice way, in short:
  
  
A service on the target machine that monitors build status in Team Foundation Server. When status changes to some configured value the service downloads the build output and runs a powershell script.
  
  
Check it out here: 
  
  
http://notgartner.wordpress.com/tag/projects/tfs-deployer/
  
</description><link>http://ayende.com/2220/how-do-you-deploy#comment2</link><guid>http://ayende.com/2220/how-do-you-deploy#comment2</guid><pubDate>Fri, 16 Mar 2007 18:57:31 GMT</pubDate></item><item><title>Colin Ramsay commented on How do you deploy</title><description>I have my build server send a zip of each build that succeeds up to the deployment server. The zip is named after the subversion revision that triggered the build. To deploy I jump on the server and type "deploy xxx" where xxx is the revision number, and that handles everything.
  
  
I'm sure I could do that last step from a remote shell somehow (WMI?) but it's no trouble for me to log on.
  
  
http://www.colinramsay.co.uk/2006/12/13/my-deployment-process/
</description><link>http://ayende.com/2220/how-do-you-deploy#comment1</link><guid>http://ayende.com/2220/how-do-you-deploy#comment1</guid><pubDate>Fri, 16 Mar 2007 16:34:20 GMT</pubDate></item></channel></rss>