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
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.
Pros
- 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.
Cons
- 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.
We deploy to production every two weeks. We deploy nightly, often multiple times throughout the day to the QA environment. We set up Dev to be automatically deployed whenever ANY build is completed - this makes sure that no one has broken anything that keeps it from deploying. This was a HUGE issue in the past, as people would check in, break the code, and go home. Now, if they check in breaking code, someone will ping them (or the system will e-mail them) that it failed to deploy, and the problem gets corrected NOW, not when QA comes in. Our QA is in India, so if a developer breaks it before he leaves, we could have lost a FULL DAY of QA time for the ENTIRE QA Department! Octopus Deploy has made sure that won't happen. OH, and QA can deploy it themselves if they see the build is there, but someone forgot to deploy it. Or, they can deploy to another QA environment by simply clicking a button and saying Deploy - in case one is down or something. They can also easily see what environments have which builds, allowing them to know that this env has the release build - which matches what is in production. We can (and have) also locked it down so that only some people can deploy to production, which was easy to do, as well as only some people can update the variables on a release.
It has reduced the time spent by developers, and me personally, by a LOT in many ways. The runbooks made a HUGE difference. But so did the ability of Octopus Deploy to be able to be deployed by QA or even the customer (Although we have not had our customer actually do it). We also have multiple companies doing development on the project, and Octopus Deploy has been great for tracking what is deployed where and by whom.
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
Comments
Please log in to join the conversation