Advantages of Octopus Deploy over TFS Release Management

Chris Fulstow's Avatar

Chris Fulstow

17 Jun, 2014 03:42 AM

Hi - does anyone have any thoughts on the benefits of Octopus Deploy over TFS Release Management (previously InRelease)?

  1. Support Staff 1 Posted by Paul Stovell on 17 Jun, 2014 11:40 PM

    Paul Stovell's Avatar

    Hi Chris,

    Thanks for getting in touch. I'm obviously biased so I won't post too much on this topic, but Ian Paullin from Accenture tried both products and shared his thoughts in a presentation recently. You can view the slides here (go to slide 10):

    Hope that helps!


  2. 2 Posted by Chris Fulstow on 17 Jun, 2014 11:46 PM

    Chris Fulstow's Avatar

    Excellent resource, thanks Paul.

  3. 3 Posted by ianpaullin on 17 Jun, 2014 11:53 PM

    ianpaullin's Avatar

    Pilot tested both Octopus Deploy and Release Management from Nov 2013 to Feb 2014. Octopus won. Here's the breakdown (in no particular order):

    RM - requires one consistent port (difficult to achieve for large networks with varying firewall rules and restrictions); OD - tentacles can use any port to access the server

    RM - all deployments use the TFS drops folder. No centralized storage. No real security from end to end. OD uses NuGet which is much more secure (HTTPS) and Octopus records hashes of NuGet packages too! NuGet feeds can require an API key as additional security. ProGet commerical NuGet server offers NTML/AD based authentication for more security as well.

    RM - logging is really fragmented. OD - centralized from multiple servers and view-able in real-time. Everything is recorded by default. No need to configure anything.

    RM - desktop client only (there is a web client but only for approvals of deployments); OD - web client only

    RM - deployments are serial by default (requires quite a bit of work to do in parallel); OD - deployments are parallel by default (can do serially in batches).

    RM - continuous deployments from TFS build require another license on the TFS build server; OD - a simple PowerShell script + octo.exe and you can do continuous deployments

    RM - requires SQL Server; OD - RavenDB is built-in so no additional cost

    RM - pricing is high; OD - pricing is extremely low by comparison (especially for large environments)

    RM - just moves files around with XCOPY. OD uses NuGet packages to distribute your applications. You can create some very neat backup scenarios for your applications as NuGet packages.

    RM - no benefits for TFS drops storage; OD - TFS build server can have a much smaller retention policy as all your builds are NuGet packages stored on a server elsewhere! Save your TFS build server storage with NuGet!

    There's probably more points that I forgot but those are some of the big points. It's possible that Release Management has made some changes since February that I'm not aware of. That said, Octopus (and NuGet) is a fantastic automated deployment solution.

    *Just wanted to note as well, Octopus is always adding more and more features per release. The release cycle (so far) has been extremely fast. I think it's starting to slow down which is fine as it's growing to be a more mature product with a much larger feature set. I think the UserVoice site where people can submit ideas and the library ( are serious assets to the growth of Octopus over the past six months since I've started using it. I don't think RM has any comparable assets to match OD in the community sense.

  4. 4 Posted by Chris Fulstow on 18 Jun, 2014 01:15 AM

    Chris Fulstow's Avatar

    Thanks Ian - great analysis, very useful indeed.

  5. 5 Posted by Patrick Magee on 03 Nov, 2014 11:07 AM

    Patrick Magee's Avatar

    We found that Octopus had one killer problem - it requires everything to be deployed via Nuget. No bad thing in itself, however we have a very large application with hundreds of separate projects, and using Nuget would have required a great deal of extra work before we could use Octopus. RM allowed us to re-use most of our existing build and deployment scripts, and so ended up much cheaper.

  6. 6 Posted by ianpaullin on 03 Nov, 2014 05:28 PM

    ianpaullin's Avatar

    I wouldn't refer to NuGet as a killer problem. In fact, NuGet gives you versioning, the ability to rollback and is more secure (Octopus stores the SHA1 hash) then say XCOPY - which RM uses (straight from the build folders FYI). Additionally, using NuGet gives our build servers a little more storage space as we don't have to retain so many builds for each project in TFS.

    So maybe you don't prefer NuGet because it _appears_ to be a hassle. And I'm not sure what the "great deal of extra work" would refer to either. It sounds like your experience with RM was (mentally) an easier transition for you so by extension, cheaper in terms of time (not cost). In terms of actual cost, I'd still argue in favor of Octopus. That said though, I'm curious to know more details on your app with hundreds of separate projects. We've got close to 100 different project teams using Octopus and NuGet (primarily with the OctoPack) so I'm not sure what the apprehension is specifically around NuGet. Could you explain how NuGet would not have worked well within your project?

  7. 7 Posted by Patrick Magee on 04 Nov, 2014 09:51 AM

    Patrick Magee's Avatar

    We have ~140 separate projects in a large legacy app with working powershell based deployment script. I have the job of automating the deployment to our test and demo environments. To use Octopus we would first have to edit each project to generate Nuget packages, and then set up the deployment to deploy them. This will all take quite a while and would require full end-to-end testing. By using RM, we can use our existing scripts to run a deployment without having to change any projects, and have the benefit of re-using the scripts that have already been tested. This saves us a lot of time, and given our tight delivery schedules, this is why I called it a killker problem. I agree that a Nuget based approach is fundamentally better, and if I were starting from scratch I would prefer to go that way, but for our scenario, RM gives us a better solution.

  8. 8 Posted by ianpaullin on 20 Jan, 2015 07:53 PM

    ianpaullin's Avatar

    I'd argue that RM gives you an easier path for adoption but long-term, I wouldn't bet on RM adding significant value if you're leveraging your previous scripts for everything. Granted, I don't know all the particulars regarding your projects so maybe there's more to it than just using previous scripts.

    We have a lot of projects and teams all using Octopus. The work has to be done up front - there's no getting around that. Any other tool, I'd imagine, is the same. RM may indeed be capable of easily using your current scripts, but as far as I can tell from that, you really haven't automated too much. You've just used a tool that augments what you currently have in place. Saving time up-front may have been a key factor for you, but long term I'm not sure how RM helps you.

  9. 9 Posted by danny.bird on 26 Jan, 2015 10:06 AM

    danny.bird's Avatar

    regarding the nuget aspect here, internally OD is great, but we have many large customers that want an MSI to deploy to 1000's of clients. this is why I've asked for disconnected tentacle deployments in another thread, which I'm told will come soon, but unless I can wrap that in a msi it's useless to my customers who we're contracted to deliver MSI for SCCM deployments.

  10. 10 Posted by ianpaullin on 26 Jan, 2015 09:25 PM

    ianpaullin's Avatar

    I read your post regarding this issue:

    Do you mean disconnected as in being able to install the tentacle in a disconnected state (not paired with octopus server API key)?

    One question: 1000s of clients (I assume desktops)? Really? You're going to have Octopus distribute releases to desktops? Isn't that a task for SCCM? Or is that not your intended usage of Octopus?

  11. 11 Posted by Harish on 30 Jun, 2015 07:01 AM

    Harish's Avatar

    The above comparison does not hold good anymore. Has anyone done a comparison between latest RM for VS013 or upcoming RM for VS 2015 versus latest octopus?

  12. 12 Posted by Richard on 31 Jul, 2016 07:51 PM

    Richard's Avatar

    I would agree with with TFS2015 and TFS15 next generation of TFS there is no reason to use Octopus Deploy if you are already tied with TFS and Microsoft. Big advantage being you don't have "Tenacles" Services running on the deployment machines...TFS2015 uses Agent Pools and machines to push deployments to the target servers... So much more flexible and scaleable with Agent Pools... Microsoft has stepped it up from Release Manager v1.0 which was very slow client and high in configuration maintenance. If you are not using TFS 2015 then I would agree that Octopus Deploy to be a viable option.

  13. 13 Posted by Terence on 08 Nov, 2016 07:07 PM

    Terence's Avatar

    I looked at OD last year and now looking at RM on VSTS. Perhaps I haven't found a way in RM yet but these are issues in RM that I came across:
    1. RM gives up variables, but not masked and stored securely. OD can readily do that.
    2. Library variable set. Common variables that you need to redefine per release in RM that you can just inherit in OD.
    3. Manual tasks - RM only gives you pre/post approvals. You can have many interim manual tasks in between steps in OD. It is probably counter-intuitive in the current DevOps world to have many manual steps, but I live in a process heavy government environment.

    We have not implemented any of the tool but are evaluating. At this time OD still wins. The only beef I have with OD is that you always need to increment a deploy version if the deploy script change, not the underlying package. If SEMVER includes infrastructure change and not just bug fixes, I get it. However, if my infrastructure change and I need a new release to deploy, it is exactly the same version of software.


  14. Paul Stovell closed this discussion on 14 Feb, 2017 06:37 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac