Nolio Release Automation Reviews

I am working for an organization where they have been using Nolio Release Automation since 2016-2017. We are currently using version 6.6, and due to dependencies and lack of support from Broadcom, we are migrating to version 6.9. We have already tested in our lower environments and pre-prod environment, and we are planning to deploy to the production environment next week.

As the central DevOps team, we are the administrators for the Nolio Release Automation tool. We provide the Nolio Release Automation infrastructure for our whole organization, enabling them to deploy their applications to their respective environments.

The solution has been really helpful with its flowchart-type interface. We can easily configure the deployments through drag and drop functionality, and we can define the process and components using the flowchart. Once we create the process and components, we can publish these components to different environments. Using these components with release parameters, we are able to deploy efficiently to other environments.

The positive impact is the ease of use. While Kubernetes and Docker are used for deploying and exposing applications, Nolio Release Automation allows us to do all kinds of configuration management. We can configure file copying operations and application deployments. Everything is feasible to work on within Nolio Release Automation.

The main disadvantage I see is the limited awareness of Nolio Release Automation in other organizations. It is a very nice tool, but its market presence is limited. I heard from the organization that the licensing cost was somewhat expensive. Perhaps focusing on marketing efforts would be beneficial. It is a really nice tool, and I am unsure why many organizations are not using Nolio Release Automation.

It is one of the greatest tools for continuous deployment, yet its popularity remains limited. Some organizations are not aware of its existence. This might be an area worth researching and potentially developing new marketing strategies.

I have been extensively using Nolio Release Automation for three years.

The deployment process is really easy. While the architecture was initially complex, once everything is configured, it becomes straightforward. The new version of Nolio Release Automation is particularly easy to use.

In version 6.6, we faced numerous performance issues. This might be because it is a six-year-old version, and we are supporting nearly 1,500 applications and 15,000 to 16,000 agents. I will observe the performance after upgrading to version 6.9.

The solution is sufficiently scalable for our usage. I have not encountered any difficulties in this aspect.

Earlier, support was not available for version 6.6. After obtaining the license, we started working on the 6.9 migration. We are receiving good support from them, and they respond quickly to our queries, even simple ones.

Positive

I previously used IBM UrbanCode Deploy. They are still using UrbanCode Deploy, but I did not work extensively on the administration side, making it difficult to make a comprehensive comparison.

We are currently in the testing phase. Once we go live in the production environment, I will be able to provide more detailed feedback. At present, we can deploy our application and the new version in lower environments while performing sanity checks. A complete assessment will be possible once we begin supporting other applications.

The 6.9 version offers significant improvements over 6.6. The dashboard is very appealing, showing information about applications and offline agents. We can easily remove offline agents and upgrade application agents to newer versions. These are the main components currently available.

The integration capability in version 6.9 is particularly good, and I have worked extensively with this aspect in the newer version.

On a scale of 1-10, I rate Nolio Release Automation a 9 out of 10.

Nolio is primarily used for production deployments, including web apps and data system deployments. We use various deployment types within the tool. Nolio is the official deployment tool at Barclays for all production-related tasks.

One standout aspect is its architecture. We can configure multiple instances on a single server using different system names or usernames. 

Another feature I like is that the graphical user interface is user-friendly and aids in efficient design and deployment.

When I started using Nolio around eight months ago, a challenge was the lack of relevant information and related support for learning. There's also not many instructional materials and videos on platforms like YouTube, especially for a very basic user. The tool might be somewhat challenging for new users initially, but becomes more accessible with familiarity.

We've been using Nolio for over eight years as part of our operational processes.

However, I started using it about eight months ago.

The tool has been quite stable. Once we configure it properly, it remains very stable. For general use cases, it is a very stable tool. 

However, it is still difficult for beginners to configure the Nolio. 

We have a substantial number of users, roughly around 13,000 to 15,000 end users. So, we're operating on an enterprise scale.

So, scaling is easy. Once you get familiar with the tool and get some basic information about it, it becomes easy to scale. 

There is room for improvement in support. Support is provided, but from the enterprise perspective, the licensing costs can be a concern.

I've worked on OpenShift, and I've also worked with IBM UrbanCode Deploy. In some aspects, Nolio is better than all those options. 

However, as an administrator, there's a degree of uncertainty. I'm currently in a learning phase with Nolio, which I started using about eight months ago. At this point, I've become acquainted with around 70% of its features.

Nevertheless, I'm still unaware of the concealed functionalities that require exploration. Only after delving into these can I provide a more informed opinion.

The initial setup is very easy. Installation and configuration were very easy. Each time we configure, it's a similar process. Comparatively, the installation was easier than other tools.

Installation is quick, but configuration takes a bit longer compared to other tasks. There are some complexities related to tagging, enrollment, and contact information that could be addressed to enhance customer experience. These aspects can be a bit challenging for those who are new to Nolio.

Installation typically takes a few days, not a full week. 

However, maintenance is a bit difficult. I've been in the industry for six years. It seems a bit more involved compared to other tools. Skill-related issues play a role, and sometimes, we face challenges due to a lack of proper information.

Nolio is a pretty much good tool, though its pricing is relatively high in the market. It's more expensive than other tools.

The pricing could be cheaper. In our organization, we've been using it for many years. Due to pricing considerations, there were discussions about transitioning to an alternative tool to replace Nolio. 

Nolio is a very good tool. It's highly effective for deployment tasks and even supports one-touch deployment across various environments. When you design a process template, it can be reused across different scenarios. 

It's particularly valuable for database management and web applications. In comparison to Microsoft Kubernetes and other operations, database deployment can become complex, whereas Nolio is a very nice tool in the deployment arena.

Overall, I would rate the solution an eight out of ten because I don't know all the hidden features. Once I gain a comprehensive understanding of these features, I might be able to give a more definitive rating. 

Initially, when I started learning about Nolio, I found it somewhat challenging. However, over time, I discovered that it's a valuable and well-designed tool.

The graphical view of when you're writing flow is the most valuable feature.

We want to expand our work to Amazon or Azure to the public cloud. We have Kubernetes on-prem and I want to know if Nolio can handle it.

I have been using Nolio for three years. 

It is stable.

We have more than 500 uses in my company. Nolio requires 20 people for maintenance. 

The initial setup was easy. We work with several environments and it doesn't take long move from the environment to one to the other.

We have problems with the CRT. We also deploy microservices. We have a lot of parameters that are different to go from one environment to another, and it's a lot of parameters that we have to deploy and change.

The price is not an issue here.

We also looked at Ansible. You don't need to be a DevOps engineer to know how to write the scripts. I could be an operation user. It's too complicated.

It's a nice tool. I think that in the next version, 6.7, they will have more features. Features like supporting Kubernetes.

I would rate Nolio a six out of ten.

In the next release, I would like to see more features to use active directory. And more rules to support more Python scripts and to work with Kubernetes and clouds, to have an easy solution for a lot of parameters.

In general, we are replacing vendors with virtual services because vendors are not available and it is costly to get support from them. This is the primary use case for the solution.

The CA Application Insight feature is the solution's most valuable aspect.

The configuration of the solution is a bit difficult to maneuver. They should work to make it easier.

I'm not sure if there are any features missing from the solution.

I've been using the solution for five years.

The solution is quite stable. We haven't faced any bugs or glitches or noticed anything at all that has affected its performance.

The scalability of the solution is very good. We haven't had any trouble when expanding the solution.

Right now, we have 15 users on it. Most are engineers or admins. They're handling the day to day department tasks.

We've been in touch with technical support in the past. They are pretty good. They work to get back to us as soon as possible. We've been satisfied with how they've assisted us so far.

We didn't previously use a different tool.

The solution's initial setup is quite complex. It's not straightforward.

Deployment took about two to three months for us.

The number of people you will need for your deployment depends on the project. In our case, we only needed two people to take care of it.

We handled the implementation ourselves. We didn't need the assistance of outside vendors or integrators.

I'm not sure of the licensing costs for this solution. These are not details I handle in my day to day. They are directly handled by the client.

I've also looked at HP and Micros Focus as options that we may work with them in the future.

This solution is a great tool. In my opinion, it's the number one tool on the market right now, and I've done some research into other options. 

I'd recommend this solution to others. Many people don't realize that things can be virtualized like this. It can be very easy. All the requirements are right there in one click. It's simple to use. People should try it.

I'd rate the solution nine out of ten.

It's for release automation.

It has improved our speed of deployment.

In terms of its performance, we have struggled a little bit because we have multiple instances around the world without a proper support team behind it. After several years we got the new version, and the upgrade was very painful. We had several issues or defects, but CA was responsive and, in the end, they created a fix-pack which resolved the problems. We managed to upgrade.

It could use better integration with development tools. UCD is better integrated than CA Release Automation.

Another concern with CA Release Automation is that Automic was acquired by CA recently. We're a bit concerned that CA strategy is going with Automic, that CA Release Automation is dead. They are not investing in it too much. For new customers, they're proposing Automic online. They even approached us at the end of last year and asked if we would consider switching to Automic. They do say that in the next two or three years we don't need to worry. They will still provide support for CA Release Automation. But we're not sure how CA Release Automation will evolve.

It's pretty stable.

We have had no scalability issues.

There is not enough support in Central Europe but the central support is okay, it works.

I was not involved in the initial setup of the different instances, directly. We had instances in the US, UK and Singapore. But I was involved in the consolidation or migration program when we migrated CA instances to one central server in a private cloud in Prague, Czech Republic.

It did not go smoothly. There was a lack of knowledge both at CA and within our team as well. We used a consultant who was not so experienced. He wasn't able to help us but when he escalated it on CA's side we got the help we needed. In the end, it was okay but it could have been much smoother.

UrbanCode Deploy, Red Hat Ansible, and we considered Ansible Tower as well. We had some discussions about XebiaLabs XL Deploy, but it was not on the short-list in the end.

When CA is compared to UrbanCode Deploy, the latter is stronger in the development cycle, while CA Release Automation is stronger on the deployment or release automation side.

When selecting a vendor the solution cost and total cost of ownership are definitely two of the criteria; the product quality, usability, scalability, of course, and the support are key as well. The company's market situation is also important. We cannot afford to go into some risky business because it's a long-term investment, especially when it comes to deployment automation.

If I were to consider investing in a new deployment automation tool, I wouldn't switch to CA Release Automation, because of the CA strategy. They don't invest in it anymore. From a strategic perspective, I think it's probably not the best tool to invest in.

I would definitely consider Automic. I think Automic is a leader, and I think from a features perspective, Automic is very comparable with UCD. I think XebiaLabs XL Deploy is becoming much more popular, but it's more for release automation. There are companies around that combine UrbanCode Deploy and XebiaLabs XL Deploy.

I would rate CA Release Automation at seven out of 10. It's a good and mature product but there is no future investment expected in it from CA's side. It's a stable product. It provides the features we need, but I am concerned that, long-term, the technology support might be an issue and a reason I would not give it a 10; that and because of the upgrade challenges we had.

CA Release Automation has a GUI which is easy to use and develop the solutions.
Most of the day-to-day tasks which need automation have been already covered by built-in actions. So you just have to drag and drop to start using it.

It has various plugins, which make integration with other tools like ServiceNow, Jenkins, and JIRA, etc. easy and helps in implementing CI and CD, following an agile approach.

The ROC provides features that help in release management and ServiceNow authentication when enabled, and can make production deployments safe and error free.

Deployments have been automated fully and now all the teams follow a single, error-free approach of deployment, which is time saving and seldom faults. It helps to implement standardization.

I would suggest that, rather than just concentrating on release automation and management, this tool could provide for more automation in different areas, such as database automation (we already have this but still can be improved further).

I have used CA Release Automation for over three years.

No particular issue from CA Release Automation side. if we had any deployment failures it was mostly due to the environment.

The tool is very stable and any issues we have encountered have been due to infrastructure-related issues (servers/VMs) or human error.

We have not faced any issues which scalability till now, but we do not have implementations which are very large.

CA technical support is good. You also have a community where the experts will help you with issues.

I had used IBM RAF for deployments. It does not have the same flexibility as CA Release Automation for automation in it.

Initial setup is pretty straightforward and we did not face any issues.

We had previous knowledge about this tool, so selection was not difficult.

I would definitely recommend it to whosoever wants a good solution for their automation, deployment and release management.

• Ability to maintain the maps of different environments in a single tool. The way the tool organizes and manages the information to be used in the automation deployment is one of its strengths. It is possible to have a map of all the environments involved in the Software Lifecycle (Dev|Pre|Pro), and maintain, in a centralized point, the actions that are shared between the environments and the specific actions of some environments.
• Ability to design and manage DevOps activities from a graphical viewpoint. The core of the tool is the workflow. These workflows are designed in a graphical point of view. This is an excellent functionality which is better than XML or other file based actions definitions. You can perform workflows using other workflows, so this increases the reuse of actions and reduces the copy/paste of actions.
• Ability to manage large installations with more than 5,000 servers due to the 100% scalable architecture. You can install the tool in a simple machine for simple installations or development environments. You can install the solution with redundant servers for critical installations. Also, you can distribute several components of the solution in the way you need in order of manage the deployment of large organizations with a large number of servers, a large number of applications, several technologies, CPDs distributed around the world, mix models including cloud and on premise hardware, etc. You maintain a unique point of access for all of this, sharing actions, dashboards, etc.

There have been improvements in several kinds of projects:

• Projects with more than 5,000 servers and daily deployments.
• Projects in which we must manage the deployment in a cloud environment based on the monitoring. As the number of users grows, we must deploy a cloud environment and deploy the applications. If the number of users decreases, we must uninstall the applications and release the cloud infrastructure.
• Deploying applications in a continuous integration environment, including deployment, QA, pre-production, and production environments.

Integration with other technologies such as Dockers. The solution has the capability of integration with other technologies, and I can do this without problems. The issue is that all the tasks are performed and managed in an ad-hoc manner. I think that it will be interesting to increase the standards.

We have used this solution for more than five years.

We encountered a stability issue, but it will be solved with the collaboration of the CA teams.

We have not encountered any scalability issues. It is very important to perform a correct design of the architecture beforehand.

The level of technical support is good.

I use open source solutions like Puppet and Chef. These solutions require a high level of expertise and are difficult to maintain in large installations. For this kind of project, it is better to use commercial tools like CA Release Automation.

The initial setup was simple. However, if you want to use the tool in large installations, there are some tricks you should learn.

It is an expensive tool and the licensing model is difficult to sell.

We evaluated open source, XebiaLabs, and IBM.

Begin with a small project and grow it progressively. If you need a large project, you should acquire professional services.

The built-in action packs for different systems is the most valuable feature. The CA RA install comes with built-in plugins for tools such as TIBCO, WebSphere, IIS and so on. This helps to avoid writing custom scripts to deploy to those kinds of servers. We use those plugins instead.

It helped with auto-deployment of the pipeline from TeamCity & configuring rollbacks, and seeing versions and release pipeline status.

Have an agentless deployment: Right now, we had to install agents on all deployment servers, for it to work with the CA RA tool. Currently, when a deployment server needs to connect with the CA RA tool, it needs an agent installed on it. So, when we deploy to 100 machines, we need to install 100 CA agents on each one of them, i.e., even in the production servers.

I also think that the cost of this product is high. There are other cheaper deployment solutions available in the market.

I have used this solution for more than six months.

We did have some stability issues. Sometimes, my agents on the deployment servers failed to connect with the CA RA server. So, I had to restart the agents on deployment servers once a week in order to make them active again on the CA RA admin console.

Technical support is good. The support was quite responsive.

We were trying out many different solutions and CA RA was one of them.

For the setup, the complexity level was medium.

The price of this product is expensive.

We are still in the evaluation mode with different vendors. Also, some teams are using the CA RA tool extensively.

Do a PoC of the product and weigh the cons and benefits, before buying the actual licenses.

Some of the most valuable features of CA Release Automation are definitely the shared components, as well as the tokens. Shared components within this application are repeatable processes that you can assign throughout multiple applications, such as your business types, funding, credit, whatever else, that are repeatable processes. For example, if you wanted to set up an IS site or something along those lines, you would create a repeatable flow process with the application, and then you can leverage token values to fill in something like the service account, the passwords, that kind of stuff, that would actually be populated as part of your IS site deployment. It's pretty cool and a pretty awesome feature that we leverage all the time.

In our pipeline, right now, it's used as the release. We use Jenkins to build our applications and then it sends over to Release Automation. It's basically changed the way that we're doing our deployments. We now have, instead of three-hour deployments, they're three minutes. As well as, it creates more consistencies in the environments and helps it determine if the issue is with the server, the code, whatever else, when you're actually deploying out. It's been extremely helpful.

Some of the things that we're using for compliance and governance is basically the auditing that we can use with the application, like, who deployed it, when it was deployed, what versions were deployed from dev, QA, train, stage, production. It's been pretty helpful on that one.

Some features that it's currently missing are the components that CA has put into their Continuous Delivery Edition product. That product should probably be combined with this product, instead of being a separate product. I would say that that's one of the issues that I currently see with it. I know that they put it in there as separate products but long term, it should really be combined.

We've been using CA Release Automation for about a little over a year now.

The solution itself is pretty stable, as long as you're integrating it with enterprise solutions, as well, using an enterprise database, because it's a pretty database-intense product. Don't try to use some sort of MySQL. Use something that's real, as well as the repository for your artifacts, using an enterprise Nexus or enterprise Artifactory, instead of just the built-in products.

It's pretty scalable, because you could just have multiple execution servers run. If you wanted to have more servers and agents deployed out than you currently have execution servers, you can add those on at any given time.

So far, the technical support that we've had is pretty good. I usually get about an hour response time, especially if it's something that's escalated. The other week, after I submitted a request I got a response in about 10 minutes. They opened a WebEx within an hour, and we were discussing the issue. It was surprisingly well, compared to other technical groups that I've worked with before.

We decided to invest in CA Release Automation because we were trying to find ways to be more efficient in our code delivery. We had a lot of outages surrounding releases going wrong, and part of that is also code not being built automated; versions not being the same from QA to production; just a lot of those little things that built up over time.

We also expanded as a company, so we finally have started looking at everything that we can fix and this is one of the places that we started with.

When we work with vendors, I would say just being able to actually be listened to is something we look for; whenever we have issues, actually getting responses from the companies. I find that CA actually will respond. They might not have everything out of the box that we want, but they'll listen, and they'll actually update their code and add more plug-ins. One thing that they have actually updated; we requested TIBCO version 6 for BW deployments to be added as a plugin, and they're in the process of actually adding that to their new release, on the roadmap.

The initial setup can be open to more of the interpretation of the user. If you want to have it set up baseline, you just want to deploy out one or two types of products, that's pretty quick. It wouldn't take too much time. If you're trying to create it as a central enterprise solution for your company, then that's going to take a while. It took us about six months or so, maybe closer to eight, to actually get our real foundation set before we can quickly onboard and really automate adding artifacts to CA Release Automation.

To be fair, I think that there are a lot of things that it is capable of: deploying out; integrating with other products. The UI and the design can sometimes be a little flaky, and that is a little frustrating at different points, but overall, it's definitely a solution, if you're looking for an enterprise product to do your releases for multiple types of deployments.

We were running approximately 40 manual steps, and we're getting this down to two manual steps, thereby alleviating some of the copy-paste errors, some of the transposition errors that we're currently doing that affect our customers.

For my organization, in particular, it’s going to improve our throughput. We're not going to have delays in testing, because we had some sort of manual entry error, some transposition error. We should be able to release our software to the customer in a much more efficient fashion.

As far as the role this solution has played in our continuous delivery journey, right now, we're just a very small fish in a big company. We do touch into a lot of other departments. Working with this for my group, if it becomes successful, we can start integrating and helping other parts of the organization also automate.

We don't have a lot of compliance and governance within my group. However, we do a lot of audit and we have a lot of details that we have to track. This is going to help us keep on top of those details; keep that continuity of data; keep us really on track for being able to give a better solution to our customers.

Indicating room for improvement is difficult, because we're so immersed in what we're doing right now. There's a lot of things that we can see that can be included. Working with our consultant, he's helping us address some of those issues, especially with tracking and capturing metrics. Our metrics are for very short time periods; capturing those metrics and being able to present them in a way that my management can understand.

We started using it in about March 2016, with our planning and our proto building.

I believe it will be stable. We're still finishing up some introductory things. We haven't done our full release yet. We're in a soft test process right now. I'm starting to see some very positive results with all of that.

What we're looking at is a very small part. From some of the information at a recent CA conference, I can see where we can expand. We can expand into our test organization. We can expand into our further release organization. I think there's a lot of scalability.

I've not had any problems with the tech support at CA. We've got a consultant that's come in. He's been invaluable. We've done some training. We're working right now on mentoring some of my own people to start picking up some of those tasks, so I have not had any issues with CA support.

My organization has wanted to invest in a solution for my group for a couple of years now. It was a matter of just researching, getting the right players in, and bringing in the right development people to start on this. I started on this process about two years ago. We finally got the team set up so that we could move forward on it at the end of 2015. Then we started full blast ahead in January 2016.

Initial setup is a bit complex. We also had to build a front-end solution at the same time as implementing the CA and CDD. What we're doing with CDD is kind of unique. There's been some complexities. There's a lot of business rules surrounding the manual processes; getting all those captured; and then being able to program for them. Right now, we're looking at the 80%. Then we'll be going into an optimization come the beginning of 2017.

We checked out, from my point of view, several vendors, but we have a VP that wanted an enterprise solution. We already had a relationship with CA. He felt that this was something that CA could do for us. We met with them. We feel that they're doing a good job.

I never give out perfect ratings. I think it's going to be a good, stable product. I know CDD's fairly new. We're doing new things with it. It's exciting that it can be scalable enough to accommodate our part of the production.