[chef] Re: Re: Single Repo vs Repo per cookbook

[Torben Knerr < >]

Have not used the Berkshelf rel: option personally, but one thing that
gets messy is that you are mixing up tags when version-tagging your
cookbooks.

In Git tags are global per repo, i.e. you can't tag on a subdirectory
level as you can in svn. So this would result in having tags like:
"company-apache2-v1.0", "company-php-v0.9", etc... if you want to
version them individually.

It's probably not a Chef specific issue at all but like a general Git
repo structure problem. My rule of thumb is "one Git repo per
versioned entity", so:
=> if all your org cookbooks have a common release cycle and are
version together -> use a single repo
=> if your org cookbooks have different release cycles and are
versioned independently -> use one repo per cookbook

Not even sure whether Berkshelf would handle that gracefully if you
have 2 cookbook dependencies using rel: that are in the same repo but
checked out at different commits / tags...

Cheers, Torben



On Mon, Apr 13, 2015 at 10:17 PM, William Jimenez
<
 >
 wrote:
> I've been talking to a lot of people in the community about this as well,
> and the short of it has been, while there is an overall trend towards a
> single repo per cookbook (and value in that model), either approach has
> tradeoffs. And there is something to be said for a hybrid approach that
> embraces both ideals, and this can be a good stepping stone towards an
> optimal solution.
>
> I realize you're looking for a more specific answer, but just wanted to
> share that general observation.
>
> -William
>
> On Mon, Apr 13, 2015 at 11:49 AM, Yoshi Spendiff
> <
 >
>  wrote:
>>
>> Hi,
>>
>> I know this horse has been flogged to death but I've a slightly different
>> permutation on the question that I'm having trouble working out.
>>
>> I'm fully on board with having cookbooks be isolated objects with their
>> own dependencies, using Berkshelf and testing cookbooks in isolation, but
>> I'm in a situation here where we're putting in a new Chef implmenetation 
>> and
>> I need to convince people here to use one repo per cookbook with examples 
>> of
>> why, otherwise it will be done in one repo. It's easy to show arguments for
>> why cookbooks should be essentially independent and developed/tested as 
>> such
>> but I'm not sure that necessarily means they have to be in their own
>> repository each.
>>
>> The other way around this that I can see is to simply use directories
>> under the cookbooks repo to do the same thing (not a chef repo, more just
>> like a cookbook specific repo). So you would have a structure like this:
>> -cookbooks_repo
>> --company-apache2 (wrapper cookbook)
>> ---Berksfile
>> --company-php (wrapper cookbook)
>> ---Berksfile
>> --company-cookbook (role containing cookbook)
>> ---Berksfiles
>> ---recipes\webserver.rb
>> ---metadata.rb (pointing to company-apache2 and company-php)
>>
>> The Berksfiles for the downstream cookbooks could reference the others by
>> git ref using rel: option for a directory, which is how the separation is
>> achieved. Each cookbook would also have it's own Vagrantfile for testing 
>> and
>> metadata dependencies listed.
>>
>> I guess the problem I'm having is I don't really see any major
>> disadvantage of this myself, so can anyone help inform me why I should use
>> one cookbook per repo instead of managing them in directories like this 
>> (but
>> still treating them as essentially separate objects otherwise). All I could
>> think of was it means people might work on two cookbooks in a single
>> branch/commit, but I'm not sure that's necessarily a bad thing.
>>
>> I should also add that these are all internal cookbooks that are company
>> specific, they would never be shared in the community.
>>
>>
>> --
>> Yoshi Spendiff
>> DevOps Engineer
>> Indochino
>> Mobile: +1 778 952 2025
>> Email: 
>> 
 
>
>