[debops-users] Opinions on Ansible role repository layout

Maciej Delmanowski drybjed at drybjed.net
Fri Feb 8 10:36:12 CET 2019


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:
> I will start to share Ansible roles for the PacketFence project on Github
> but I wonder what is the best repository layout for Ansible Galaxy : one
> repo with all roles or one repo per role. I notice that on DebOps project,
> all the roles are located under one repo.
>
> I just want to know what are the pros, cons and limitations of this
> repository layout from your point of view.

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_best_pr
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <https://lists.debops.org/pipermail/debops-users/attachments/20190208/6c297d12/attachment.sig>


More information about the debops-users mailing list