Used it for 4 Years, Excellent, Easy to learn, Easy to Manage/Maintain
October 18, 2021

Used it for 4 Years, Excellent, Easy to learn, Easy to Manage/Maintain

Chert Pellett | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User

Overall Satisfaction with Octopus Deploy

At a previous company, someone outside of the company recommended Octopus Deploy (and Team City), and I recommended that to my manager. However, they decided to go with TFS, in spite of the huge cost, partially because they had credits with Microsoft that they could use to configure it. The Microsoft person didn't help much. We ended up with a horrible mess that was all broken in terms of the configuration - they could turn off someone's access, but the person could turn it back on, people could do things they shouldn't be able to do, permissions were hard to figure out, configuration to get it to build and deploy was painful, overall it was a disaster. Fast Forward, I started at my current company, and they used Team City and Octopus Deploy already (on Prem install of both). This worked out fantastic. We deployed eight machines at once. It was easy to get the deployments configured, super simple to set up the variables needed, and very, very easy to see what was deployed where. It took me very little time to spin up a new environment. This is currently being used in the cloud version - [for] which we have a paid license for. Speaking of which, awesome license system! 100% functionality up to 10 deployment targets, then a reasonable price per each.
  • Per Environment Configuration, 5 Stars. Unlike ADO, you can set a var to a specific environment while still having another one apply to everything else.
  • Rapid deployment compared to ADO.
  • Easy to set up a new tentacle. The tentacles (deployment targets) can be upgraded with one click.
  • Easy access control, easier with the stand-alone version (single step), but not bad with the cloud. Just add a member (invite), wait for them to accept, and then add them to the team you want. Create whatever teams with whatever permissions you need.
  • Support - An example: We are in a meeting discussing License costs at 10 Am Central time US. I'm pretty sure of the terms, but they want me to confirm with Octopus. I sent the e-mail [at] about 10:05, I got a response DURING the meeting, about 10 minutes later, with everything we needed. Any time I had an issue, I got a quick response, and they told me what I was doing wrong or how to fix it. Super, super responsive, and they also take your suggestions and improve the product.
  • Runbooks - Clean and easy to do. I have to try to make them work as well in ADO, and well, yeah, I'll take Octopus Deploy any day. Their runbooks have saved us TONS of time, avoided errors, and opened up what I do to everyone else without using my time.
  • At one point, they didn't have runbooks, I suggested it (and I guess others did too), and now they do.
  • I would like to be able to edit a process and then run it without having to do a new build/release. This is something that I've suggested to them, and they are considering implementing. It can be hard to develop the scripts if you have to do a ton of iterations to get them right - At least, if [your] build time is long AND your process is one that you can't deploy the same release over the same release (like one of ours). We are using Octopus Deploy for about eight projects right now.
  • I believe they are working on their ISO 27001 certification and don't have it yet. This is something that CSG mandates to keep things secure.
  • Reduced the amount of time that I personally spent (Architect) doing things that required a high level of expertise. I am no longer asked to, for example, do a backup of [the] production server and restore it to a lower environment. That is the following process: Click on Runbook, Click on Copy Prod > Env's Run button, select Environment, click "OK' and DONE.
  • Reduced chance of Error on our process - we had a process before where I was one of the few people (almost always the only person) who would do a backup of the production server and restore it back to a Dev/Qa environment, and then apply a process to cleanse the data and set up test users. Now, this is a simple process.
  • Reduced time we spent during our bi-weekly deployments. The process is super quick compared to what a manual process would be.
  • Reduced time it takes to add a configuration variable to the system. You add it to the config file, use it in the program, add it to Octopus Deploy (which has a step to auto-patch the Config file - even the OLD ones (we have a VB.Net App) - ADO lacks this step, so I had to write my own script to do the patch. You can see in one place the variable and all the values/environments that it applies to. If you leave the environment blank, it applies to all of them that don't have an environment selected (And unlike ADO, you can list all 5 QA environments on ONE variable if they are all the same, instead of listing all 15 environments because two of them are different from the rest).
  • Project Spin-up is quicker with Octopus Deploy.
  • Creating a runbook to do an automated task has saved us countless hours/money.
  • We can even give this to our customers and have them be able to see what is in what environment, when it was deployed, or what runbooks got run when.
I used TFS back when it was called that, and that was a mess. ADO isn't as bad but has many limitations and things that are hard to do. The main difference is I ENJOY working in Octopus Deploy. Not so much with ADO. I'm always trying to figure out things that are stupid. For example, in ADO, if you use the 'System.StageName' for a stage name, say 'QA.' What would you expect that to return? If you said QAAB87873284126123D723AB54D, Then hats off to you! I would have guessed 'QA,' but no, that is System.EnvironmentName, even though we have no Environments defined in ADO. Yep, Quite clear names. (Might be a bit off on the exact variable names, I think it is a 3 part name in ADO, but you get the idea.) I have also used multiple homegrown deployment systems at different companies, and Octopus Deploy is the cleanest system that I've seen.

Do you think Octopus Deploy delivers good value for the price?

Yes

Are you happy with Octopus Deploy's feature set?

Yes

Did Octopus Deploy live up to sales and marketing promises?

Yes

Did implementation of Octopus Deploy go as expected?

Yes

Would you buy Octopus Deploy again?

Yes

Azure DevOps Server (formerly Team Foundation Server)
If you have an application that deploys to a website, this works quite well. (Just don't have more than one tentacle running on the same machine and deploying websites there - there isn't any sensible reason to do that anyway - but we had it set up that way for a while since changing that it worked perfectly. If you need to deploy a Windows application to a bunch of machines, this is awesome, you can add a machine in a few minutes, and it is done. You can easily see all the machines that it is deploying to; they run in parallel, so that is great. One where it might be bad [is] when I worked at Robot Entertainment, we needed to deploy to 25,000 machines at once. Based on the pricing model, this would be bad, plus I'm not sure how well it would handle easily figuring out what was deploying and where. In our case, I took a program that was started for that and rewrote it to deploy to all the machines at once - so we rolled our own. However, it was a very specific use case that isn't likely you would need unless you were developing a League of Legends type app.