[chef] developer -> chef-admin workflows?

[Bryan Berry < >]

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