[chef] Re: Re: Re: Workflow of Making, Testing and Using a Cookbook?

["Julian C. Dunn" < >]

On Mon, May 19, 2014 at 10:53 AM, Matt Stratton 
<
 >
 wrote:
> Julian,
>
> Not to go off on a tangent, but I'm curious about a statement in here. You
> mention that the cookbook should not be "using git submodules or any of that
> funny business".
>
> What would be the negative reason for putting chef-repo in source control,
> and then all cookbooks in their own repos, but putting a submodule of each
> cookbook under the cookbooks directory of the chef-repo? I've been working
> on a few projects where we intended to do this eventually, and just haven't
> done so yet. What issues/problems might I not be realizing? :)

A submodule is pinned to a particular Git hash, so you wind up in a
whole world of maintenance hell when you want to get a consistent
state for your top level. example: if I 'git submodule update' to get
to a new hash, I'm immediately impacting everyone.

I usually set things up like this for customers:

+ chef-repo [its own Git module, with a .gitignore containing cookbooks/*]
  + roles
  + environments
  + data_bags
  + cookbooks (empty directory, maybe with a README.md in it
explaining why it's empty)

and then a Git module per cookbook.

The workflow for someone starting with Chef at that company would be:

* Clone chef-repo
* cd into cookbooks, clone individual cookbooks as needed

Yeah, there's Berkshelf, and upstream dependencies, and all that jazz
I haven't accounted for. But when people are first starting out, the
most important thing they are interested in doing is to start writing
some Chef code immediately without having to learn a pile of tools.

- Julian

-- 
[ Julian C. Dunn 
<
 >
          * Sorry, I'm    ]
[ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ;]
[ gopher://sdf.org/1/users/keymaker/           * compliant!    ;]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]