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 is easy to learn but we are experiencing many firewall issues that have prevented a successful launch of the product.

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. 

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.

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