Overall Satisfaction with Octopus Deploy
We aim to have a light-weight and flexible deploy pipeline since we are a small startup. Octopus gives us a good deployment tool that isn't overly complicated. We use it to manage our deployment for all of our products. These include ASP.Net deployed to AWS EC2 hosts, Angular webapp deployed to EC2 hosts, published installers for desktop apps, and scripts to deploy new versions of ECS hosts. (Our builds are handled by Team City which integrates with Octopus nicely)
- Integrates well with various platforms
- Allows customization of deployment process, manual deploys, and redeploys
- Allows flexible deployment process definition and scripting
- UI is very fluffy and padded. It looks pretty but it could benefit from a more compact, information-focused design
- Deployment process options are not always laid out in an intuitive manner. Choosing which steps to exclude, which environments or targets to deploy to, etc., is not immediately clear
- Lack of useful reports and metrics for tracking active deployments and historical data
- Allows us to deploy to our fleet quickly and without interruption to service
- Can roll back to previous releases quickly, allowing us to back out of breaking changes in the worst-case scenarios.
- Integration with several targets has allowed us to explore new platforms for our products, such as Docker in AWS ECS.
Octopus has a longer initial loading time than expected, but that is partially due to the resources we give it. It can be problematic in a crisis situation, but other than initial load, it performs adequately.
- The ability to manage different stages and define a workflow is very useful for ops troubleshooting as well as deployment. You can see which version each environment has for each project, and promote or redeploy versions.
- You can view deployment logs and dig deep into problems or long deployment steps.
- Finding old releases can be a pain, and there isn't a good way to compare releases.
- It does not really lend itself well to viewing what the content of a release is further than the version number. Ideally, you would be able to tie a deployment to the builds from the build server as well as specific commits from source control.