OneRepositoryVsOneRepositoryPerCookbook

Organizing Cookbooks in Source Control

Starting questions: One big repo? One per cookbook? Should we lock versions for cookbook?

One Central Repository

Benefits

• Central access
• One repo to clone to get started for new developers

Hurdles

• Lots of tests can make CI take time (discouraging small changes)
• Hard to limit based on metadata
• Dealing with branches, easy to make changes in the wrong branch
• Lots of noise in the commit history

One repo per cookbook

Benefits

• Isolation of development and testing

Hurdles

• Can be expensive if using private repos on GitHub
• Can be difficult to get started for new developers (lots of stuff to clone)
• N+1 (do we have a cookbook to manage our getting started)
• Hard to see changes in context with our cookbooks/environments

Version locking

• Use berkshelf and cookbook metadata with cookbooks for cookbook level dependencies
• Use environments or environment cookbooks to control versions for whole environments

With Test-Kitchen - how do we replicate environments? Use Chef Zero and pull from environment data in repo.

Create a repository for your policy file and keep cookbooks in their own repositories with "chef generate" Chef generate repo -p #(to create a repository structure with cookbooks gitignore'd) Chef generate cookbook #(to create a cookbook repository)

Should we have community cookbooks in our ONE BIG REPO? Berkshelf allows you to treat external dependencies as external dependencies.

You should have local cache of external dependencies.

As you scale your team, one repo per cookbook can work better.