Digital.ai Deploy Reviews

The solution is for heterogeneous enterprise environments that have different workflows like Kubernetes, Linux, Windows, and mainframe.

The solution creates a manifest file that caps the bridge between the developer and the system admin.

The tool needs to improve on cloud-native GitOps.

I have been working with the solution for six years.

I would rate the tool’s stability an eight out of ten. It is good.

The tool has no scalability issues because you need to just install a separate agent as you grow.

The solution’s initial setup is simple.

The product’s pricing is acceptable. We get volume discounts.

I would rate the overall solution an eight out of ten.

Release Orchestration

Visualizing the DevOps progress

The solution's most valuable aspect is that it is vendor-agnostic and it has a file called Manifest, which makes it possible for developers, ops people, and system admins to cooperate.

The solution currently has a bug that causes performance issues. They need to resolve this in a future release.

Technical support needs to be improved.

They lost key professionals after Digital.ai acquisition 

I've been using the solution for six years.

It's relatively stable, but there are some performance issues.

The solution is easy to scale.

Our customers have not been happy with technical support. They need to do much better to help clients solve issues. The response time is much too long between finding out there's a problem and finding the solution.

I wasn't involved in the initial setup.

We use both the on-premises and cloud deployment models.

The product has a flexibility that allows it to work with various deployments and various technologies. 

I would recommend the solution for enterprise-level organizations.

I'd rate the solution eight out of ten.

We help our customers in improving their business agility by leveraging DevOps frameworks in the best possible manner driven by a continuous improvement approach. On that mission, We use XLDeploy in order to drive deployment automation for our customers. One of the best things about it helps in simplifying and speeding up deployment. In most deployment automation solutions you build deployment scripts. Either you will write a lot of scripts, or you knit your deployment plans together.

In the case of working with XL Deploy, you are not going to write as many scripts. The process has more to do with understanding what you want and then it actually generates the deployment plan and the automation that is needed for the application deployment.

It's a highly scalable solution. It's a bit different from a lot of the other tools in the market. Other tools are more workflow-based and this is a model-based deployment automation engine. It works across all major application platforms, container platforms and cloud platforms. We find it to be a very good fit for what we need to accomplish and it's very easy to manage and to maintain it from an enterprise skill perspective, as well.

I think the model-based automation itself is a marked differentiator that sets this product apart from anything else on the market. Secondly, It is also agent-less which is what we prefer as compared to an agent-based approach which increases the maintainance overhead

These are two key contributing factors to describing our primary use case.

For our organization, the speed of deployment is paramount. The speed at which we can deploy is enhanced by automation with this product and has been much faster than anything else we experimented with.

If you ever write a lot of deployment scripts and playbooks, et cetera, and you have to maintain all of this it becomes a burden. In this case, we didn't have to do as much of that maintenance. First of all, as an example, say somebody writes a script and he leaves your company in a year's time. Then somebody else looks at that script and the guy who wrote it came at it from a certain perspective and it may not be easy to interpret. It works for some cases, but in other cases, it isn't quite right. You don't exactly know what cases it was written for or what other scripts it had to be used with. There's lost knowledge of the purpose of the script because the person who wrote it is gone.

Instead, with XL Deploy this is scalable because you define your deployment package using your favourite CI tools, and you point it to a logical application-centric environment to which it needs to deployed. The rest of how it needs to get deployed and based your specified deployment pattern like blue-green, canary etc, the deployment plan  is generated by XLDeploy and the application is deployed.

We don't really spend time building scripts and maintaining scripts as part of something someone has to remember any more. XL Deploy does that for us and the deployment knowledge does not get lost. So, you actually accelerate processes of deployment and automation is much faster than with other platforms.

We don't feel the learning curve for XL Deploy is very high. For the company, this means you don't necessarily need the same level of specialist skills for a successful deployment. It is much easier for people who are new to it to learn how to use it. That has become a big element for us pushing ahead, and it has made a serious impact on the way we apply scripts and deploy applications.

Ensuring our deployment techniques are no more people dependent and scalable automation are clearly the most important to us and our business needs.

Overall the key features from which we benefited are

1. Model based deployment automation and speed of deployment

2. Agentless

3. Visibility and Insights on the Deployment process

4. Self Service deployment for our teams

5. Ensuring compliance

Though the product is very good, I think the product can still be improved in a couple of ways. For example, there are new platforms that keep being developed. I think the developers of the product can speed up to support the new platforms as they are released. Having said that, they already have a plugin framework and the guidance provided on that ensures that we can build the plugins for new platforms.

We experienced a scenario where we had to use a certain platform for which XebiaLabs didn't have a plugin for specifically. But the plugin framework they provide actually guides us through a process so we can build the plugin and apply it easily. Because of this, my team could actually build a plugin for that platform without much difficulty. 

From that perspective, the product is extensible and that makes it easier. From an enterprise perspective, which rampant change and innovation inspiring our developers to explore new platforms based on business needs, it is very helpful that XLDeploy can be extended to support the new needs.

I think you find would find it to be the best of all the similar type of products that you've seen out there. 

The stability of the product is very good. We haven't any issues with it.

I think scalability is one of the biggest factors that is a benefit of the product. What we accomplish is more-or-less independent of the people who can use the product. We don't have to pay for people with particular scripting skills. In fact, a lot of our people who got trained picked up using the product pretty quickly and they become functional using the platform without a big gap in time. Often people were ready to use it very well much earlier than what we thought it would be possible.

Some of them really picked it up the design of the product well. I have seen this in cases of people who are 60 plus years old — who have pretty much been doing something for the last 25 or 30 years in a particular way. When we introduced them to this platform, they've managed to pick it up and changed their style of doing things in a very short time. That tells us a lot about the product and its people-friendly from an adaptability perspective. When somebody has had habits of doing certain things in a certain way for so many years and they are able to adapt to this platform quickly, that makes the product very effective in speeding up velocity and scale across the enterprise.

We already have about 150 users on the solution and expect that will grow.

I find that the technical support is very, very prompt. It is worldwide support and accessible 24/7. You raise an issue to support and they respond promptly with an answer of a fix. When we have approached technical support to this point, we've never had a problem with them in terms of how they responded.

We have had experience in the past with many solutions and sometimes use them if required. 

So these tools played a part as components of a framework. Because customers have already made some choices we have to make integrations revolving around some of these tools that they chosen and invested in. It is our job to get things integrated into the value-stream and ensure that the visibility of the information and control from governance, audit and compliance perspective is simplified for our customers.

Previously we used Jenkins. So, initially, a lot of the work was scripted on Jenkins. We moved away from that solution to now use Jenkins for CI, XLRelease for CD and Release orchestration and XLDeploy for Deployment automation.

Obviously, in the initial days while in experimentation for our team, we started with open source solutions because they were essentially free and we did not have better direction as to what we needed. It was an easy way to start on things because you can experiment without any cost involved. But, when you look at the whole problem from an enterprise-scale, you've got to look at it from a different angle because a lot of the factors come into the picture. That's when you have to take a realistic look at that solution you are currently using and say, "Well, is that really going to make sense from an enterprise skill perspective?" If it doesn't make sense, then it is time to make a change.

When we looked for an enterprise-scale solution, it did not meet our requirements from a security, scalability, or from an automation capability standpoint. It was nowhere close to what  XL Deploy and XL Release provides. We decided we wanted a scalable, dynamic automation across the enterprise. We didn't find anything to be a good fit until XL Deploy and XLRelease.

The initial setup was straightforward. Once our deployments were automated, it was even easier and in a matter of minutes, we could do the deployments.

We have got only one person who looks after the maintenance at this point internally. One person and he only takes care of that part-time rather than as a full-time employee. With just a few hours he can go over everything that might be a concern.

We have deployed XLDeploy on containers. The container-based platform also helps us to manage things much more easily. 

We are a solutions partner for XebiaLabs for their product line. So, basically we provide specialist consulting, implementation services to our customers. Implemented in the right way, clients will make the most of the product and scale best practices effectively. This will maximize the benefits from CD — and overall from a DevOps perspective as well.

We save in a number of ways including spending less time on solutions, using fewer specialists and spending less time in costly training.

The licensing costs for this product are based on an annual subscription. I don't remember the cost price-point at this time and it is not my responsibility. But the ROI from the tool is huge.

I think XL Deploy is a very versatile product, and it actually makes a lot more sense than a lot of other options which are on the market. It actually helps our technical people to adapt to it much faster. You don't need a lot of specialists and technical skills. That's where I find it makes it easier for most of the teams to pick this product up pretty quickly. That, to me, has been a big factor because new users for the platform can easily adapt to it. That means you can scale this faster and more teams can be involved in using it faster. Without that, you're always stuck because of the lack of specialist skills and hampered in scaling DevOps practices effectively across the enterprise.

If you only have a budget for a few specialists and have a lot to roll out, then you have to wait for the specialists to complete work they need to do before you deploy. This makes you wait longer for anything to be deployed. That becomes a big stumbling block.

In the case of using XL Deploy, we don't face that problem anymore. The other thing that is a benefit is that we also used the other product, XL Release, which helps to orchestrate the Continuous Delivery and Release journey. It simplifies the DevOps journey and makes visibility, control, governance, audit, compliance much easier.

On a scale from one to ten where one is the worst and ten is the best, I would rate this product a nine. There's always room to make a product better. 

XLDeploy has excellent dependency management for application deployment, We would like that capability extended to a more visual manner making it easier for teams to understand their dependencies.

- The product sounds good thanks to its UI, as it is really easy to perform a deployment... when things work.

- Product just works when you're with a pure JEE solution (Tomcat or Weblogic), with a well written app that can be shutdown and restarted properly, and a reliable database.

No more need to write a 40-page handbook to perform a deployment.

- Make the product an open box, i.e. as a user I must be able to see exactly which commands the system sends to the server so that I could reproduce them myself on the server.

- Be able to perform a reinstall of a package (notably if the server has a hardware failure and needs to be replaced). This seems to have been fixed in later versions.

- Use platform native packaging format instead of a native one

- The basic design is broken, as it computes diffs to perform updates. This works well for SQL but this is the only area where it works well. Any other install program has phases where it lets you do the thing you want and it simply execute these phases.

- Inconsistencies in the UI. For example adding a user is only possible through the CLI, not the UI.

- The fact that the system relies a lot on plugins, and that plugin backward compatibility is not ensured at all. So actually users may have to redesign all the DARs on each version upgrade (for example from 3.8.x to 3.9.x) which is just catastrophic.

6 months

- Quite many due to buggy plugins and poor docs. For example the command line plugin does not work properly if you need to perform a command on each deployment (due to the broken design explained before). So you need to use an alternate plugin to do so.

- Documentation is quite poor and misleading, especially there's no way to know the plugin read-only properties, which is extremely annoying.

- The fact that the system might not be sync between XLDeploy database, and the real server state. And when this occurs, this can be quite hard to recover. Thus the fact that there's no server agent on each server can be misleading to the teams in charge of maintaining the servers.

- (Not encountered in real world but in the study case): unable to reinstall a package, but also unable to remove it. So you're stuck.

Yes: single point of failure problem. If for any reason your DeployIt server fails you cannot deploy anymore. As the product is not designed with load balancing in mind on so on, it makes the server rebuild quite hard. Thus the fact that the packaging format is proprietary prevents users to perform deployments out of DeployIt.

They're quite long to answer on their forums. Did not phone them.

Yes, RPM. I switched because it was a customer requirement (I was a contractor). Then I switched back again to RPM in another customer and I feel much happier with it.

In-house one.

I'd advice anyone who considers using this solution to switch to native platform packaging format instead (i.e. deb for Debian, msi for Windows, ...). This kind of solution is good when you wish to have a centralized way to perform your deployments. Now it should actually be more something which asks the servers to which versions of the packages we are so that users can deploy packages manually when the system is off.

You can follow the delivering process of deployment. When an error occurs, you know which step is involved. Error messages are sometimes not enough clear to solve the issue. But if you work with a sand box environment before using your real environment, it should be ok.

The main quality is still to have a "One Click" process, then you save precious time.

Unlike other colleagues, I'm able to speed up the delivering process. I use DeployIT with WebLogic and Tomcat servers. Everything is fine set up just in two minutes. Even in 2014, we can easily find people who copy manually their own packages directly to production environment! It's completely incredible.

The GUI deserves some improvements. Adding new dictionary values may be laborious but hopefully, the frequency of this action is low.

The Flash user interface which has some bugs (I heard an HTML 5 version is in progress).

Just several weeks. It corresponds to the required time to start from scratch and have a full process to deliver your packages in production. I work only on Java projects with Maven.

When you start to use a new product (whatever the product is), you have to understand subtleties, read the documentation and test by yourself. Nobody is perfect.
Two main issues I get:

1. The Maven dependency 3.9.1 is bugged for DAR packaging. Sending DARs into the DeployIT server with this version is hazardous. Upgrading the version to 3.9.4 solved the problem.
2. You can have false-positives steps during your deployment. For example, the step which stop the WebLogic server is green, but when you click into details, you see a stack trace error. So, you don't have to be too trustful with the software.

In cluster mode with WebLogic server, nodes are not properly restarted each time you run your DeployIT process. Working with an administrator is highly recommended.

Never used.

Never used.

I'm working in a huge bank. DeloytIT is a standard. Previously, I worked with Jenkins and plug-ins. But it was some years ago.

Neither simple, nor complex. If you can work with someone who did it previously, it would be great. Then you will work with good methods. Once you get the concept, you speed up your deployments.

A specific in-house team is present where I work. It's not a huge team, but has skilled people. They use DeployIT almost every day.

It's difficult enough to talk about it because I'm never involved in this, but it's very short.

DeployIT is a group solution. Personally, I would like to test others software like Thougthworks GO.

Set up a secured server with separate profiles. It sounds obvious, but by this way you have a segregation between business teams. Having four environments is recommended: sand box, development, pre-production and production. Sand box is used to test unitary your DAR package. When it's done, you can use a unique project to assemble all the others DARs.

The integration in the cycle of a project build and the facilities to integrate with Maven.

For a "from scratch" project, the build pipeline is very easy to create : Jenkins for the continuous integration platform and deployIt for "push" the artefact onto our servers.

Simplification of the pre-production and production installation.

XebiaLabs made some custom plugins for us. So, there are some issues with these plugins.

I used deployIt for 6 months 

Yes, a little.

Not very good.

I used "cargo" plugin for jboss but the scope is smaller than deployIt. deployIt is compatible with Windows and Linux OS, and with a lot of java J2EE containers.

Very complex in my customer environment.

1. Dictionary

2. UI

3. Maven Plugin

4. Integration with different servers like Jboss, tomcat.

Jenkins deployment was hard to maintain different environments, different variables, Machines etc. Now we have it all under one roof.

RollBack, Logging, documentations, support, forums, and blogs.

2 Years.

General configuration issues.

No issues with stability.

Less documentation.

3/10.

3/10.

No, but we might be switching to urban code.

Complex, New tool, new technology.

Vendor, 8.

I don't know.

Urbancode

Make sure it works with cloud integration, and you have proper technical support.

For us the flexibility of this product is nice, we can manage several things within one file and by giving parameters to the deployables. So it is very useful to implement it on several machines in different network segments.

Some deployables have to be built, it is not quite difficult but not every product is supported by one standard. It is open source, so it is easy to build your own portals.

I started to use it last year in a proof of concept.

Some deployables have to be built, it is not quite difficult but not every product is supported by one standard. It is open source, so it is easy to build your own portals.

Stability is fine, performance with a lot of systems, you have to manage the time for refresh with puppet, for xldeploy, the deployments are done after pushing the button. Deployments could be somewhat faster in selecting the environment, but much faster than deploying by hand.

This is our first solution in this case and we are happy with the support of the supplier and with the knowledge on the internet and people whom share products on a blog.

The solution we decided to use is complex; we had several systems which we would implement, so we started with 4 different kind of deployables.

We implemented it in-house and had 3 consultants for several weeks in-house for implementation working together with us.

For us the ROI is not that interesting, the prediction is much more interesting; we are using a lot of environments,11 development and 13 test environments which we would implement with the same settings to be predictable for the implementation of projects.

We had looked for several other solutions but for unix/linux environments which we are using this product has more opportunities as landesk or something.

Controlled / automated way to deploy application releases.

Shorter time to market, more agile in deploying newly created business value.

Documentation / initial setup / learning curve.

No issues with deployment.

No issues with stability.

We encountered no problems with scalability.

Customer support is excellent, quick response from product specialists.

Excellent.

Homemade solution, too complex and lacking flexibility / features.

It was straightforward.

In-house, but a vendor team could have expedited the initial setup.

No, the product was already used in another business unit.

This is just a technical tool, take time to redesign processes too.

Automatic deployments using packages build using TFS and the way it assembles the configuration settings for us.

Quicker and more solid installations.

I’d like better reporting possibilities.

About over a year by now.

No.

Once, when to many deployments were running.

Once, when to many deployments were running.

A 7 on a scale from 1-10.

A 7 on a scale from 1-10.

No.

Straightforward.

Vendor team, 7/10.

Yes, don’t know what they checked back then.

Compare and choose the product that fits your needs, if you implement this product, draw the implementation in the tool first and note your needs. As you may need other plugins then default are delivered, it is possible to create your own. But then you do need the programming knowledge.