What is most valuable?
- 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.
How has it helped my organization?
No more need to write a 40-page handbook to perform a deployment.
What needs 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.
For how long have I used the solution?
What was my experience with deployment of the solution?
- 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.
What do I think about the stability of the solution?
- (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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
They're quite long to answer on their forums. Did not phone them.
Which solution did I use previously and why did I switch?
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.
What about the implementation team?
What other advice do I have?
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.