12

I have looked into both. Would like your suggestions as to which one is better for automated web deployment on multiple servers.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
sam
  • 4,594
  • 12
  • 61
  • 111
  • I wouldn't say it's appropriate to compare them in this way. Although Octopus doesn't use MSDeploy, it's essentially a wrapper around the MSDeploy concept.With MSDeploy you'll use a command line or invoke it inside MSBuild with various arguments. Octopus gives you a friendly web UI to manage your configuration. – The Muffin Man Jul 12 '14 at 06:27

3 Answers3

16

I think you should definitely give TeamCity and Octopus a try. We use TeamCity to create Octopus (NuGet) packages and the Octo tool to automatically trigger deployment to a test environment after each succesfull build. After that we use the Octopus portal to promote deployments to other environments.

We use the following Octo command line to trigger deployments from TeamCity:

Octo.exe create-release --apiKey=YourOctopusAPIKey --server=http://YourOctopusServer:9015/api --project=YourOctopusProjectName --deployto=YourOctopusEnvironment

The Octo create-release step needs to be in a separate TeamCity project, otherwise the NuGet won't be updated with the resulting package from the build.

Marco G
  • 703
  • 6
  • 18
  • Looks like its not free. If you deploy one project its free but then you need to buy. please guide – sam Jul 24 '12 at 11:35
  • it has just come out of beta and it's not free anymore, as far as I know. it offers unlimited usage for just under $800. – Marco G Jul 25 '12 at 12:25
  • Marco: can you please explain how you use octo tool to automatically trigger deployment to a test environment and then using portal to other environments..PLease guide – sam Sep 05 '12 at 09:08
  • @MarcoG They have a 45 day trial of the unlimited package and after 45 days you can continue using it for free for a limited amount of users/machines. Sounds like a killer deal.. – The Muffin Man Jul 12 '14 at 06:30
4

MSDeploy can be used to deploy everything from web applications to databases, and the Web Farm Framework can be used to sync from the main server to secondary servers (which you can also do manually using different sets parmeters, if you prefer).

What you're describing is a "deployment pipeline". I'm not sure how you go about integrating one into Team City, but the basic premise is:

  1. Build the application, test and package it (declaring any parameters that need to be set). Push the package (and any files needed by future steps) to an artifact repository (possibly Team City, if it supports it)
  2. (Automatically triggered) Obtain the package from the artifact repository and deploy it to dev by calling msdeploy -verb:sync -source:package.zip -dest:auto,computerName=http://server:8172/msdeploy.axd -setParamFile:dev.xml
  3. (Manually triggered) Deploy the package to stage
  4. (Manually triggered) Deploy the package to live

MSDeploy supports a surprising number of features, including storing credentials in the windows credential manager and parameterising almost all aspects of a deployment. I highly recommend you check it out. (It's also free, apart from the Windows Server license)

arserbin3
  • 6,010
  • 8
  • 36
  • 52
Richard Szalay
  • 83,269
  • 19
  • 178
  • 237
1

It depends. (strikes me that this question hasn't been flagged yet). But anyway, it's probably worth asking yourself these:

  1. Are you developing a website that requires QA to sign off and promote or have Automated Tests suite to verify each build?
  2. Are you deploying to multiple environments (QA, UAT, Demo, Production) and want to see a nice dashboard of which version is where?
  3. Do you require certain users to have the permission to push to production?
  4. Do you need to deploy other types of components (windows services, databases etc)
  5. Do you need some extra setup on each server before you begin the deployment (e.g. call chocolatey to install and setup Mongo ). Aka limited server provisioning.
  6. Is control required over the promotion lifecycle (e.g. Go to production only if it has been through QA).

If you said yes to most of the above, I would say Octopus Deploy wins hands down for deployment. And guess what, it's free for up to 5 projects and a breeze to get up and running.

For the simple websites that require simple CMS management by end users or websites that don't need to be maintained by developers, I'd say that all the Azure stuff and the MSDeploy is great tool for the job. As Richard Szalay mentioned, it has great command line tools these days to publish regularly.

In terms of a build server, it doesn't really matter because it should be used to just creates you the artefacts. Team City is a winner for me though because it has nice integration with Octopus. IMO, that's a separate discussion.

Dejan Vasic
  • 662
  • 7
  • 17