Automic Continuous Delivery Director [EOL] Reviews

Automic Continuous Delivery Director can automate the entire release process. Our client, who operates web servers including iOS and Web, needed to streamline their release management process for preproduction and production environments. Our team successfully developed the entire process, encompassing over 30 workflows, with nearly 10 dedicated to the Web and over 20 for iOS. Our client heavily relies on its scalability and appreciates the wide range of out-of-the-box integrations available. Automic's marketplace further enhances its utility, offering numerous connectors for seamless integration with various modules.

We implemented comprehensive release management processes that involve managing the application upgrade agent and releases to target servers hosting applications. We have around 70-80 releases every month.

It transits from development to preproduction to production. This entire journey is automated, ensuring efficiency and accuracy. Automic facilitates integration with monitoring tools, allowing for timely alerts regarding server availability. Additionally, it enables integration with service management tools, monitoring of database tables, and seamless integration with VMware automation and web services.

Automic eliminates a lot of error mishandling. If implemented, it can save a significant amount of money. It requires a substantial investment upfront because it eliminates the need for manual intervention in each process or job. Essentially, an operator oversees the releases, ensuring they are ready for release without needing to understand the intricacies of the process. This streamlines the release process and allows for monitoring at every step, reducing manual errors and providing automation, as the name "Automic" suggests.

Automic offers a wide range of out-of-the-box integrations, available through its marketplace. This includes monitoring tools, release processes, and various other tools, making it a comprehensive solution.

Automate has been in the market for quite some time because of its strong presence and extensive range of available connectors. This feature eliminates the need for manual code writing when implementing solutions, thus reducing coding efforts. Automate provides a wide array of connectors, such as those for VMware, tools, and ServiceNow, making integration seamless. Additionally, Automate boasts a robust workflow engine for automating various processes efficiently.

The product's development has been stopped. It focuses on maintaining existing products.

I have been using Automic Continuous Delivery Director as a partner for six to seven years.

The product is very stable.

I rate the solution’s stability an eight out of ten.

The solution is very scalable. It doesn't require much of an architecture-level change. You can migrate easily. We have a bunch of customers using Automic. Some customers are fairly dependent while some of them have 70 releases.

I rate the solution’s scalability an eight out of ten.

Support is unsatisfactory.

The initial setup depends on the complexity of the infrastructure. It is a fairly big project. The initial steps were quick, but the overall process completed the entire implementation of the release management process, spanning development, pre-production, and production across over 800 servers. It took us almost eight to nine months to complete this part of our release process.

The product has easy licensing, which depends on the number being installed.

I recommend this product. It is a very stable and scalable product that can assist you. However, it's no longer being sold by Broadcom. Only existing customers can upscale; new customers cannot acquire.

Overall, I rate the solution a six out of ten.

Automic Continuous Delivery Director is used to orchestrate and release pipelines.

The most valuable features of Automic Continuous Delivery Director are the UI, release planning, and tracking, and you can do your soft and hard freeze through CDP.

Automic Continuous Delivery Director can improve the integrations. We have 25 but would like more.

I have been using Automic Continuous Delivery Director for approximately five years.

Automic Continuous Delivery Director is modular-based and stable.

Automic Continuous Delivery Director is scalable.

The support is active and my customers are satisfied.

The installation is straightforward. It can be VM based. The process can take one day. However, it does depend on the environment.

There are Linux and Microsoft Windows-based installations. Someone with database knowledge can do the process of installation. 

There is a free trial available that people can try. The solution has a subscription and it is based on the users that use the solution.

The price of the solution can be flexible and there are not any additional charges from the standard subscription.

I rate the Automic Continuous Delivery Director a nine out of ten.

I would advise others to try the solution and see if it fits their use case.

We have approximately 150 customers worldwide.

Application software delivery is the primary use case.

There are many valuable features. For me, it's the fact that you can easily design a pipeline to promote applications from a development environment up to a production environment, and the team can become autonomous in designing those pipelines. In an Agile organization where you are searching for such autonomy, having that kind of capability is very valuable.

The second valuable aspect is its capability to drive external systems like deployment automation engines or to integrate with Agile Central.

What we would like to know is how to use CDD in Agile, at scale, in our organization. We have rolled out the SAFe model, but what we would like to have is better integration with Agile Central, for instance, or at least at the plugin level, where we would select only certain stories, instead of many stories, in the sprint.

We would like to have a more user-friendly interface. It is already very friendly, but as soon as you start to have many applications with many tasks, the applications should be easier to manipulate on the screen.

We would like to have export capabilities to paper because, for auditing purposes, we need to keep them.

We would like to add some documentation inside the tool as well.

This is information we have already communicated to the development team of CDD and they will work on it. 

In addition, there is the testing aspect. It's a strong need now in the market: Not only to deploy/promote an application into whatever environment, but also to be able to execute testing and report on the quality of the application.

Astonishingly, it's quite stable. The quality of the application is pretty good. We haven't had bugs or crashes. It seems to sustain the load we give it. It's working. We haven't had any problems with it.

Scalability is a question for me. You can put more load on it, but the real question is not about the tool itself, it's about the all the new practices in continuous delivery in an Agile, at-scale organization where the basic principles are not yet embedded in the organization. So tomorrow I could select a tool from a competitive company, for instance, XL Relieve or XL Deploy, but I will have exactly the same problems: "How do I define what I put in my delivery/release pipeline?"

There is no secret recipe for that. You have to work with your customer and adapt their way of working to benefit from the tool. Some teams are more agile and are more autonomous than the others and fit perfectly well inside CDD. But if you take mainframe applications, most of the time they are big, monolithic applications, and it is the applications which are a problem to fit inside CDD. In that case, you need to be able to work with those users and find solutions so that continuous delivery brings value. Otherwise, you just have deployment automation which is of minimal value.

So the tool can scale, but it cannot scale faster than the way you change your organization.

I like technical support very much because I've been in contact with the development team from the very beginning. I'm in a somewhat special situation, but they have been helpful from the very start. They were eager to listen to our change requests.

But I also think that the development of the tool should go faster. The market is moving very fast, and I think it's very important that CA realize what its customers are asking. I need to push CA to get my new requests or improvements because my own customers are requesting them. 

They're eager to listen, to propose, to understand. They deliver it. But now it has to go faster. Otherwise, people will say, "Okay fine, the tool is there, but we want to see it evolving."

It might be that due to the recent acquisition by Broadcom it might have slowed down. Sometimes my users sometimes are wondering will the tool stay or will they have to change tools? They see other tools coming on the market, so the competition is starting to be there. There will be more pressure on the CDD team to deliver newer versions. They do release multiple times a year. That's very fine, but I think they should release even more often. That's probably why they are going to the SaaS version as well.

It's very straightforward, technically, to deploy the tool. To use it at a small scale it works. The problem is when you go Agile at scale, you encounter problems with who owns a release. Do we give autonomy to squads or should it be the tribes that have autonomy? Then the question is, what do you put inside those pipelines? Do you want to work in project mode, or do you want to work in a more product-oriented mode?

When you introduce a tool like CDD, technically it's easy to run, very easy, even if you run with containers or run the SaaS version. It's very easy to integrate it. But it's the cultural shift which is much more difficult to achieve, and this is proportional to the size of an organization and the way it works. I'm in a context here where we have a very large organization and our Agile process is not that mature. Therefore, we still work in a pure ITIL way, very Waterfall.

When you introduce a tool like CDD, you tend to shift left. You tend to give more agility and, therefore, people need to be trained. All of that has nothing to do with the tool itself. It is more about the cultural shift, as well as achieving continuous delivery in an organization that was strictly controlled by a release process which was extremely manual. You encounter a lot of resistance because you replace jobs with automation. It provides greater flexibility for certain teams, but you are really changing the organization. 

It brings a lot of value when you look at the organization completely; what it can change and make faster and better. But the people have to change their way of working, their culture. They have to trust more, they have to change their roles as well. This is the most difficult part when you use a tool like CDD. You could use whatever other release automation tools or continuous delivery tools and you will encounter exactly the same problems. The problems are not related to the tool itself but more to the concept behind the tool.

In terms of deploying CDD, they provide a containerized version or you run it on your own application server. In our case, within a month we had the environments provisioned: Dev, QA, and production, and everything was set up and integrated.

Our implementation strategy was, first of all, to do a PoC to check if what we were expecting from this type of tool - meaning integration, its capability to provide autonomy and visibility to teams - was as expected. Then we did a deployment in a Dev and QA environment, where we re-integrated it with external systems in the organization and then we delivered it to production, into the test centers. First of all, we were working in the Active-Passive mode, but now we are moving to an Active-Active mode in production.

We had coaches coaching squads to use the tool. What we see now is that we have to re-engineer the release process to stop working like before, where teams were only delivering up to QA. To make things more autonomous, delivery should be up to production. That means enabling a DevOps strategy, which is something that has to be taken into account in an Agile strategy as well.

That's where we are right now. Some teams have become autonomous and use the tool without our supervision. They roll it up to production. They see benefits because they no longer have to follow "run books." Run Books were the set of stuff they had to execute which were contained in Excel sheets. Everything is tracked inside the tool. And when they introduce automation behind the scene, what we see is that everything is reproducible from very environment - Dev, QA, and Production. And it happens just by clicking the button on the screen. That works. It fosters collaboration between the operational team and the development team which, before, was broken or hidden behind a wall.

To deploy CDD we requested our infrastructure, we got unique servers, we got databases, etc. We had two employees delivering CDD, and now those two people are running the platform. But they do many things in addition. They are DevOps engineers.

I am from a consulting company and I provide the integration and the rollout services for CDD, Agile Central, and Release Automation.

I looked at other solutions from other companies. At that time, CA was not ready with its solution. Luckily, we were stuck in the decision-making process with budgeting, etc. Then, CA came out with the early CDD. It was quite promising so they put a lot of effort into being on time. They came out with a first version which fit our initial purposes. That's why we went to CDD. 

It was very lightweight to install. Other tools needed a lot of expertise and infrastructure. But now, other tools are known in the market. I think we made the right choice but those competitors also make strong arguments to be present in big enterprises. Again, it is not the tool which makes the Agile way of working work, it is the people using the tools.

We looked at solutions from IBM, Microsoft and, recently, solutions from the company that created XL Release. It is interesting, but for me, it is still the same as CDD.

As I said above, a tool is just a tool. What you need to do is more along the lines of thinking about how to roll out usage of the tool inside your organization. Rolling it out for a couple of teams is very easy. Rolling it out for people who are eager to change their way of working is very easy as well. If you work in an organization that does not have a long history with hundreds and hundreds of applications and rules and policies to follow, it usually means the employees are free to work in their own way. We benefit a lot from that. But as soon as you need to go Agile and respect regulations, when you have a huge legacy behind you, the tool will be there and will be used, but you first have to break that big monolith and change the way of working. Then you will benefit from using the tool.

For continuous testing, we are implementing a solution based on CDD and external tools because we want to deploy an application inside an environment, test it, and automatically promote it to the next one if the quality is met. Unfortunately, today in CDD, we don't have that capacity to integrate the testing yet. I know there is a Dataset Repository coming, but I have never used it.

We use CDD for the continuous delivery pipeline and we integrate it with a continuous integration platform like Jenkins. It's needed because we want to be able to deliver faster and with better quality. We want the developers to know the changes they are making in the applications or in the product that they're running in production. They should know all the changes and how to test it with the testers. In a DevOps organization, you want everything on the same page and, in the pipeline, you want to have visibility into what's going on, what is delivered where, and what the quality is. That way, when you deploy up to production, it's kind of a non-event. You are sure that it will work if you have previously deployed everything properly in QA.

In terms of tracking user stories and fixes within the release pipeline, we have demonstrated these capabilities in a PoC and in some test environments, but not yet in a production environment. To have it properly tracked, your organization needs to have enough maturity in its Agile processes. We are currently running out "Agilification" at scale, and therefore we need to have the proper squad and tribe organization. We need to properly size and design each feature and story and have the proper state. Currently, for instance, people are not in agreement on what an accepted state for a story is, or what an accepted state for a feature is. Therefore, we have the capability in the tool - we demonstrated it - but today the business still has difficulties tracking the progress of stories and features in Agile Central. Therefore, providing automation in CDD, where we update both systems with CDD, seems too early. But our aim is to do it. We have demonstrated it, we have run it in PoC and it works. But the question is, how can we scale the Agile way of working to an organization of 2,000 people? This is the pain point today.

Getting there would be the most important business value because then, everyone - even the business - could track the delivery of business value. That's the plus of the tool. If it could integrate the testing, and by that I mean the quality aspect, it would mean that the product owners and business could release autonomously and have a complete view into the quality of what they release. Then, CDD would become an orchestrator, just executing the delivery of a pipeline. But the goal is to reduce all manual intervention to the minimum. Basically, we would shift-left all activities and control to the business, so that they could track and act on the delivery of that business value.

We are delivering something like 140 applications and that needs to increase to more than 350. We have 25 groups or squads of users. Each squad can have between four and eight people, sometimes twelve. So we have something like 150 users. But we don't manage users individually, we manage groups of users.

The majority of the teams are DevOps teams, but we still have transversal teams which need to become more DevOps. For that, we have to break the way they work, to split those teams and move them into squads. But then the question comes up about the ownership of what previously belonged to the transversal team. It has to move to the business squad or the product squad. The definition of those products goes alongside the change in the organization. We support both models and we roll out CDD at the same time we roll out the Agilification.

We even use CDD to deploy its own plugin. We have multiple instances of CDD, one in Dev, one in QA, and one in Production. We use the Production instance to deploy plugins that are a component of CDD, into our own CDD. In our squad, we also have other applications and we used the same CDD to deploy those same applications.

From a customer point of view, the customer comes with a new application. We look at the technology, we automate the technology to deploy that application. It could be a WebSphere application or it could be an Oracle database, etc. We train them on how to use CDD and give them the autonomy to deliver their application, given that we have automated the deployment task and integrated it with the test automation team. That team then provides the test automation capabilities, such as running a performance test or running a load test. That is not our specialty. Our specialty is orchestrating the delivery and deployment and to trigger tests.

I know other organizations that have deployed the solution here in Belgium, and we often meet to discuss our progress. Because, like I said, deploying the tool is easy, but using it properly to benefit an Agile-at-scale organization is difficult. It's difficult to "Agile-ify" at scale. We discuss how to do that properly, and how to benefit from the tools, whether it's CDD or Release Automation. They often go together. In addition, customers might have JIRA or Agile Central. I'm lucky, I'm using the three: Agile Central, CDD, and Release Automation. They are quite well integrated.

Compared to what I have seen on the market, I would round it up to a nine out of ten. It's the simplicity. It's very simple to use and deploy and deliver. And it works.

The reason it doesn't get a ten is that you need knowledge about what you are doing, about the shift in control and responsibilities. People get autonomous and you then have resistance. I don't think it's due to the tool. But it could still be improved maybe on those aspects, by providing more controls or permissions and the like. And the other thing that is missing is the test automation or tracking. But I know it's coming.

Delivery of business applications.

Agile and DevOps teams can now self-organize to deliver applications autonomously.

The most valuable feature is the thorough coordination of software delivery across multiple environments. Multiple actors (typically business stakeholders, devs & ops engineers, release engineers, testers, and change managers) can easily cooperate to ensure a proper and repeatable delivery, by combining constant follow-up on manual and automated activities.

Reporting and dashboarding could be improved. Release pipelines should be creatable via templates as well as easily integrable/chained together. Visual navigation could also be improved when the pipelines become too large.

No issues with stability.

Scalability is fine, up to hundreds of pipelines. Above that, the user interface might become a limiting factor.

Tech support is good. The tech support team is easily accessible.

Initial setup can be done in days. The most complex part is the organizational change around the tool.

Consider extra licenses for additional release pipelines (maintenance or hotfix releases, for instance).

Micro Focus Release Control (formerly Serena Release Control), Microsoft Team Foundation Server, and IBM UrbanCode Release.

Implementation should focus on Agile and DevOps teams. Plan it to gradually create a scalable organization.

We are using this in conjunction with CA Release Automation. RA has trimmed hours of deployment time down to minutes. We are hoping the CDD GUI will be able to provide better visibility for deployments.

Its ability to automate release deployments, streamline release scope, and reduce the cost of and time for deployment. 

It rollbacks when toll gates fail. 

CDD is primarily used for showing end users (managers, business teams, project managers, and release managers) what is happening with each release. The status and reporting features are very important. Automation reduces time to deploy. It also allows us to do more with releases and testing prior to production, better guaranteeing a smooth deployment. 

We also like the ability to clearly rollback changes when releases fail. The tool does not have automated rollback, but it’s very clear which steps failed. Thus, we know when to start the rollback process.

CDD and RA should be two modules in the same product. They do not automatically “talk” to each other. and they require endpoint definition. If changed, we wouldn’t have two separate strategies for the tools since everything was in one tool. Both products could orchestrate and have overlapping capabilities. At the moment, we have to think about the strategy for each product. It would be great if CA RA and CDD were rolled into one product. CA RA is the “brains”, and CDD is the GUI/display.

No issues with stability.

We have not encountered any issues with scalability.

Technical support is good. Their consulting service is fair since they do not have many SMEs for CDD. But technical support has been strong.

The product is easy to learn but we are experiencing many firewall issues that have prevented a successful launch of the product.

We have not had issues with pricing/licensing.

We did evaluate other options but I was not a part of the evaluation phase. We picked this product to work as part of a suite with CA Release Automation.

Make sure you understand your firewall environment and decide up-front if you are using CDD or RA for orchestration.