Automic Continuous Delivery Automation [EOL] Reviews

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.