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.
Archive powered by MHonArc 2.6.16.