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.
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.
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.
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...
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.
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.