One of the challenges a company faces when it wants to apply a DevOps culture is the choice of tools.

Indeed, there are many tools that are either paid for or free and open source and that allow you to version the source code of applications, process automation, implement CI/CD pipelines, and test and monitor applications.

Along with these tools, scripting languages are also added, such as PowerShell, Bash, and Python, which are also part of the DevOps suite of tools to integrate.

So it's a question I'm often asked: how do I choose the right DevOps tools that are useful for my company and business?

In fact, to answer this question, we must remember the definition of DevOps culture provided by Donovan Brown, which was mentioned in Chapter 1, DevOps Culture and Practices:

The important point of this definition is that DevOps culture is the union of Dev, Ops, processes, and also tools.

That is to say, the tools used must to be shared and usable by both Devs and Ops, and should be integrated into the same process.

In other words, the choice of tools depends on the teams and the company model. It is also necessary to take into account the financial system, by choosing open source tools, which are often free of charge; this is easier to use them at the beginning of the DevOps transformation of the company. That is not the case of paid tools, which are certainly richer in features and support, but require a significant investment.

Concerning scripting languages, I would say that the choice of language must be made according to the knowledge of the teams. For example, Ops teams that are more trained on Linux systems will be able to make automation scripts better with Bash than with PowerShell.

In this book, we have introduced you to several tools, some of which are open source and free, such as Terraform, Packer, Vault, and Ansible, and others that are paid for, such as Azure DevOps (for more than five users) or LaunchDarkly, and this is to help you better choose the tools that best suit you.

After this reflection on the choice of tools in the implementation of DevOps practice, we will look at another good practice, which is the fact of putting everything in code.