UrbanCode Deploy Reviews

We are using it for our CI/CD pipeline across all levels: from development to production.

A lot of times, the constant changes that happen in the application, the skillsets required, etc., become bottlenecks, and we have to constantly depend on teams. Any new variations that happen in the application, getting the whole pipeline to be built again, or changes to be done in the uDeploy code: All these become complicated and they take time. UrbanCode Deploy could be improved so all these processes are more comfortable, seamless, and rapid.

We were also trying to do an orchestration, and do a POC around how it could be leveraged for flexibility of BCT, switchovers, etc., a similar functionality as HBO, and I would love to see this single suite support that in the next release. I'm  really keen on exploring that.

My organization has been using UrbanCode Deploy for the last four to five years. I'm a consumer for it because all the applications which go on the pipeline for deployment go through UrbanCode Deploy.

We didn't have any challenges with UrbanCode Deploy, so it's good. It's stable.

Our organization has also tried other CI/CD tools. There are areas where this tool has been lacking, which is why alternatives are being looked into. From a scalability point of view, I'm rating it a six out of ten.

UrbanCode Deploy is used as a part of the enterprise solutions that I work on, while Process Orchestration is what I work on in context to IBM, BBM, and Camunda products.

I'm not from the support team or the team who's handling this application, so I would not know about the deployment and whether it's easy or complicated to set up.

As I belong in a big enterprise, the volume of users is huge, and I don't even know people beyond my department. Thousands of people are using UrbanCode Deploy in our organization. Predominantly all the development teams are using it as consumers for their CI/CD pipeline.

I'm giving a score of seven out of ten for UrbanCode Deploy.

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.

We have 5,000 to 6,000 developers and we wanted to make sure that with such a large community, we were able to scale up to support thousands and thousands of applications, around 4,000 of them. They're all being continuously deployed through UrbanCode.

It's a great product and a great framework. If you're on a team that has a good mixture of both developers and people who operate the environment or have an operations focus, you're going to love this tool because it allows you to easily integrate with your environment.

Our integration involves a portal that allows our developer and app teams to order application environments (similar to an AWS portal). The self-service tool integrates with APIs for deployments that automatically create the integrations required to develop and deploy our code. So UrbanCode's APIs have made it much easier to enable application developers to create apps much more quickly with its self-service mechanism, speeding up the entire process. If we didn't have the API, it would make it much tougher for us to support, scale, and do self-service in our application-development process.

One area is with Java deployment. We were able to reduce this from 20 steps to 4 or 5 steps, which is about a 4x reduction in complexity and specification, making it easier for our Java developers to develop and deploy their code.

The other area is not just with the tool itself, but with company culture and taking advantage of technology. UrbanCode Deploy has really transformed the way we do code deployment, connecting development and operations more closely. We're almost 100% of the way there with a cohesive devops, which I can quantify at about a 28% improvement.

Its reliability has been a little suspect, and one of our frustrations has been that it's taken them some time to focus on fixing that problem. They're able to simulate customer environments and configurations in terms of size and setup, so that when they're in development, they can run test cycles and build product enhancements and fix problems for customers. Instead, it seems they're building something locally with synthetic data that doesn't really match any customer.

Another area of improvement would be plug-ins, which seem to not have kept pace with current technology. I feel that they don't have enough staff to build plug-ins, and it's a struggle for us. It should be part and parcel of what the product is, which includes the ability to integrate with many different technologies in a centralized deployment architecture. Plug-ins multiply the value of the product, especially when you then have the ability to stretch to new integrations and technologies without having to wait on IBM to develop something.

I've used it for two years.

We had a fairly in-depth POC where we took all our key platform deployment types. For example, at the time we had a very small WebLogic environment and deployed into Teradata, Oracle, and Red Hat OpenShift. During the 2-3 week POC, we analyzed our deployment of existing scripts, embedded them into UrbanCode Deploy, and automated their execution. This required a bit of decomposition in our existing scripts in order to properly implement the product.

It actually didn't require a lot of effort on our part, which is one of the advantages of UrbanCode. So that was one of the compelling things that encouraged our thinking during our POC -- that it wouldn't take us that much time to convert our environment over to using it.

On the whole, I've had really good experiences with technical support, especially since we're a strong partner with IBM. As I'm an architect, I don't submit as many trouble tickets as I used to, but when I did, the tickets were impactful and technical support was very responsive. I was able to get to level 3 support fairly easily.

I set it up, but I did have someone bless the configuration to reassure us that we had set it up well enough to scale to cover our IT.

ROI is tricky to pin down. There are a couple of good metrics in areas for which we were able to reduce the complexity of deployments. See the above discussion regarding organizational improvements.

Understand your environment, your processes, and how your teams use your technologies. Make sure you spend some time decomposing those areas and making sure that the orchestrations and automations you create fit your customers' needs. Don't have the expectation that it's going to be easy and plug-and-play out-of-the-box.

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.

• The gating and approval workflows.
• The udclient.jar API calls are relatively easy to understand.

• Centralization of our deployment process
• Unification of our nonprod and production deployment process

It makes it easier to create new resources, especially new components, and to import new servers into uDeploy Environments.

I have used it for six months.

Once I understood the API, deployment was reliable.

We have not encountered any stability issues.

We have not encountered any scalability issues.

Customer service is good.

N/A: I have not had to invoke technical support.

We did not previously use a different solution.

I was not involved in the initial setup & configuration.

We use IGS on site to assist our IT staff as needed.

We are still evaluating competitors like XebiaLabs Release, Puppet and Chef Automate. There is a chance we could move to Chef Automate

Learn the API and automate common tasks from your CI|CD pipeline

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.

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.

We like a few things, such as the calendar, the permissions model, and the process editing. The component template and deployment interface are very good.

Our organization has already improved by quite a bit by taking out so much manual intervention from multiple people doing the deployments. We've simplified our process and the deployments are now much faster.

Sometimes the deployment process reports are faulty. I've run into situations where the job says it was successful but it really erred-out. It would be nice if the reports are correct all the time.

The configurations tab takes forever to load. It doesn't work very well so that needs to be improved. Also, you can't filter by resource tag, which would be useful.

We've used it for six months.

The deployment reports are faulty.

So far, the product has been very stable.

We're in the process of moving pretty much most of our codes to run through it one way or another. I anticipate it will scale well.

So far, we haven't had an issues with support so it seems okay.

Our existing solution was mostly manual deployments so that, of course, is very error-prone. We looked at several different solutions to try to see what we could implement quickly and what would have the most impact, the most return on investment in a relatively quick amount of time. This was the tool we decided to try out and so far it's working pretty good.

It's very time consuming, the setup of the solution. We ended up scripting a lot of it, so that it was quicker. There's a lot of pieces that you have to set up for one particular job to run on it. You can actually make steps and end up having to sit there and figure out what you missed, so we ended up scripting a lot of it so that we wouldn't miss pieces, which made it also quicker to set up new applications, to be able to get all the way through deployment.

We implemented it with our in-house team.

It's a pretty straightforward tool for straightforward deployments. If they have many complicated deployments, they're going to really want to look at the plugins and what's out of the box to make sure that it's going to be able to do what they need to do, and that they need to make sure that they have the resources and time to spend setting it up.