We used an in-house developed scripting solution for the main parts of our deployments and complemented that with error-prone manual steps accompanied by huge hard to maintain deployment manuals. We wanted to implement a Continuous Delivery methodology combined with a DevOps culture and therefor needed to speed up deployments as well as delivering better quality products to our customers. We switched because our scripting solution would not be able to deliver on those key features. Plus, we also are in the process of switching from IBM Websphere application servers on Windows to a new target platform (JBoss EAP on Linux (RHEL)). So in the long run the scripting solution which was targeted on IBM Websphere needed a lot of work, if at all it would survive.

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.

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.

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.

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.

No, but we might be switching to urban code.

Homemade solution, too complex and lacking flexibility / features.

No.