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.

There are several most valuable features for us.

1. Automation of deployment processes for all our projects;
2. It's user-friendly enough for our development team to access and use on a daily basis; and
3. The lead approval process is one of the unique features in it that can't be found in any other automation tool.

It's improved our organization's functions in a few ways.

1. It has automated the manual deployment process for all Java, .NET, and C++ applications;
2. It makes is easy to track production releases with date and time; and
3. It's gotten rid of the manual errors for deployment that occurred from manual testing.

I think that the IBM support team needs to be more proactive in their responses to PMR tickets raised by customers. Also, the plugins for ServiceNow Integration need to be updated.

I've used it for three years.

We've haven't encountered any issues with deployment.

We haven't experienced any issues of instability.

We've been able to scale sufficiently.

I'd rate customer service at a 5 out of 10.

I'd rate technical support at a 6 out of 10.

We previously used IBM Rational Build Forge and then migrated to UrbanCode Deploy, which has more flexibility and process-oriented features.

The initial setup was pretty straightforward with the installation of agents and clients. The configuration process and specific jobs are dependent on the complexity of your application or project.

Our client's in-house team helped with the implementation, and they had an expertise of about an 8 out of 10.

I can't say exactly what our ROI is, but as we're in the insurance sector, I know that this is a cost-efficient tool.

It's available at a very reasonable price.

We evaluated OpenStack and Amazon Web Services.

It's best to do a POC on the applications you're currently running to check the feasibility of using UrbanCode Deploy.

• Automatic detection of new builds (via an agent on Nexus).
• The ability to easily create a custom deployment workflow in the web interface.

Deployment to various environments can be done from a web interface without needing to manually copy files around or log into systems to run scripts.

Full blown support for repositories such a SonaType Nexus would be better than having to deploy an agent to watch particular filesystem paths.

We've been using IBM UrbanCode for 3 months.

No issues with deployment and the automatic deployment of agents and agent relay has proved very useful.

We have not encountered any issues with stability.

Currently a single node is sufficient for our needs, so scalability has not been an issue.

There was no need to contact customer service.

There was no need to contact technical support.

The previous solution was a mix of manually copying files around and logging into systems to run scripts. IBM UrbanCode Deploy enabled us to easily take builds from SonaType Nexus and deploy them into the environments without needing manual steps.

The initial setup was straightforward. It was very easy to install and configure IBM UrbanCode Deploy and remotely deploy its agents.

In-house.

Before chosing this product we also evaluated Midvision RapidDeploy, Thoughtworks Go and Xebia Labs XL Deploy.
Thoughtworks Go: the plugin to integrate with Sonatype Nexus is a thirdparty plugin and has been broken for sometime.
Xebia Labs XL Deploy: The set up of each app for deployment is overly complicated.

Reusable templates make your life easier.

Using reusable templates (mainframe and middleware), you can force developers to use the same rules for deployment. Also, you have choice to break that rule.

Since 2016.

In our implementation, we created 16 PMR for this product. 15 of them were solved.

Perfect. IBM has one of the best customer services.

Perfect. IBM has one of the best technical supports.

No.

We implemented in-house.

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

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.

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.