Nolio Release Automation Reviews

One, it's agent-based. It allows us to do multiple things at once as opposed to serially, which we had a home grown tool that did it serially. We've reduced our time frames. I think the pre-codified actions for doing the release activities, also is a major benefit. It's something that we don't have to write scripts for, they're already written. We just need to pull them together. Those are the two major things.

The other thing that the tool does that we're beginning to realize is it's addressing what Gartner's calling this bi-modal approach. What we're realizing is that Mode 1, which is your old legacy type of approach, which is why we got the tool. It's fantastic for, but now the new fast speeds using it in the Mode 2 type thing, we're finding it bullet-proof there as well.

One of the key benefits, what really we're looking at is the quality of the releases, not necessarily the code quality, but the actual deployments and the speed at which we're doing it. Things that we automate are taking upwards of 8 to 10 times less. Now, what we can do is we can do 3 to 4 times more on a release. We just had our largest release ever. Without CA Release Automation, there's no way we could deliver that level of code to our end-customers. It's very stable.

We're using it more on the deployment side. What we really want to do is see a stronger or easier user interface. I think the biggest complaint that we've gotten from the development side is that the user interface, the experience is not as good as they'd like it to be. It's hard to comprehend. We've overcome that with a lot of our own solutions, but we'd really like to see that user interface, and would like to see them get into more of the release orchestration aspect. We're actually using an internal solution for that. I know they're heading in that direction, we're really looking for that, and again, that needs to be ease of use. That user experience is critical. The developers have their critical time frames, and for them to figure out and comprehend a new tool is not acceptable. We need it to be simplistic and easy to use. There are some challenges, we've overcome a lot of them though.

Very stable. We were fortunate that early on, one of our internal technicians/architects sat down with CA. Went through the process of designing what the solution should look like. We're benefiting from that up front set up and structure of the tool in order to make it very reliable. It's enterprise wide, it's being used by all groups.

Extremely scalable, that's one of the main reasons why we bought it. It's extremely scalable. We've been able to scale up from probably 100 or so automations to where we're doing 700 now, per release. It's been a very powerful tool. Broad set of technologies as well.

The tool has been so bullet-proof, we haven't had to tap it, but when we have tapped it, it's been spot on.

Our releases were getting bigger and bigger. The demand was getting larger and larger. We knew that the home grown tool was not going to be able to be scalable, basically. It was elongating our releases. We need to get our stuff done in a weekend, and it was beginning to drift into the following week. We went to the marketplace, CA Release Automation was a market leader, we made a quick decision in that direction. We haven't regretted it.

The support we've had with CA in the past had been very strong, those were important to us. Then, the depth of the solution. I think we're looking into the depth of the solution, and the agility and flexibility of that solution, I think were important to us in this decision. We're with a large player, somebody that could support us if we needed. The tool, from everything we had been reading and researching, it could stand up to it. I think those were the things that we were looking for.

The initial set up itself as relatively straightforward, what was a challenge was the roll out. You had competing priorities, you had adoption issues, you had skill set gaps. Not only on the roll out team, but on our development team. What we were able to do was close some of those skill set gaps. It became a journey where we had to show the value to each of the individual development groups, and it created momentum. As we got these development groups onto the CA release automation, they saw the benefit. We were able to take internal environments, and be able to turnaround those environments in seconds as opposed to days. We began to get the adoption. It's getting that initial movement forward which was really the challenge. I don't know that there's anything that CA could've done. It was something that we had to do internally.

At the time we did the selection, no. They were out there. I was not part of the selection process, I know the person that was, and we got release automation before it was known as CA Release Automation. It was then purchased by CA. It was a clear market leader, so we basically went in that direction.

My recommendation would be: a) buy the tool, b) recognize that it's a journey. It's not something that it's a binary thing that's going to happen overnight. You've got to continually sell it and treat it as an ongoing initiative. We're post the projectization of it, and we're still bringing people on board to the process. I would recognize that this is a continuous delivery, if you will, exercise that I don't think ever stops because your code and your code base is constantly evolving. There are things that you can continually do, integrate it with your change management environments, integrate it with some of the other DevOps tools that you can't even imagine what you can do with it. I would say, recognize that it is a great foundation for your release automation, but it doesn't stop there. This tool is holding up to the new requirements that are coming, and that's what we really like about the tool is as the world evolves, this tool is stable. It's stable and it's able to adapt.

One of the major value we assigned the tool is it's a agent-based deployment tool. Our job is pushing code through all, consistently, 24/7 so we want the tool to handle our deployment volume.

The benefits: we are able to deliver more. Our release volume doubled up but our release window went down by 80% so we deliver more and faster.

The release orchestration and release automation tool. The automation tool is a very good deployment engine but it's not fitting our release orchestration process so we have to go for another tool to handle the orchestration, integrate the tool with the release automation. I'm looking for more features in the release orchestration.

The product is very stable. We had minor performance issues but we contacted CS Support. They gave us a solution to fix the issue.

Scalability is a good question. We started with one application automation. Now, we automate around 400 applications. We installed close to 2,000 agents.

The level 1 support is awesome, okay. Whenever we open a ticket with CS Support, we got a email response, a phone call, within 2 to 4 hours. If level 1 is not able to address the issue, they escalate to level 2 and level 3 and we get the solution very quickly.

We bought two solutions together. One is Release Automation, because our release planning team had a very strong gating process. We have to go through a approval process. They have a very strict change management process. The release automation tool did not fit really well into the process, that's why we need to go for another solution.

Our application portfolio is growing and our release window is doubled but our customers start complaining, okay when you do release software, we have to take our production system down. We want a tool to move core faster so we can bring down our release window and take a very brief outage in the production.

The reason I'd rate it 8/10 is because it is a very strong, stable deployment engine. It's very scalable. It fits really well with our deployment process.

Recommendations: first look at their current processes. How they do the release, how they do the deployments. Look for all the tools. What tool will fit into their process? When you buy new tools, you want to make sure it fits very well to the process.

The measurement we take is only two factors. The number of changes going into production and how long it takes. We are able to deliver more. We doubled our release volume but stayed within the same release window. We are able quickly, on board application for automation. Previously, it used to take weeks and months to automate an application because they're all skill based application. Repeatable and reusable process in the tool, we build a deployment process. We just onboard an application to the automation.

• Continuous Integration is easy to automate.
• It can be integrated and used for handling releases for many different platforms and tools such as .Net, Java based Application Servers, load balancers, and many others using Standard Action Packs.
• It's easy to build flows using Standard Action Packs without writing any scripts.
• It includes plug-ins to integrate with different ITSM and Source Control tools to automate deployments with REST API.

• We've integrated it with our ticketing system to automatically trigger deployments and update tickets accordingly, saving a lot of manual effort.
• Our number of successful deployments have also increased exponentially.

• Error message descriptions need to be more accurate and specific.
• Error handling needs to be improved in some of the action packs. 
• UI is a little complicated to understand for the new user and needs some improvements.

We are currently going through a period of trying to implement CICD, Continuous Integration and Delivery. We've quite a lot of tools in the CI space. Now we want to expand that out to try and allow for automated deployments, so that we can get a more integrated process and workflow, between actually building and creating code, and the actually deploying that into the systems. So that's really what our main focus is of implementing RA. 

The most valuable features for us all revolve around the automated deployments, so it's more around the governance and consistency across all the different technologies that we have. We're just in the process of implementing Release Automation, so I think once we've implemented it, and started to get to grips with the initial functionality that's available, we can start to look a little bit deeper, and see what other functionalities are useful.

We have a lot of CA products within the company and they've all fit our requirements, and I don't see any difference with Release Automation. Its benefits to us are of pulling our project together and making us more efficient. It also allows us to have a repeatable process that enables governance and control.

As we're just in the initial implementation phase, I can't say there's any room for improvement, save for maybe the complexity of it because of all the functionalities. I can see why it was chosen from the POC. Once we've got the initial implementation over and done with, we can then start to look at more of what the tool has to offer.

We haven't actually got as far as configuring the Production Instance. We've only dabbled in the POC. So it's hard to tell at this time.

In terms of actually implementing the tool technically, it's straightforward. The challenge that we've got within our company at the moment is that we're in the process of trying to roll out a cloud. It's trying to understand how Release Automation fits with that because I think it's getting very on-premise focused until now. And that's one of the challenges that we've got.

We ran a POC earlier this year. It basically looked at IBM UrbanCode versus CA Release Automation. They're the two market leaders.

The frictionless end-to-end, automated deployments. Before we did manual deployments working with different parties, we removed those handovers which makes it frictionless. It’s fault-tolerant without human errors; it's agnostic. It’s consolidated on one tool instead of multiple solutions with manual implementations.

Everyone deploys with the same tools – standardization; it makes the exchange of people within a large organization easier. Transparency, risk awareness, and it offers centralized solutions for compliance checks. Delivery to customers is also much faster, whether it’s an internal or external customer.

Stability could be improved. For functionality, it needs versioning.

We push the edges of the tool, so we have a lot of stability issues on a daily basis. The database interface, the users who access that data – when it goes down it affects a lot of clients. It impacts a lot of applications once it breaks up.

There are misinterpretations of data between an application if it’s written in a certain way, fit to use with different databases for examples with the hibernate layer, the layer can wrongly execute.

The RA product itself is able to produce queries which you can easily program, but which translate into taking a huge amount of memory which is not available in a server. If you’re in an ROC you see an overview of all your deployments, maybe 25-50 deployments with the query underneath, which queries everything that hasn’t been run. For several hundred applications that translates into huge overhead and performance problems. We’re working very closely with CA to address these problems.

It’s not scalable; we can never deploy this in an HA environment. We think they have to reprogram the core of the system, but it depends on which environment you’re using the solution in. If you’re using the solution in a less intensive, small business it could be more usable.

They do good work. We’re working closely with them. For our issues we think the solution needs a basic redesign.

Tools from other companies are more focused on Java implementations. We have a lot of off the shelf customers we have to work with, so at that time RA was able to do that. We had a lot of teams already doing work automating their deployments, so we looked for a cohesive approach. We were also deploying Secure Shell, so a mix of agents with Java and non-Java applications.

It was straightforward. It implemented very quickly, it wasn’t an issue. No big issues.

We looked for a solution that was less sales orientated, more roadmap, and had a development culture. That’s something CA can improve. We'd like more support.

We looked at Xebia, UrbanCode, Open Source Jenkins. It was because of use of agents and the ability to deploy non-Java code.

Without stability issues and all those internal escalations, it would be a 7 or 8/10. Organize your culture first, then process, then look at which tool you’re going to use.

Usability – it’s good for developers who are both technical and non-technical. This has been particularly helpful for us.

Helps with a faster ramp-up time. This is the best way in which it has helped us for sure. Otherwise, it's got the standard features for an automation tool.

• More stability and customizations
• Better integration with new open source tools
• Even more stability for the new version

We use two versions – the older version (4.4) is very unstable, while the newer one (5.5) is much better. So we went from many issues to far less.

We are not able to scale it beyond what was initially defined on the infra-bases, so I can't fully answer.

They're helpful for lots of things. Never had issues with them.

We had always used an in-house tool.

It was already setup when I joined.

We also looked at Atlassian, but CA has been there for a long time and we've just kept with them, especially since they integrate with everything and other CA tools. We also look at the integration focus of new tools.

The product provides readily-available actions to use in the deployment process. The external connectors are made available to integrate the tool with other SCM applications.

This is purely an automation tool which has helped us to move from traditional manual deployments to zero-touch deployments.

This product lacks proper documentation with illustrated examples.

I've used it for three years.

5/10 - CA has bought this product recently from Nolio and does not have much expertise available to answer our queries.

Be ready to struggle for documentations and tutorials. You have to do this based on your previous knowledge.

The dashboard is the most valuable feature as it allows you to monitor all agents installed on all app servers.

We did a pilot - a POC – during which were able to make some progress with the product; it was a previous client, and they were trying to use this product but we couldn’t get it to work properly in the development environment.

It could use more plug-ins – at least in v2. Mostly it would have been nice to see it integrated with Jenkins and JIRA to create the tickets, and to be a plug-in for Quality Center.

I've used it for six months.

We wanted to set up the automation continuous integration build process, and then we wanted to create a failure mode so it would automatically create a ticket in some defect management system. We couldn’t get the support, and we weren’t able to achieve our goals, and there were no other plug-ins available for JIRA or Jenkins.

It was in the development environment, but we didn't see anything.

We didn’t use it.

We couldn’t reach out to support because the product didn’t have the appropriate plug-ins.

We used a home-grown product on the IBM side. We wanted to enable faster continuous integration dev-ops methodology.

The initial setup was easy and straightforward.

It was a combination of our team and CA engineers.

It was expensive. In the latest version they have a lot of plug-ins so it would be worth it to invest in that version rather than what we used.

We didn't evaluate other options.

I would suggest v3.0 with all the plug-ins, which provides a lot more depth in using the product. There’s also a lot of technical support, customer service, and other online support options with that release.

1. Manifest driven
2. Multi-tier release automation
3. Comprehensive set of action packs and plug-ins to achieve business requirements

1. The number of errors have been reduced
2. A higher quality process has been achieved for application releases
3. Release Automation's significance and capability led to the formation of a new vertical team called DevOps in my organization
4. DevOps is being implemented on all the projects in my organization, to enhance customer experience

Zero down time during production deployment. Currently we use the 'Bank' concept for scalability.

I've used it for four years.

Yes, but that was later fixed by the CA team in the later versions of the product.

If more than 150 nodes are connected to the execution/NAC server, then we observe slowness in the execution of the processes. This then leads to time-outs, and the deployment fails on some of the nodes.

No issues encountered.

7/10.

7/10.

We used to do the deployment manually, which lasted for hours, and it didn't usually work in one go. So to automate the deployments we started using Release Automation.

With the help of a CA team, the initial setup was simple.

We implemented it through a CA team.

We also looked at IBM u Deploy.

It is a very good product and can help the organizations in the long run, which will lead to higher customer satisfaction.

The software deployment tool.

It's a lot easier to deploy software through CA than using a manual process or through GPOs. Packaging and client's hardware/software information recovery are handy features, as is the feedback on license management.

Maybe the user interface. We always can do something simpler, even for professionals.

I've been using it for six months.

None that I remember.

It was reliable.

I've not had experience with customer service.

I've not had experience with technical support.

I used Numara Software by BMC, but it wasn't a switch, though; it only was another customer.

Overall, it's a great product, but not that user friendly concerning the deployment server configuration/management.