[debops-users] Opinions on Ansible role repository layout

This is a cross-post from a mail of one of the DebOps users, I thought that others might be interested in the topic. On Feb 08, Nicolas Quiniou-Briand wrote: Hello, I'm obviously biased, so please keep that in mind. The choice depends on a few factors. How many roles do you plan to manage at once? Are they completely independent entities, or do they work together in some fashion? How many people you have available to maintain them? You should probably read the mailing list threads in which I talked about merging DebOps into a single repository: https://lists.debops.org/pipermail/debops-users/2017-August/000078.html https://lists.debops.org/pipermail/debops-users/2017-September/000096.html And here's the afermath of the merge: https://lists.debops.org/pipermail/debops-users/2017-October/000102.html I also wrote about this very subject on Reddit: https://www.reddit.com/r/ansible/comments/9n3p37/develop_roles_with_git_b... actices/e7k7gza/?context=0 But pros and cons of each model? Let's see... Pros of separate git repositories: - it's easier to hand a role or a few of them to somebody else if you don't want to deal with them anymore - separate teams can work on one set of roles independently, each one having access to specific repositories - it's a simple publishing model, estabilished by Ansible Galaxy, easy to use with a limited number of roles (10-20 max, I'd say) Cons of separate git repositories: - scales horribly unless you write your own toolset to handle large number of repositories - lots of overhead when you want to synchronize multiple roles together and rely on Galaxy to distribute them, because Galaxy uses git tags to handle versioning. Tags, tags everywhere... - if you want to use GitHub for issues and pull requests, prepare to deal with issues and PRs per-repository. There's no good way to centralize it, unless you create a dummy "issue repository" which only confuses users, and you still need to deal with PRs per repository anyway. Pros of a monorepo: - everything in one place - roles, issues, pull requests, additional tooling, everything in lockstep. Awesome with a large number of roles. - you just have to install one git "package" and all of your roles are available for consumption. You can still use specific roles in playbooks, there's no downside here. - git grep over everything. What do you mean, everything? EVERYTHING! Cons of a monorepo: - existing tools around Ansible like Molecule are geared towards a single role per repository model. If you go with a monorepo, you probably will have to create a custom toolset for it as well, but the problems you have to solve will be different. - everything is in lockstep, which might be a problem when you have multiple teams that want to move at different pace. Scheduling tags/releases based on time could be a solution to that. - everyone gets the entire repository / all of the roles. Depending on preferences or application, that might not be a desirable thing to have. Ansible Galaxy actually has a very nice support for multi-role repositories now. I'd say that if you want to start publishing roles from scratch, going with a multi-role repo is much more benefical. The single Ansible role per repository was forced on everyone because of limitations of Ansible Galaxy at the time. It's all better now, go with the monorepo. Do you mind if I cross-post it to the DebOps mailing list? It might be an interesting discussion, I wonder how the monorepo looks from the users' side. Cheers, Maciej