UrbanCode Deploy Reviews

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.

We use UrbanCode Deploy for storing the artifacts of the environment. 

In both our production and non-production environments, we rely on UrbanCode as an artifact repository. For example, if we want to deploy something in production then we take our usual steps, such as stopping what needs to be stopped, then we deploy using UrbanCode, and then we restart to make our production environment available again.

This solution is also useful for maintaining different versions of the artifacts because it has the capability of maintaining snapshots.

The most valuable feature is the snapshot functionality, which allows us to access previous versions of the artifacts. I can see what versions are there and it has helped a lot in one of my products that has many different artifacts that need to be managed. UrbanCode shows me which versions of which artifacts are in each environment.

This solution could be made more flexible with respect to deploying databases. Liquibase is a valuable feature but it is weak and could be better. I have just seen a video on a product called Datical, and the database workflows are easy to manage.

Not just anybody can use this tool without first taking at least the basic training online.

I would like to have the agent up and running at all times, as opposed to only while it is in the DevOps pipeline.

I have been using UrbanCode Deploy for nearly four years.

The stability is good and we've had no issues with it. We use it on a daily basis in both non-production and production environments.

This solution is very easy to scale. We have between 300 and 400 users and we have had no issues at all. Our development and support teams have access to this tool, although there are only four or five of us with administrator access.

We have only contacted support one time and it was concerning a very minor issue. Currently, we are running this solution without a support contract from IBM, although we will be purchasing support the next time we upgrade UrbanCode.

Before UrbanCode was implemented in the organization, we used to perform the basics using Jenkins. However, it was a very lengthy and difficult process.

For some of our products, we are not using UrbanCode. For example, we have implemented Ansible and we are looking forward to using it more as a Linux tool. The major difference between the two is that Ansible is agentless. I just need to log in to the server and do my deployments. The issue we are having with UrbanCode, where we want to keep the agent up and running at all times, is automatically resolved using Ansible.

We will continue to use multiple products for the time being.

The initial setup is easy, although it depends on the tool that you are comparing it to. For example, Ansible is a similar tool that is not agent-based. Overall, I would rate the ease of setup a three out of five.

When the product came in, one of my colleagues went for training and then assisted me with the implementation. I also took some online training and I think that anybody would need it before they can use UrbanDeploy.

The licensing fees for this solution are based on the number of servers that are being deployed and the number of agents that you have. There is a separate charge if you want support from IBM, and the cost of support also varies depending on the number of agents.

This is a solution that I recommend but I think that for anybody who is interested in implementing it, I would suggest that they start by reviewing the resources that IBM has online. It is not complicated, and they will be comfortable with how the variables are used and that kind of thing.

I would rate this solution a seven out of ten.