It is all very well stating that Ansible playbooks should be cloned from a version control system and cloned to the systems from which they are to be run (be that from the command line or AWX), but how do you actually organize these effectively so that you can find your code when you need it?

A clue comes to us from the user interface of the AWX tool, which refers to each version control repository you might reference as Project. As you build up your automation processes and solution, you could end up with many playbooks, possibly into the hundreds, depending on the size of your enterprise. 

You can, of course, store all of these within the same repository. The ansible-examples repository is a good (albeit smaller) example of this—it contains a variety of playbooks for different purposes, each within its own directory. There are even Windows-specific playbooks that live under a Windows subdirectory. The directory structure is relatively easy to navigate for you to find playbook that you want, but you will note that all of the code contained within it are examples for people to learn Ansible with.

If you worked for an online retailer, for example, it would not be logical to put the playbooks for building the standardized Linux images into the same repository as the ones for deploying your stock control system. This would be counter-intuitive and would lead to confusion, especially when people are looking for a particular playbook.

Naturally, the decision comes down to you at the end of the day—only you can decide on the structure that will suit your enterprise best. However, the division of repositories by project is a good starting point for anyone looking for a sound starting point to build on.

There will always be gray areas too – for example, in Chapter 12, Performing Routine Maintenance with Ansible, we advocated building Ansible playbooks for performing frequent housekeeping tasks such as cleaning up disk space. Now, suppose you have a playbook that cleans up a directory structure, but that it is specific to the stock control system we mentioned earlier— does that go in the stock control repository or the general maintenance repository?

Again, the choice is yours—but the stock control cleanup playbook will not run properly (and might even be dangerous) on systems that do not run the stock control system, so I would advocate making it a sub-directory within the stock control repository.

So far, we are building up a picture of how you would effectively and efficiently store your playbooks, yet we must remember that, throughout this book, we have strongly advocated the authoring of Ansible code as roles wherever possible, as roles can be reused in multiple playbooks. None of the solutions we have discussed actually support role reuse (other than manually copying the code between playbooks), even though we have established a sound methodology for building up our directory structures and processes for running the playbooks.

In the next section, we will look at the specific capabilities of Ansible when it comes to the version control of roles.