Software Configuration Specialist at a insurance company with 10,001+ employees
Real User
Top 10
May 16, 2025
My use case for Digital.ai Release is that I work for an insurance company on a very big project that develops multiple different pieces of software. We use Digital.ai Release to move our software from dev to test, to pre-production. I create release packages, installing different artifacts all at the same time, doing handoff approvals, and it sends emails and Teams messages. It interacts with Jira, logging Jiras for auditing purposes and all those kinds of things.
It helps with creating documentation, release processes, deploying to lower environments, scheduling meetings, and sending emails to stakeholders. The goal is to reduce manual work and save time.
DevOps Tech Lead at a financial services firm with 5,001-10,000 employees
Real User
Dec 15, 2022
Our company uses the solution to handle deployments for new releases. Whenever there is a new release, the solution creates a new provision template for deployment. We also orchestrate and manage all users. We integrate with other tools like GitHub, Jenkins, or Digital.ai Deploy to manage processing or deployments. We currently have 160 users with no plans to increase capacity in the next year.
Senior, Workload Automation Analyst at a government with 501-1,000 employees
Real User
Nov 19, 2020
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.
Automate, orchestrate, and gain visibility into your release pipelines at scale using Digital.ai Release, a release management tool that is designed for enterprises. Control and track releases, standardize processes, and bake compliance and security into your software release pipelines.
My use case for Digital.ai Release is that I work for an insurance company on a very big project that develops multiple different pieces of software. We use Digital.ai Release to move our software from dev to test, to pre-production. I create release packages, installing different artifacts all at the same time, doing handoff approvals, and it sends emails and Teams messages. It interacts with Jira, logging Jiras for auditing purposes and all those kinds of things.
It helps with creating documentation, release processes, deploying to lower environments, scheduling meetings, and sending emails to stakeholders. The goal is to reduce manual work and save time.
Our company uses the solution to handle deployments for new releases. Whenever there is a new release, the solution creates a new provision template for deployment. We also orchestrate and manage all users. We integrate with other tools like GitHub, Jenkins, or Digital.ai Deploy to manage processing or deployments. We currently have 160 users with no plans to increase capacity in the next year.
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.