XebiaLabs XL Deploy Review

Product that looks fancy, but real black box


Valuable Features

- 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.

Improvements to My Organization

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

Room for Improvement

- 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.

Use of Solution

6 months

Deployment Issues

- 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.

Stability Issues

- (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.

Scalability Issues

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.

Customer Service and Technical Support

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

Previous Solutions

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.

Implementation Team

In-house one.

Other Advice

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
7 visitors found this review helpful
3 Comments
Principal DevOps ConsultantVendor

The assessment is candid and straightforward; and you can tell it comes from lots of real-world experience.

10 June 15
Java/JEE Consultant with 51-200 employeesConsultantPOPULAR

Hi,

Actually if you read some devops reference book just like Continuous Delivery they strongly suggest to use the target system native facility, which XLDeploy won't. On the contrary each time I used the target system native installation way (ok on Windows things get more complicated since they did not provide MSI out of the box but after several iterations) all the integration went smoothly. Native installations (RPM, DEB, ...) coupled with tools like Ansible to send the same command to dozens of target servers plus some tools like Puppet for config file templating give great results.

Now the main problem of XLDeploy apart from that is that it tries to remain too high level with its black-box plugins, so it means that you'll often require to tear the tool in order to do what you need. Actually if XLDeploy were just a unified console which then delegates the installation to each OS native tools this would be much much better, so that deployments can continue without XLDeploy if necessary, and the product it there to give you a convenient supervision tool and automated installation tool. Don't forget that good tools will never try to lock you up in proprietary formats, on the contrary they'll make you feel free... so that when you try other tools you come back to the first one as it is the best.

Rgds

12 July 15
Vice President, Sr. Architect at a financial services firm with 1,001-5,000 employeesReal User

Hi Julien ,
We are evaluating XLDeploy as a continuous delivery tool for a container as well as a tranditional VM platform. As part of continuous delivery we want on demand env provisioning as well. We have IaaS APIs that are offered by our platform team to provision nodes by passing the necessary CPU, Storage and memory as parameters to the API. Underneath the API our platform team uses Ansible playbooks to provision the infra resources. They also provide an API interface to describe the application domain model in terms of the configuration of the app at the app, middleware and infrastructure level and a model to also describe the env ( dev, test,Qa and prod) on which to deploy the app.

My question is will XLDeploy work for us if we have to use our own domain model and have XLdepoy call the rest API to provision the env for the app first by requesting the node on which to deploy the container and traditional app by passing the app name and env name as parameters and then by actually calling the API that actually deploys the app using Jenkins or another deploy tool of our choice?

Please let me know.
Thanks in advance for your response
Rajesh

29 November 16
Guest

Sign Up with Email