Digital.ai Release Reviews

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.

The features I find most valuable in Digital.ai Release are the integration with MS Teams, because we have MS Teams channels that publish or push notifications to that. When we start deployments, it sends a notification to the people that we are doing a deployment to their environment. It notifies them when the deployment is started, completed, or if attention is required.

I also appreciate the fact that it has plugins for Bamboo and I use lots of Gradle and JSON scripts, and we do SQL upgrades as well, triggering Flyway scripts via Bamboo, along with the integration with XLD and Jira; it's all Atlassian software.

Regarding environment management capabilities, Digital.ai Release is mostly useful for me, as it is more application related and that is managed via my XLD dictionary. We have one artifact that is environment agnostic, which has placeholders that correspond to my XLD keys and values, and at deployment time, it substitutes the placeholders with those environment specific values. We don't need to make a specific deployment artifact for dev, test, or production; it is all the same artifact using environment variables, ensuring what we take to production is what was tested.

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. 

The solution can apply one template across multiple applications for email approvals or orchestrations. 

The load time is good and can handle anything we are doing. 

Our organization utilizes Digital.ai Release to manage and coordinate the releases of our large integrated system, which includes SQL database upgrades, web application servers, Windows servers, and IIS web services. Digital.ai Release is responsible for orchestrating these releases as they progress from development and testing, through pre-production and eventually to production.

Previously to using Digital.ai Release, we only did one development build per day and manual deployments. However, now we are using Git software repositories with branching to do around 30 feature builds and three dev builds per day. This has significantly reduced the amount of manual work and the potential for human error in configuration, as each environment has its own unique configurations. The daily deployments to test have also been made much more efficient.

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.

We start by creating documentation for all these tasks. Initially, this includes all the details of the artifacts and the database. Then, the developer updates these details. 

We perform the deployments using Digital.ai Release. What we do is input the artifact information, and it handles all the deployments in the lower environments, usually within a minute or up to five minutes. 

This way, we avoid the need to use Jenkins to locate the artifacts and then deploy them, which would take much more time. Here, we simply input all the artifact details once, and later, we only need to update the artifact version for deployment. This significantly reduces our time. 

Moreover, once the deployment is completed, Digital.ai Release automatically sends an email notification stating that the deployment is complete, and we can begin testing. So, that's how it works efficiently for us.

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. 

The orchestration from our perspective was nice because right now, we're having to manually launch deployment jobs out of Jenkins. The orchestration, building the release, and then just executing it and managing that pipeline — the orchestration capabilities are great for that.

It had the built-in metrics that we did use in selling to the executives. The metrics were good. It retained build-information so we didn't have to go back through it and dig out some old records to figure out what we've done — that was a really nice feature. 

From my perspective, I don't know about the entire team, just automating the backfill off of the production deployment was one benefit.