UrbanCode Deploy Reviews

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.

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.

Getting the deployments automated adds a lot of value. Before we automated deployments, there was a big problem with manual intervention and people making changes on production services and forgetting what they did. It was just impossible to reproduce deployments.

Then there's the traceability aspect -- you can trace back to the code which is stored in ClearCase through the build. All the deployment artifacts can be traced back to the original source.

The biggest area of improvement that I would suggest is in the upgrade process. We started 2015 with uDeploy 4.7, and in order to get the latest version, we had to upgrade first to version 5, which was introduced for the IBM branding. That was straightforward enough, but the jump from version 5 to version 6.1.2 was enormous. We had to focus on testing the security model because it was completely new. We documented and tested it in a production environment. Once we did the upgrade, we found another big change in the version implemented, which we didn't anticipate and which caused problems in our production environment. We re-architected the implementation and there were 4-5 failings we had to work through. Future upgrades probably won't be this difficult, but this one was tough.

In terms of functionality, the reporting could be improved a bit. It seems like the new version has better reporting capability, but data visualization would be nice to have.

We first started using uDeploy around 2011 or 2012, but when we started to automate our deployments in 2010, we used Anthill Pro. When we started using uDeploy, we kept Anthill Pro as a backend for the builds. We now are on version 6.1.2 of uDeploy.

It's less stable than our other IBM products. We have ClearCase, and it rarely is unstable as it's designed for devops work and can deal with the development process on the product itself. There have been a lot of broken stoppages in uDeploy 6.1.2, particularly in the upgrade. We installed the newer 6.2.01 in our sister environment and actually had some regressions in the interface. It seems to have the stability level of open-source products.

It's scaled fine for what we need it to do. We have over a hundred applications configured in it.

They're always knowledgeable, but it seems they're overwhelmed. They're great and deal with our issues, but it seems the hurdle is their other customers who also need help. There aren't enough resources available.

It's really good if you have a lot of applications that need to be deployed in different environments. You need to have a team to support it because there's a lot of different pieces and it's a really deep solution. There are many features, only some of which we've been using. It's not the kind of thing that only one person can work on. It's not for a small shop; it's for an enterprise.

The ability to deploy as often as possible allows a number of people to work on it at the same time.

It's provided us with more reliable and faster deployments, as well as the ability and flexibility to create and modify deployment applications to meet the needs of the ping.

We're running version 4.8.4, which isn't the latest version. This version lacks reporting, which may be improved in the latest version.

I've used it for four years.

It's been a very stable product. We've had a few performance issues, but they haven't been serious. I'd say we've been going for a couple of years without having any issues or needing any support or assistance.

It's absolutely scalable. We have gone from about 17 products to 32, maybe it was 42 since we've gotten uDeploy. Before it could take a couple of days and we could only do a few deployments, just barely a few in a month. Now we can do multiple deployments in a day, we can get hotfixes out very quickly, and we can easily modify and customize processes as the needs of the teams change. It scales very well for us. We also, for instance, have needed to improve our security and all that is there in uDeploy. We don't have to do anything other than figure out how to configure it.

Technical support is always very knowledgeable and proactive. In contacting different people, we've always had very good responses.

We weren't using anything before and we had to get something up and running quickly. It did take us a little longer to get the uDeploy up and running than we'd hoped, but once we did it certainly met all of our needs.

It was complex at times. It took us a while to come up with the standard process that we needed, but then once we had it it also took a while to actually get all of our projects up and running. We didn't know how to use the CLI at that time. We might have been able to do better if we knew that.

It was all done in-house. I'll add a comment that the learning curve for uDeploy is high. Even now there's a couple of us who know it well, but being able to bring somebody else on-board and explain it to them would take a little time. Of course, now that we know what we're doing, we have somebody so we can explain it to somebody else, but at the time when we started and since we didn't know what we were doing, and it took a lot of trial and error to figure out how to use it.

Standardize processes as much as possible so that you can re-use them. Don't be afraid to create multiple applications when that reduces the complexity. Don't make applications really complex to try and do all these things all at once. If you can, break it down into smaller apps because they're easier to manage. Generally the more independent things are then the fewer things break at any one time.

If you have problems, it doesn't affect more than just the particular instance that you're looking at. Our developers have done a lot to break down our projects into smaller and smaller pieces so that they help with that. We can deploy an application, but if it's only got three modules that are changed, then we only need to deploy three modules. Breaking it down into independent pieces and reusing them, I think, is really important.

Integrating it with an automated build system, I highly recommend that. We use Jenkins. We can easily connect our Jenkins artifacts and push them to uDeploy so that they can be deployed. We have some interaction between the two so that we have good auditing and knowing which build is the one that got deployed. In fact, using versions that relate to the build version, so that when you go into uDeploy and you look at a version then you can see that that version came from specific build and the build tool, that's really helpful.

It just changed my whole job and made it easier. I'm sure that some people might have different opinions on that, but coming from where we were and getting to where we are was just never could have been done without uDeploy and it's just incredibly powerful for us.