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
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:
–company-apache2 (wrapper cookbook)
–company-php (wrapper cookbook)
–company-cookbook (role containing cookbook)
—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.
Mobile: +1 778 952 2025