- 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
- 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.
Customer Service and Technical Support
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.
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.
Jun 01 2015