Dear fellow Chefs,
I am lucky enough to have on my team several developers that are very
motivated to learn how to create their own cookbooks. Among them is our
maven, jenkins, artifactory build engineer who may get as involved with
Chef as I am already. All told, I am looking at least four people including
myself who may contribute regularly to a common set of cookbooks. Right now
I am scratching my head a bit about how to coordinate all of these people.
I am the only sysadmin on the team.
Currently I plan that our Build Engineer will be a “chef-admin” along with
me. We will be the only people allowed to use knife against our production
chef server. The other two “chef-users” would only have knife access to a
development server.
Here are the different strategies I am considering
Approach #1 : Chef-jenkins
If you are not familiar with chef-jenkins (
https://github.com/adamhjk/chef-jenkins) it essentially syncs your
chef-repo in git continuously with chef-server via jenkings
2 chef servers: Dev-chef and Prod-chef
1 big, fat chef-repo
Only Prod-chef would be connected to chef-jenkins. Dev-chef is a playground
not connected to continuous integration
Only chef-admins can commit to the main “corporate-chef-repo” in git
All of the 4 chef users–admins and non-admins–have knife access to
Dev-Chef
Workflow:
chef-users maintain their own git-repos of "corporate-chef-repo"
chef-users hack on cookbooks and can use Dev-chef and any connected vms to
it (not many) to test their cookbooks, databags, roles, etc.
chef-admins can pull from those git-repos into development branches and
test them on Dev-Chef as well
When chef-admins are satisfied w/ a given cookbook, they can merge it into
master corporate-chef-repo
Chef-jenkins syncs the master branch with Prod-chef
If a change needs to be pushed faster, one of the chef-admins can use knife
ssh to trigger a chef run
Pros:
Conceptually very simple as our team already uses jenkins heavily.
Cons:
Makes it very easy for different cookbooks, roles, databags to become
tightly coupled and/or interdependent. Thus a big wad of nasty spaghetti.
We have no tests yet for our cookbooks 
making continuous integration
pretty dangerous
Approach #2: Much simpler, individual git repos for each cookbook
2 chef servers; Dev-chef and Prod-chef like before
Only myself and the build engineer (chef-admins) have knife access
Git workflow:
chef-users maintain their own git-repos of “corporate-chef-repo” plus
create new git-repo for each new cookbook they create
chef-users hack on cookbooks and can use Dev-chef and any connected vms to
it (not many) to test their cookbooks, databags, roles, etc.
chef-admins can pull from those git-repos into development branches and
test them on Dev-Chef as well
When chef-admins are satisfied w/ a given cookbook, they then pull any
related databags, roles, environments into a development branch and test on
Dev-chef (here be dragons)
Once satisfied w/ a cookbook and any related databags,roles, environments,
chef-admin uploads the related items to Prod-Chef
If a change needs to be pushed faster, one of the chef-admins can use knife
ssh to trigger a chef run
Pros:
decouples databags, cookbooks, and roles
Makes it easier to maintain individual cookbooks
Cons:
Workflows much more complicated
Easy to lose track of the “context” that a cookbook lives in (databags +
cookbook + role)
My jenkins-loving devs won’t “get it” or see the benefit of keeping each
cookbook in its own gitrepo. This doesn’t use the metaphor thay they are
used to.
@fearoffish would esp. love to hear your thoughts on this topic