Release Primary Use Case

Senior, Workload Automation Analyst at a government with 501-1,000 employees
We tested it, but in the end, we didn't purchase it. We were using it to orchestrate our releases. We wanted to use it for deployment, builds, backfilling, etc. We were having a hard time determining who would be the practitioners of the product. In the end, one of the things that drove the cost up was the need for so many people to be able to use the tool. There was probably a little learning curve with some of them, but predominantly, our technical leads and perhaps some senior developers were going to use this solution — also, on the infrastructure side, the DevOps team, too. Someone's got to build the release, so the infrastructure DevOps has to set the environment, and then the leads and the senior developers can build the release and supply all the build information to go with it. We're evolving quite substantially at the moment. Right now, we're probably doing some releases a couple of times a week and we're also moving into some microservices. That probably would have increased our usage with this solution to some degree. View full review »
Find out what your peers are saying about, Jenkins, Atlassian and others in Build Automation. Updated: January 2021.
455,962 professionals have used our research since 2012.