Deployment tips

Our TeamCity builds generate .msi files as artifacts and the next step for us is to automate the deployment of these.

I want to separate the deployment from build configuration so adding deployment as build steps is out of the question.

Second, I could script something from a dependant project but it requires a VCS root.
Perhaps a deployment branch of the project containing only the scripts.
That could work if I wire up artifact dependencies.

I was wondering if anyone else here on the forums are doing the same and was willing to share some tips ?

The .msi files are both services, standalone applications and web applications. The difference should not really matter as the msi should take care of that.

Comment actions Permalink

Hi Oscar,

We have similar deployments: Windows services, apps and web apps (all Windows/IIS based). We have separate builds for deployment in separate projects from compilation builds with artifact dependencies. We do not use msi. Instead, we wrote custom scripts for deployment. We are using ClickOnce technology for applications and msdeploy for web apps under the hood. It all works reasonably well.

If msi is not a requirement for you, you could go on a similar route. I could also suggest using PowerShell for Windows stuff since it has a lot of native support for managing services, files, etc. You could also consider Octopus Deploy. We haven't used it, but it looks interesting.

Hope this helps,

Comment actions Permalink


we have landed on msi since it's a type of setup every Windows computer can run and if our customers is a large organization they might have IT-departments who want to silent deploy it via AD or other means. I've also started to get aquainted with WIX installer and see many useful features there.

The decision of delivering applications to customers as msi files is pretty concrete, then we would like to deploy them from the same format in our test/demo environment to be able to uncover installation / upgrade issues.

I did look at Octopus Deploy but was not too fond of the concept:
a) Projects needed to have Octopack NuGet package installed - When I have a build process for binaries, _not_ the installer, I think it is downright wrong to make changes there to facilitate deployment/installation
b) The end result is a NuGet package which isn't really a NuGet package as we know it but in reality a ZIP file with metadata ( - Not much worth to our customers without some extra wrapping
c) Configuration per environment or site is not possible in the Octopus deploy step. *Again, I had to change the source* by adding one app.config transform per deployment.
d) The deployment target is not cleaned automatically as there is no working way of telling Octopus deploy which files are only meant for the deployment. As a result, a webapp could have all these files in it's folder: web.config, web.Demo.config, web.Test.config, PreDeploy.ps1, PostDeploy.ps1

I guess Octopus could work if you only meant to distribute a website internally. Customers are those who use the website and you don't need to ship them an installer or deploy the websites into several production instances with different configuration.

I've just started to look into Chef. Chef has a provisioning system for msi files and, unlike Puppet, it looks like Chef can read the version info of the installed Windows Application and only run the installer when the installer is of a newer version.

Comment actions Permalink

Thanks for the details. Our scenario is internal deployment only, so Octopus might work for us. It's on the roadmap to explore.

ClickOnce has a built-in mechanism to check the version and run the installer only if needed. Works great for Windows apps. I'm not saying Chef is a bad idea, just that there is a Microsoft-centric technology that might work well too.

Good point about msi use for IT silent deployments. We use that for 3rd party apps.


Please sign in to leave a comment.