UrbanCode Deploy Reviews

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.

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.

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.

There are three main valuable features for us:

1. The ability to deploy objects consistently to any of our multiple environments;
2. Prior deployments and logging stored in a web GUI which can be accessed by any member of the team; and
3. Flexibility of the plugin system to use features supplied by IBM or the ability to write our own.

Teams are now able to schedule deployments to any environment and watch in a screen the deployment occur. This has allowed teams to reduce the number of staff online when a deployment occurs.

Tracking and audit-ability of the deployments are easy and allow teams to research any issues quickly and resolve the issue with little assistance.

The reporting functionality is limited and it is difficult to retrieve information from the database due to the table structure.

We've used it for about one year.

We encountered no issues with deployment.

We have occasional minor issues with stability.

We've had no issues scaling it.

6/10

7/10

The prior solution was created by our company. We determined that to add the features required to expand our solution, it was better to use a vendor product.

The initial setup was straightforward and well-documented.

We implemented it through our in-house team.

I'm not able to answer this.

Cost is based on the number of agents installed. This is normally one agent per target box/system.

Yes, we evaluated Jenkins.

This product is excellent for deploying components and running processes related to deployments. It is not intended to be a build system, but is easy enough to incorporate into any CI Build system. The tool has two "sister" products which work well with UrbanCode Deploy. It is intended for this tool to be used for larger companies.

Repeatable, reliable deployments from one environment to the next.

We are able to help customers automate deployments reliably. 

I've used it for eight months.

No issues encountered.

No issues encountered.

No issues encountered.

The IBM Urbancode team is a great bunch of people and they are extremely knowledgeable.

Plugin-based architecture.

It has provided a platform for traceability across the whole release cycle for more than 700 diverse applications.

• Licensing structure - pay per machine deployed to.
• Additional integrations with ALM solutions.
• Unclear why it doesn't support build automation, which is covered by a separate product.

3 months.

No issues encountered.

No issues encountered.

No - scalability is handled via client relays which offload the server's work to proxies.

Good.

Good so far. Not a lot of history there.

Yes, we used Build Forge. It's a build tool that was being re-purposed for deploy and it was beginning to fail often.

Very straightforward. Command line prompts to install all components, and hook into enterpriseDB. Trial version will use its own Derby DB.

TBD. Have handled most of this in-house so far, but we have a service contract available. No info on expertise.

No specific numbers right now, but we're saving the deploy team, the infrastructure team, the help desk team, and the development teams many hours. Results are variable based on how much automation was already done, and the quality of the legacy code.

Evaluated Automic, CA product offerings. Also kept tabs on the Serena offering.

• Start with small wins to build momentum towards the larger applications.
• Align with the compliance team from the beginning. We had compliance and internal audit in the room for the PoC to run through concerns up front.