Automic Continuous Delivery Automation [EOL] Reviews

The primary use case is the implementation of software updates.

We save a lot of money. We have not had so many incidents in terms of correcting the deployment.

We have saved on our time costs and have seen more quality.

Stability is good. We have no problems.

CA Technologies technical support implemented the software. They were helpful.

We increased our quality and reduced our time costs.

In the beginning, we invested 50,000 Euro in the application. We expect the return to be more.

I am happy with the product.

We wanted to put in place release control, release management for our products, which is more centered around a COTS application, into an automated process. That's when we started looking for different tool sets and did a PoC with a couple of vendors. CA Automic stood out there. We started using it for both our service orchestration pieces as well as for release automation.

So far, it's been doing well. In terms of our expectations, it's what we were looking for. There are some angles where we are still refining it or maturing our processes around it, but we have covered a lot in the last about 18 months since we purchased and deployed it. We are about to take about 30 applications under the release automation and going live with a large program. So far, so good, I would say.

I would say our headwind, or our time to market, is reduced considerably. We get more consistent results out of it, because you write one time and once it's automated you expect it to behave the same way every time. And it cut down a lot of re-work for us.

Scalability and auditability. The capability to provide visibility to the stakeholders, to management, is the biggest piece that showcases what the solution is about. Our whole approach of release automation is geared around it.

One of the biggest features I've been asked by my team to put in there is opening more scripting languages to be part of the platform. There is a little bit of a learning curve in learning how to code some of the workflows in Automic at this time. If widely used languages like Perl and Python were integrated, on top of what's already there, the proprietary language, it would make it easier to on-board new resources, and it could become a little bit more widely adopted tool going forward.

It's pretty stable. We have a good number of servers under its control right now. We haven't seen any issues where we've seen it's not stable or it's impacting the infrastructure negatively anywhere.

As I said, scalability was one of the key points when we looked into. It's quite scalable for us. The enterprise size that we have is well controlled and well defined for us, so it's good.

We actually have a professional service engineer onsite from Automic, and he's part of our team. He helps us implement best practices; trains our guys as we roll in new resources. It helps set the stage for us. Very helpful.

We had a lot of challenges to begin with. There was a big vacuum of tools when we started looking into it. For us it was natural that we knew what we were struggling with, and management was looking into doing something different, something better. We started looking out for some of the tools and solutions that could help us bridge that gap.

We did a couple of trial and errors to begin with, but with the help of the Professional Services guys, it didn't take that long. We were up and running in about two weeks' time, and started putting pieces in there.

We started with IBM tool sets. We had Electric Cloud that we looked into. And then we looked into Automic, and a few others; open source tools, as well. And then we naturally aligned towards Automic.

We went with them because of the stability of the company. We were looking for a partner, a well grounded company, how long they had been in operation. And we also looked at some white paper case studies out there, that helped us. And then we did a couple of proofs of concept with some of the vendors, and for our use case, what we were trying to implement, Automic stood out.

Our most important criteria when selecting a vendor are

• the size of the vendor itself
• how stable the company is
• how long they have been in the market
• what product suites they have that can help us achieve our goal at the end of the day. 

We look for partners, not vendors per se, that can help us implement our vision with us, and that's why we like Automic.

I give it a good nine out of 10 at this time. The one piece that I think that could help leverage more of the tool is the scripting language barrier at this time. If that's not there, and some of the pieces that could be delivered faster, it might be adopted more out there in the market.

I would suggest look at the complete offering that's out there. I would suggest: Prove it out first with the use case that you have. We were not shy in terms of running some proofs of concept with a couple of big vendors out there, and then making them make the case why their product suits our use case. And don't be shy to restart if there is something that you think is not going right, make sure you fix the problem before it gets too late.

Application deployment and orchestration.

It has been performing very well for us.

There are not enough hours in a day or week for us to do our jobs. We joke, we call the Automation like another person, or another few people. It lets us multitask much better, gives us a lot more confidence in what we do. At the end of the day we're delivering products that we know are working, as opposed to guessing that they're working.

• The speed which it deploys, and the accuracy. 
• Gives people insight into what's happening during the deployment. 
• The metrics gathered after deployment, for example, the rate of success versus the rate of failure.
• We also notice places where we can improve.

We're a WebSphere shop so I would like to see more support for WebSphere, only because it's the platform that they seem to want to use the most. That's about the only thing I can think of.

The stability is very good, I've only had one issue with the product since we bought it, and the support was handled very quickly.

We've had no problems with scalability, even when it came to network segmentation. We were able to differentiate between test and production, and keep both sides happy, and make our security department not mad at us.

We actually used Professional Services, they helped us on-board, and we're actually still working with them for that too. But technical support: calling them or opening a ticket incident, very quick. We don't spend a lot of time having to be escalated from one person to another. Usually the first person that we get, right away the answer is pretty quick.

I'd say it was fairly straightforward. I think the only thing we ran into that was difficult was getting people on all the different teams, the infrastructure, to agree with our choices and platform and setup. That was the hardest part.

Going back now to 2016, we spent a year's time doing proofs of concepts with various release automation tools. We looked at all the industry leaders and we also reached out to companies that we had relationships with; obviously with CA, and we had products with IBM. We just took each one and gave them a shot, a proof of concept to go through.

At the end of the day, at the end of the year, CA offered the best package overall, and that wasn't just from a product standpoint but also a support standpoint. Because some companies (shall remain nameless) give you a startup and then they let you go, and we felt we needed beyond what you get for training. Sometimes it's not enough. 

You need that real world experience, you need someone who is an expert at your side doing it, as opposed to their giving you two weeks and then you're own your own. And then, it's not like it was during the demo, or like it was during the pilot. There were things that we ran into, that were variations within our organization, that CA was able to come in and adjust and change and make it work.

I would say, when you go to proof of concept, bring your next-to-the-worst-case scenario of what you need to get done; not the most complex but close to it. Because whatever you'll be able to hash out during the proof of concept, it positions you for better success when you actually decide to roll out.

The key use cases will be eliminating manual activities, reducing the risk of missing steps in the deployment. The other thing is to speed up deployment, because the previous way of working was having someone to document the steps, someone to review the steps, and then at the end of the day, someone had to execute those steps within that window.

So far, it has performed well, at least from the "repeatable" perspective. All deployments are repeatable, so when we have issues with deployment, it gives us the opportunity to review and to know where the issues came from. If it is working now and was not working previously, we usually know where it fails.

I think on a day-to-day basis, it has increased the capacity to deploy. We don't have to wait for someone to do something. As long as it changes, then we can always deploy to an environment on demand.

I would say the traceability part of it. With this feature, I know which environment is running what. Which version of the binaries; that is key because then we know what to fix. 

I think I spoke about this to them. The key thing is support for cloud-based deployment. That is lacking. Today, the whole world is looking at cloud deployment, running a cloud application. But it doesn't seem this platform will have that feature any time soon.

Stability-wise I think it still needs to be improved; performance-wise. It crashes from time to time. Sometimes it just hangs and requires a restart. Upgrades, depending on the versions, can be tedious and risky. We recently had a problem with one of the version upgrades, and the platform was down for a day. That wasn't a very pleasant experience.

I think scalability-wise it is proven. We are running a significant number of end points. I think other customers have run larger number of nodes as well. The scalability should be okay.

I use it all the time. The level of response is very specific to the individual that answers the call. Some are knowledgeable. But there are times that we are left on our own. The response time itself, overall is okay.

Initial setup is definitely easy. But when it comes to growing, the system becomes a bit more complicated. You want to have that HA capability, then you have to have redundancy in terms of connecting the different nodes, and you have to test that. Sometimes nodes don't seem to talk to each other. That's a problem.

At this point in time we are not investing more because we already bought upfront. We are taking a wait-and-see attitude because, if the maturity of the platform plateaus, meaning we don't have new features, we might decide to move on. 

When we are looking for a new vendor, what is important to us is ease of migration. The other factor is the the currency of the platform, how current is it in terms of alignment to the market we are in.

I give it an eight out of 10 because it does about 60-70 percent of the work. What it does, if it's done correctly, it does well.

I would advise a colleague who is considering this type of solution to look out for the fact it doesn't support the new stuff. But if you're looking for solutions that are based on your existing, traditional infrastructure, I think that's good tool.

Here are the top three features:

1. Deployment workflow (WF) can be designed this way, so that it is not necessary to provide all applications (systems) artifacts of which an application consists. Presence of deployed artifacts may differ in every deployment and an Automic ARA tool is able to handle this situation and provide a final successful installation. When we were testing different ARA solutions for this use case, it was necessary to design more than one deployment WF (specific for every combination of artifact). Our goal is to design a suitable amount of workflows for every application. In an ideal case, just one complex WF will solve all requested deployments. Until now, we have been able to keep this principle, that we have only one WF for each application.
2. Ability to easily create our own Action Packs for platforms where we are deploying artifacts (a wide range of supported platforms out-of-the-box). You can read and edit out-of-the-box action packs as well. The tool is very good, configurable and customizable for specific requests of customer (specific customer environment and processes).
3. Well and clearly designed UI with a very good UX. User is able to very clearly see designed WF, WF progress during deployment, and output logs from deployment targets and platforms. All this is available inside the Automic tool. Work in the tool is intuitive. User is able to restart deployment after it was stopped because of some problem, and so on.

CA Automic ARA solution gave us the ability to:

• Be faster and more flexible. In first pilot run, we achieved five times faster deployment without human work.
• Be effective. We are saving tens of millions of dollars of work from our IT administrators.
• Support standards and have fewer outages. Environments have to be the same because we use one deployment workflow for each integrated application.
• Support Agile development. We are able to do quick sprints without any deployment limits.

Our DevOps project (reason why we bought this solution) has improved culture and cooperation in our IT department significantly.

GUI for mobile phones: Availability to approve and start deployment through mobile phones.

Better dashboards and reporting: About deployed versions, planned deployments, waiting deployments, and so on.

Infrastructure discovery functionality: Scan customer infrastructure automatically and collect information about potential deployment targets (purpose is not to insert all the information manually). For example, XebiaLabs has this feature.

We have used this solution in our production environment with our first application since April 2017. Actually, we have eight applications integrated in this solution.

Solution is stable, without any platform outages. We have had a few bugs, but technical support solved those quickly.

No, we did not have any issues with scalability. Our solution runs in HA mode, with two active nodes. It is enough for our usage and current load from integrated applications.

Bugs are very quickly fixed by the vendor. Until now, it has only been a positive experience from our point of view. Also, a platform upgrade was solved with an onsite vendor consultant. Activity was difficult, but it was done without any problems.

As a general statement, we can say that we are satisfied with CA Automic support in all areas that we are cooperating.

We have used only custom deployment scripts (each team has their scripts, we did not have any standards for that), for a solution like this. Major reason for this purchase was our DevOps project. As a short introduction to this project, we started our DevOps transformation at our bank and we were solving problems like build automation, provisioning automation, test automation, and deployment automation as well. We wanted to have one complex DevOps delivery pipeline which consists of all of these interconnected tools, and we made it.

Initial preparation and installation took three months and was very complex. We wanted to prepare the HA and a stable environment, which would need to be ready for massive usage. Actually, we have already integrated eight applications and run over 1000 automated deployments.

They should use a deployment target (or agent) licensing model and start their implementations with a lower number of agents in the beginning.

Yes, for sure. We did more PoCs during the analysis phase of our DevOps project last year. We were testing products: IBM UrbanCode, CA Release Automation, XL Deploy from XebiaLabs, HPE Codar and the winner - Automic ARA.

This product is very strong and, on the other hand, very complex. So they should involve more technical people in the beginning to ensure knowledge transfer, and continuous and quick integrations of applications into this solution. The best option is to create a dedicated automation team before the implementation.

The second important thing is that this solution provides only automated deployment and some orchestration as well, but deployment depends on all steps before, such as build and artifact preparation, testing, and provisioning. So others should use at least the automated build and artifact preparation and interconnect it with deployment. Then, they could achieve bigger benefits from automation.