UrbanCode Deploy Reviews

Our company uses the solution for standard, blue-green, and complex deployments. We have 250 users throughout our company. 

The solution handles complex deployments very efficiently. 

The user interface includes buttons or drag-and-drop options for all functionality. It is easy to create component processes and application or process flows. 

The interface allows access in a number of ways but that can be confusing. For example, driving to your home from the office is easy when there are one or two routes. With twenty routes, there is some initial confusion. 

I have been using the solution for three years. 

The solution is stable. 

When multiple deployment jobs are triggered at once, the solution logs the second job until the first is completed. This could impact performance or progress because the solution gets stuck in a holding pattern. 

We use the solution on-premises so there is no need for scaling. 

The Community is good because it includes a lot of documentation that is quite clear and understandable. In particular, the Community includes a lot of deployment-related documentation. 

I have not needed technical support. 

The setup is very easy so I rate it an eight out of ten. 

Our five-member team handles all implementations. 

Deployment does not take much time compared to GitLab. If everything technical is set up on the platter, then creating components or application processes might take a day or less. 

I use the solution for deployment and GitLab for entire development operations life cycles.

The solution is a great tool for hands-on deployment that is straightforward. It is easy to get exposure in terms of real-time work. 

I recommend the solution and rate it an eight out of ten. 

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.

We use this solution for deployment automation. 

The most valuable functionality is the ability to define the deployment process, schedule the deployment and automatically execute the deployments to different environments. 

We also have integrations with our custom tools which are in UrbanCode Deploy. We don't use the UrbanCode Designer, which is part of the product, but this is mainly because of our conservative approach to security. 

The technical support of the solution could definitely be improved as PMRs take a long to resolve. The cost of the solution is high. 

It would be good to have the support of public cloud services like Azure. 

My team has also had some concerns around security when using this solution. 

I have used this solution for five years. 

This is a robust and stable solution.

The setup was quite easy. We are still in the process of rolling out the solution to the entire organization. We are still using Automic for infrastructure configuration management. We offer our development teams multiple options including UCD and Jenkins however, UrbanClode Deploy is our main choice.  

Our biggest ROI is increased productivity which we experienced within the first year. 

This solution has offered us an ROI as we have combined it with the IBM Engineering Lifecycle Management tools. Although the price is high, it is a great quality product. 

Trial and error is the best way to determine if this solution meets specific needs. This is a good solution for enterprise-level deployment automation. However, it may not be the best solution if one is only looking for a simple solution for deployment automation. 

We are currently comparing this solution with other options in the market such as Azure pipelines or the GitHub actions.

I would rate it a nine out of 10. 

We use UrbanCode Deploy for deploying containers and Kubernetes.

Within our organization, there are roughly 20 people using this solution.

It helps us orchestrate enterprise applications that need to be coordinated.

I would like to see more reporting for container architecture.

I have been using this solution for five years.

The stability is good. I haven't experienced any issues.

If you really want to scale up, it's going to get a little complicated. You'll have to do some configurations to make it work. High scalability is a little complex with UrbanCode Deploy.

Overall, the scalability is good, but it's complex.

IBM recently sold the solution to HQL. Today, communication is not as fast as it was with IBM.

Currently, the support right now is HQL, but through the IBM systems.

Deployment times vary. It took us between five to six hours.

Considering COVID-19, the price is too high.

If you are deploying independent components that are not involved in an enterprise scenario, then maybe this solution could work; however, if you have a complex scenario with multiple components and multiple complications, then it's better to choose a more powerful solution.

On a scale from one to ten, I would give this solution a rating of ten.

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.

Currently, we are using UrbanCode Deploy, a product from IBM. Before I had a bit of expertise with it at a bank in Belgium that uses recent commissions from computer systems.

Now, I work in Belgium for an importer of Volkswagen, Audi, Porsche, Lamborghini, etc. I'm in the middleware department. What we do is we link all the different applications together.

We deploy UrbanCode as a middleware solution.

In the beginning, this tool was completely new to us, to everybody in the company, actually. At that time, Urban CodeDeploy was not performing well at all. After that, when we started to use the tool more and had some better insights, UrbanCode Deploy started performing better. 

Last week we sat together with some IBM experts to see where we could gain some more deployment type of performance optimization. We still have to do this. We got new recommendations yesterday. We will now see how much effort it will take to implement them. We will not implement them if it takes over 2 weeks. 

If we can gain maybe ten or fifteen percent optimization with UrbanCode Deploy, then we will invest further in the platform. The tool is performing not so bad now.

For me, the most valuable thing is that we have a full overview of our environment, where we have deployed what, when it went okay, when it went wrong, etc. These kinds of things. 

It is very easy to make a software release. It used to take us at least a couple of hours to make a release, now we went to production with a new one last night. This new release took me five minutes.

It makes it easy to select what we want to deploy and to follow it up afterward. The reports that we get when something goes wrong work very well.

What UrbanCode Deploy improved for us is that we have better visibility. We are not deploying faster with it. Actually, it's a little bit slower.

We have the software application automation fully under control with UrbanCode Deploy. Whereas when we did it the old way, we had failures.

Before we used UrbanCode Deploy it was difficult to find out why we had failures. Now, we don't have any failures anymore, or almost none. 

For the last couple of months, we have no failures at all and we have full visibility. The interface is doing very well. 

Performance-wise, our deployment now takes longer. We know that, but that's something that we can live with to take advantage of UrbanCode Deploy's other feature set.

We are one major version behind and we will do the updates internally. The only problem is UrbanCode Deploy is used not only by me but by all of the company. We all do our deployments with UrbanCode. Upgrading is not my decision. 

I certainly would like to have a better way to pass information between deployment steps using UrbanCode Deploy because that's really difficult to do. 

Personally, I would like it if you can loop on some things like the tags and the agents. I would like to have some more loops.

I'm really not that satisfied with the stability of UrbanCode Deploy. First of all, it needs a lot of memory and it needs a lot of CPUs. This has a huge impact on viewing. I expected an interface that is far more responsive and it seems most of the screen handling is done on the server and not on the client. Hence, just for working with it, you need a machine with 4 CPU's or cores to be comfortable.

If you use the API's to do some stuff from Jenkins it performs way better. Doing the same action using the REST API, is literally just hundreds of milliseconds, whereas the GUI takes seconds. That is certainly something that UrbanCode Deploy could improve on.

The current version that we have, the 6 series, does not scale at all. It is not good enough, in my opinion. They knew this and they have upgraded this with a whole new technology. We do not need it to scale any further at this moment.

In the beginning, we had some issues with UrbanCode technical support, some things that did not work the way we thought they would work. For some of them, we opened PMR's with IBM. As always with IBM PMR's take a long time to respond. 

I'm not happy with UrbanCode customer support at all. On the other hand, we also put some time in with these experts last week. These experts were certainly highly qualified. With them, we proceeded very well and very quickly on some items, so it's a little bit mixed. 

The support that we get from PMR's is not good. I give it a score of 2 out of 10. We have PMR's open for more than a year.

Management wants to use UrbanCode to make sure that we all deploy the same way. I do not know if they evaluated other products. I was just given the product at the moment and I was in the company already for some time. The strategy behind this is that everybody deploys with UrbanCode.

We have a department called Infra. Management decided to use UrbanCode for several reasons so it was imposed on us that we should use it and it was installed outside our team.

Because the company likes to use the big solution providers, our middleware is IBM. Our deploy tool is IBM so they have a lot of big players. I personally prefer Open Source solutions. I don't just want to use Open Source. We use Jenkins & GitLab. 

Jenkins & GitLab are tools that everybody uses and if there are problems, these problems are fixed quickly by the community or by the developers. That's basically how Open Source works. I am not at all against paying for a solution. For example, it could well be that we use GitLab but the Enterprise Edition. It gives us the opportunity to start with a community edition.

I like to evaluate tools to see how they work, to see how they fit us as a company, and then switch to a paid solution. This is something I miss with big companies like IBM.

In my opinion, the way you have to develop with UrbanCode Deploy is to use the graphical interface, which is nice. However, for development UrbanCode Deploy is slow. 

Each time you have to click on something, you have dropdown menus, etc. I am a coder by nature. Some tasks I would normally prefer to go faster. It would be better if I could type commands directly using UrbanCode Deploy.

I would give UrbanCode Deploy a six or a seven because it is not easy to set up. The documentation is not commonly found. I think it's pretty expensive too. UrbanCode Deploy is not so much used in the market. When you implement, it's not so easy but you can overcome that. Afterward, when it runs, it runs slowly to complete. Now that we have the solution, we rely on it and really trust it now. I would have given it more points if it were easier to work with. My final rating would be seven out of ten.

Take at least one month and properly evaluate the tool with a real business case because it was sold to us in a different way. We were told this tool can do anything and within a week you will have a solution. In reality, it took us three or four months even to come to the final solution. The tool is not as easy as the vendor says it is. You have to get used to it and you should not think that this tool is just magic that will solve your problem. You have to think around your current problem and then see how you can get that into the tool and not vice versa. Don't expect the tool to solve your problems.

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.

The most valuable feature is the ability to create a deployment process visually and to see that process executing in real time, step by step, with access to log files and with a click of a button.

It has drastically improved how we function. We can now realize continuous delivery practices. We can automate more and integrate with other system much more easily.

Need more granular security: for example, access to the Settings tab is all or nothing. I would like to be able to grant access to parts of the Settings tab and also provide read-only access to parts as well.

Reporting: I am excited to learn more about Insights. Until then, native reporting in UCD needs a lot of work.

I have used it for 1.5 years.

We have encountered scalability issues. We did not scale particularly well. We have not been able to maintain a cluster with 3 servers in UCD. When running with 3 servers, we have experienced instability and agent connectivity issues.

Customer service is average. For a company our size and the amount we stretched the tool, I would say more could have been done to help our journey. With that said, there are a lot of examples where IBM has worked very well with us.

Technical support is slightly above average. It has been good. We have challenges that we still need to work through.

We were previously using a home-grown solution. That solution couldn't scale, was risky to make changes to, and could not provide the features we need to achieve continuous delivery.

Initial setup was complex. There is a lot to consider in a large enterprise: security model, resource tree strategies, infrastructure topology (UCD servers, agent relays), management of UCD agents (installation, monitoring, troubleshooting, etc.).

We implemented it mostly in-house but we did have some help initially from IBM consultants. I would rate that help as fair.

• 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

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.