UrbanCode Deploy Review

Enables the creation of reusable component templates. WebSphere deployments do not work out-of-the-box.


What is most valuable?

The valuable features are “scriptability” and customizing the deployment processes.

How has it helped my organization?

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.

What needs improvement?

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.


For how long have I used the solution?

We have used this solution for one year.

What was my experience with deployment of the solution?

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.

How is customer service and technical support?

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.

Which solutions did we use previously?

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.

How was the initial setup?

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

What about the implementation team?

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.

What was our ROI?

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.

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Guest
Sign Up with Email