UrbanCode Deploy Reviews

The valuable features are “scriptability” and customizing the deployment processes.

It’s not necessarily the product, but more the drive to automate deployment that results in improvements.

UCD gives the freedom to create reusable component templates. You set up a process for deploying something once, such as a standalone Java application, and then that is “templetized” and can be reused.

In these templates, you can:

• Standardize the used repositories, such as Nexus
• Standardize how an install.sh script must be made
• Determine how staging parameters must be stored in a config file.

Many of the improvements are, therefore, based around automating the deployments. They are automated in such a way that no more "screwdrivers under the hood" are allowed in any stage.

This saves time, and makes the process much more reliable, reversible, repeatable, and traceable. In the beginning, this is painful. I can’t stress enough how much effort should go into getting this right.

WebSphere deployments, for some reason, don’t work out-of-the-box. We have worked on the Websphere issue with the IBM uDeploy development team a lot more now. What we want to be able to do is apply configurations to the Websphere using the standard plugin. This can be done by creating json snippets that must be parsed with the large json files of the cell, the node and the server that have been created during the mandatory initial configuration discovery of the target machine. We have had lots of difficulties getting the parsing to work, now a new version of the config plugin has been released which is an improvement. 

However, what we want to be able to do with our CICD automation is to create configurations paired with the EAR files so that we can start doing partial updates, of only the parts that have changed. Also rollbacks will this way be much easier to accomplish. uDeploy can not work like this to date, the plugins do not allow it.

UCD needs to perform a discovery of the environment. This would not be needed if it would understand more about WebSphere environments and releases.

We have used this solution for one year.

In terms of deployment for WebSphere, the configure plugin didn’t do what we wanted. The plugin requires a discovery of the target WebSphere environment. For some reason, applying changed configurations via the plugin doesn’t work for us.

In itself, UCD is a stable tool. Once something works, it continues to work.

I would give customer support a rating of 6/10. The customer is expected to bring a significant amount of knowledge to be able to configure component templates, resource tree, etc.

Customer support is available, but it is remote and only acts upon raised incidents. At our own cost, we have hired IBM specialists on premise to solve the WebSphere issue.

We didn’t have a previous solution. This was our first real attempt to introduce one central deployment tool to automate and standardize deployment processes for all techniques, such as Linux, IIB, IIS, and WebSphere.

We chose the product because we have a long-lasting relationship with IBM.

Initial setup was done on only one environment. Even then, UCD has a quite complex setup due to a needed high-available setup with load balancers, queue managers, license servers, and databases.

Depending on the size and complexity of the organization, you need at least three environments:

• To develop and test new versions of UCD
• To build reusable deployment solutions
• To execute them

IBM did the implementation. Unfortunately, they did it without considering that deployment automation is not just about a tool, but much more about standardizing and optimizing the deployment landscape and the processes.

It was done as a remote implementation, which of course didn’t fit. It had to be changed in numerous ways.

I have no knowledge on the ROI. In the end, I think the costs must be seen in the light of the objective you want to achieve. If you’re considering release management, CICD processes, and want to be a DevOps organization, then the costs for the tool don’t matter much.

Think about what deployment automation really is. It means no tweaking throughout the stages whilst applying changes. Everything must be code. That is the most important step; having everything as code.

Once that is done, then probably all of the good deployment tools in the upper-right corner can do the job.

In the end, deployment should be something that runs in the background; getting a signal to deploy something that has been created.

Ability to do automated deployments. It does what it promises: It helps you automate deployments. But, it works better for some application component types than for others.

Automated deployment forces the organization to standardize runtimes, development output and handling of platform provisioning.

They could add support for some of IBM’s own middleware. IBM is so big a company that the left hand doesn’t understand the right hand.

I’ve been using UrbanCode Deploy for too long.

We have not had stability issues.

We have not had scalability issues.

Technical support is bad.

We had various solutions before this one.

Setup was complex because IBM started on the wrong foot.

Don't use the tool in combination with IBM as datacentre manager.

We didn’t evaluate other tools. We were forced to use it by IBM as datacentre manager.

Look for other tools if IBM runs your datacentre.

It provides a wide list of OOTB plugins for middleware.

By standardizing the automated deployment application process, reducing the amount of errors due to manual steps and by providing visibility into the release cycles of various teams/applications, we've improved our global efficiency by at least 25% and still counting, since we've only used the product for a short period of time.

• A simplified UI
• A simplied licensing model
• Lack of technical expertise available in the market that forces us to rely solely on IBM Professional Services

I have used UrbanCode Deploy for six months.

We have not had any stability issues so far.

We have not had any scalability issues so far.

They have very good response time to our technical support tickets. The solution/answer that allows us to close the ticket typically comes from level 2 or level 3 support (i.e., not level 1).

We didn’t have a previous solution. We just had a very wide variety of custom in-house scripts.

Initial setup was straightforward.

The licensing model can be very simple, or quite complex, depending on how you want it to be and how you negotiate with IBM. I suggest to deeply evaluate your growth/scaling capacity, since this will dictate your choice of licensing model. If you know that your needs in terms of applications to automate is fairly stable and very predictable, then you might consider a simple approach of the server and agent licensing model. If you're in a rapidly evolving environment and it's hard to predict, but you know that it will grow rapidly, then you might consider a PVU licensing model based on the CPU capacity of the server, regardless on the number of agents deployed into your datacenter(s). And somewhere in between, the hybrid approach is the floating model that is a good fit for the shrink-and-expand type scenario (our choice).

It all depends on your requirements and the guesstimate of growth and potential shrink capacity.

We continued with custom in-house scripting; a dead end, obsolete approach that cannot scale and belongs to the past, not the future. Open source-based products (Jenkins and others) that we complement with in-house custom functions, require too much human investment in development effort to provide minimum features that make solutions properly operational in large-scale enterprises with complex IT landscapes; a buy vs. build decision.

Its competitors are: Xebia Labs, CA Release Automation.

Properly evaluate the ratio of applications that are based on newer architecture models (cloud native vs hybrid vs traditional). Weigh in that element into the decision and consider a hybrid approach: big vendors' ARA tools vs. new cloud-based deployment technology like Kubernetes.

The most valuable feature is auto-deployment of application versions through direct connectivity with UrbanCode Deploy.

Previously, for a planned release, an Excel-based implementation plan had to be created and validated beforehand in a production-like environment. On the go-live date, a high number of resources were required to run that implementation plan and perform a high number of deployments and validations. This eventually takes almost a day for a release leading to business impact and high release cost. The Excel implementation plan size climbs to 2000+ lines depending on the size of the release, which is prone to errors.

UrbanCode Release is used to run deployment from non-production environments and hence the plan continues to mature until we reach the go-live day. It is run through the non-production releases a number of times and hence is validated beforehand. With the usage of UrbanCode Release, we are able to save on efforts required to create a detailed, accurate implementation plan. Also, as it has direct connectivity with UrbanCode Deploy, we can schedule automatic deployments and hence save on time and cost of resources. The overall release efficiency has improved multifold.

Performance of the tool is quite slow. It takes a lot of time to load a plan if the plan size is bigger. Also, the reporting feature needs to be strengthened to provide more valuable real-time reports.

I’ve used UrbanCode for 1.5 years.

Sometimes the tool gets hung while running a plan. Also, sometimes the deployment status is not accurate with regard to UrbanCode Deploy.

The tool's performance goes down when the number of simultaneous users increases.

Technical support for us is good as we are one of the initial big customers for this tool. The tool has developed in consultancy with us.

We were completely manual before this.

Initial setup was complex, as providing user privileges, environment-application mapping, and environment release allocation are some of the pre-install tasks to be completed for creating a plan. Creating a long plan is also complex.

Pricing is on the higher side. Individual licenses for each user is not an expected model for a tool like UrbanCode Release. It should have group licensing.

We evaluated Nolio by CA for release management.

It’s a must have. UrbanCode Deploy provides great advantages.

Gates is one interesting feature, which will help approvers provide their approvals in advance, without having to rely on when deployment happens.

It has helped developers manage and deploy their own applications.

The Archiving policy is something which should be looked at.

The resource tree is pretty bulky and slow. Making a change to the resource tree manually is pretty difficult when size increases.

I have been using it for more than six years.

Sometimes logs were not returned back and answers were not found, but still re-executing them worked fine.

Also, when the application history grows and resource tags with component tags are used, actual deployment take-off occurs much later than when you start the deployment.

I have not encountered any stability issues, as such, in 6.1

I have encountered scalability; the artifact's clean-up policy is not efficient, so it takes up a huge amount of storage.

Also, when you have a large number of components in the same application, the deployment take-off is very slow. I assume it fetches the current inventory and compares it against the requested version.

Customer service is good, as opposed to earlier products where recreating the problem on the IBM side used to take days.

Support is great, I would say. They are very reachable, collaboratively connect and help solve the problem

We had home-grown solutions different for different applications. We have standardized by adopting this solution.

Initial setup was not that complex, but you need to work on integrating this with your company standards, and tools and policies supported.

Implementation started initially with vendor support but post that, it was done on our own. This was when there were only a few members at the company when we started in 2010. So, not much documentation and help was available.

ROI is difficult to explain but it's provided huge savings.

It is a bit costly but good ARA tools are not free, and this has competitive pricing.

Before we chose this solution, we evaluated other options.

It is a good tool to use if you have a substantially big enterprise.

It has out-of-the-box integration with source-code repositories, various ticketing systems, plus a wide variety of plugins to use during deployment. Custom plugin development was easy and the tools capability of keeping the version tracking of workflows were pretty good.

It provided a reduction in deployment time and lowered the application downtime.

More out of the box plugins are required though good number are avaialble at the moment.

I've used it for one-and-a-half years. The sole purpose of the tool was to pick the application binaries from various sources and deploy them on target systems.

There were some issues related to high memory consumption, but those were primarily due to the deployment workflows being developed incorrectly.

There were no issues with the stability.

The tool is capable of handling the load. The single application server was handling 50-70 applications which were quite complex in nature.

7/10

7/10

We used BMC BladeLogic previously. BladeLogic is more for automating tasks performed on servers like compliance, patching, and provisioning. It is not suited for devops/application deployment and hence the migration from BMC to IBM.

It was fairly simple as the product is easy to install.

We did it in-house with failover.

For us, it was more about automating the complex application deployments which were manual for years. IBM products are expensive unless you can strike a deal. However, the tool did help us in automating the use cases and integrate with existing platforms via plugins.

We explored Ansible, Puppet and Chef. I worked on Chef for a few days and I am not a very big fan of it, probably due to my lack of interest.

For DevOps, this tool is one of the best with all its integration capabilities for repositories and various systems. Perform the initial setup carefully, and probably with someone who has knowledge on the tool plus enough experience of designing infrastructure solutions. For me, the pain starts due to mostly incorrectly designed/implemented tools.

It has flexible deployment options, allowing us to model our components as we want and need, which is the most valuable feature we've found from our experience with it.

It reduced more than 70% of our manual effort when it automated deployment of both UNIX and Windows-based applications using UrbanCode Deploy. We used plugins available in the plugin center and used UNIX shell and powershell scripts to automate completely.

More plugins are required. There are also many bugs in UrbanCode Deploy. Finally, database deployment and rollback of databases needs to be worked on.

I've used it for one year two months.

It does not support variable changes and utilizations while executing the application. We were setting the variable values in the application process and using it in the same process, but apparently that's not supported.

There have been no issues with the stability.

We have had no issues scaling it.

Technical support is very good.

Refer to the IBM Learning Center as that will help with the setup

We used a vendor team for our implementation.

Rundeck is also a good option, but UrbanCode Deploy provides more features and is easier to use.

Before buying this, try the trial version and check if it serves your purpose.

• Rich plugins
• Visualized process design
• Visualized approval process

It has automated the deployment of tasks to different environments which we were previously only able to do manually.

They need to reduce the footprint and improve the performance of UD agent. If the agent runs for too long it can cause a memory issue on the production server. We must keep the agent offline and only enable them during deployment.

We've used it for three years.

There have been no issues with the deployment.

There was no issues with the stability of UD agent.

We have had no issues scaling it for our needs.

In my experience, I'd say that technical support has been good so far.

The initial setup is easy and straightforward.

We implemented it with our in-house team.

We compared UrbanCode Deploy with XebiaLabs XL. We chose UCD because of the process design function.

The product became more complex after IBM acquired it.