One repo per role is the general advice, but it does depend a bit. We built 
a body of over 200 roles at my last job, and over time we found that 
managing a 'package' of know good versions got very unwieldy, and people 
had trouble managing their requirements.yml. Our first solution was to 
build a 'bundle' of roles. So, the devops central team published a package 
of all 200+ roles once per PI, and projects just unzipped the whole thing 
into their build folders as part of CI/CD pipeline. In my new job, I'm 
taking a different approach and using a mono-repo of all the roles and it 
seems to be working well. It has a lot to do with who will use the roles. 
In our case, we have a ton of devs who dont have the time or inclination to 
keep track of versions, or deug issues. They just want a bundle that has 
been tested and is know to work.

On Tuesday, January 26, 2021 at 1:21:04 PM UTC-6 [email protected] wrote:

> Thanks!!  There's definitely a lot to think about here for sure.  I 
> appreciate the information!!
>
> --John
>
> On Mon, Jan 25, 2021 at 5:19 PM Jean-Yves LENHOF <[email protected]> 
> wrote:
>
>>
>> Le 25/01/2021 à 16:03, John Petro a écrit :
>> > Good morning,
>> >    I am working on setting up an ansible repository, for work.  We are 
>> > going to be using AWX eventually ( sooner rather than later ).  What I 
>> > am wondering, is how people decided to split up their ansible project 
>> > directories. My first thought was to just have a single project with 
>> > all of our playbooks in that but I am starting to question whether 
>> > that is the correct path or not.
>>
>> Not so obvious to answer !
>>
>>
>> >
>> > Along with that, when it comes to source control, are you storing your 
>> > roles in a separate repo per role, or all in one repo.  For myself 
>> > personally ( homelab ), I have a single project, and all of my roles 
>> > have their own repo, but I am not sure how that scales to a larger 
>> > organization.
>>
>> One role per repo with version tags !
>>
>> Like this you can use version in your requirements file and decide which 
>> version is working for you in your context. Periodically you need to 
>> update versions and make some adjustments to code after testings !
>>
>> The more a role is going to be used by different people, the more you 
>> will need a concensus about changes and decide what change can be done 
>> in in a minor and in a major release version !
>>
>> Regards,
>>
>> JYL
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/ansible-project/b8e10d84-4a41-dc3c-52c8-99433327c2a6%40lenhof.eu.org
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/7d172c6b-9253-4937-98e2-c8520455e027n%40googlegroups.com.

Reply via email to