We are using:
- single git repo per cookbook
- one git repo per project infrastructure
- cookbook dependencies resolved via librarian-chef instead of berkshelf (due to proxy support)
- application cookbooks instead of roles
This works quite well and is quite sound imho - cookbook dependency management is king!
Within the project infrastructure repo we have a rake task which resolves the cookbook dependencies _per application cookbook_ into <project-infra>/cookbooks/<app-cookbook>-<version>. This honors the fact that application cookbooks may use different versions of dependent library cookbooks (e.g. app-a depends on lib-d 1.0 but app-b depends on lib-d 2.0 and both live in the same project infra)
The only thing that makes me a bit unhappy is that we can not use version numbers like "1.1.0.dev" to differentiate between in-development and stable versions or "1.1.0.my-fork" to differentiate between forks of and original community cookbook versions.
Cheers, Torben
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.