[chef] Re: Standard Practices


Chronological Thread 
  • From: Jesse Nelson < >
  • To: chef < >
  • Subject: [chef] Re: Standard Practices
  • Date: Thu, 14 Mar 2013 00:46:37 +0900

We us one cook per repo (migrated from monolithic repos). With one repo per project/infra that has a berksfile + env/bags/rolls. Internal dev projects in this scenario can get their own  version of the main repo, but all cookbook work happens per cook and each dev/project/infra can lock their versions down in environments + berksfile. This has been IMO the best layout for working with diverse projects and needs. The main goal for us was to capture all work in cooks and make sure there was single source of truth for those cooks. This has worked out much better than the one repo for everything model we moved from. We see less issues with people stepping on toes, and individual cookbook quality has anecdotally gone up. We have ~15-20 people interacting with the cookbooks and a core of about 4 people that are the "main" committers. 



On Thu, Mar 14, 2013 at 12:22 AM, Mark Pimentel < " target="_blank"> > wrote:
I just wanted to get a feeling for what standard practices people are following for managing chef cookbooks.

We will be moving to git internally and I would like to plan out the migration of our cookbooks to git.  What is the best practice for this layout?

One repo per cookbook? or all cookbooks in one repository?
How about databags, roles, environments?

Any feedback would be greatly appreciated.

--
Thanks,

Mark




Archive powered by MHonArc 2.6.16.

§