This was a brief presentation at the Boston Chef Meetup on Fiksu's use of Berkshelf.

1. Using Berkshelf
Evolution in Cookbook Development at
Fiksu.

2. What is Berkshelf?
● A Cookbook authoring productivity tool by
Jamie Windsor and the Riot Games crew.
● Replaces some functions of knife (cookbook
download / upload / create)
● A package manager of sorts (think bundler
for cookbooks)

3. Why Berkshelf?
● Simplifies collaborative development.
● Promotes wrapping and extending public
cookbooks.
● Greatly simplifies cookbook and dependency
upload process.
● Seamless vagrant integration. (via plugin)

4. “The Berkshelf Way”
1. Work in verticals from the outside in:
● Start with the application cookbook and work down through the
dependencies.
2. Favor Data-driven Cookbooks:
● Cookbook attributes preferred; tune on an environment level.
3. Write well-encapsulated Cookbooks:
● Stop using Roles. They aren’t immutably versioned and add additional
setup and complexity for users. Cookbooks should be self-contained.
4. Have short iteration loops:
● Use vagrant with berkshelf plugin to greatly reduce iteration cycle time.

5. Berksfile
● Think Gemfile; tells Berkshelf where it
should look for dependent cookbooks:
○ cookbook “nginx”, chef_api :config (Your chef server)
○ cookbook “nginx”, site :opscode (Opscode Public Cookbooks)
○ cookbook “nginx”, git: 'git://github.com/opscode-cookbooks/nginx.git'
○ cookbook “nginx”, path: '/Users/bob/cookbooks/nginx'
● You can tell Berkshelf to use your metadata
file:
○ metadata

6. Fiksu specifics
● Application, Wrapper, Utility Cookbooks
○ All explicitly namespaced.
● Cookbook metadata is the source of truth
○ depends statements in metadata.rb constrain
versions, not Berksfile.
● Chef Environments
○ Use of metadata makes production constraints much
simpler.
○ Staging is unconstrained
■ Promotes faster iteration cycle
■ Reduces Ops overhead/bottleneck
● Roles
○ For now, a placeholder that binds our base role with
an app cookbook.

7. Fiksu’s Berksfile
# Check our hosted chef server first. Looks for the chef configuration
# info in ~/.berkshelf/config.json. If not there, run 'berks configure'.
chef_api :config
# Now look at the community cookbooks.
site :opscode
# Finally, reference the metadata file in the cookbook.
metadata

8. metadata.rb
maintainer "Fiksu Inc."
maintainer_email "xxxxxxx@fiksu.com"
license "All rights reserved"
description "Installs/Configures Fiksu’s awesome app!"
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
name “fiksu_awesome_app”
version “1.0.0”
depends "fiksu_nginx", "1.1.4"
depends "fiksu_redis", "1.2.3"
depends "monit", "0.0.15"

9. The Past
● All chef artifacts (cookbooks, roles, envs, etc.) in one
giant chef-repo.
● Adding or extending public cookbooks was painful and
sloppy… git submodules were less than ideal.
● A very role-centric environment; tough to easily see the
“big picture” while working on a single cookbook.
● No use of Vagrant for testing. Everything was uploaded
to Hosted Chef and tested in EC2… cookbook testing in
isolation was impossible.

10. The Present
● One cookbook per repo.
● All Application Cookbooks use Berkshelf and Vagrant
for much faster iteration cycles.
● CI: Use TravisCI for linting (foodcritic) and syntax
checks (knife cookbook check).
● Little to no test coverage with chefspec/fauxhai or
minitest-handler.
● Still using roles.

11. The Future
● Well defined cookbook development workflow process
that empowers both dev and ops as productive
cookbook authors.
● Matured CI workflow (automated cookbook uploads to
chef-server, etc.).
● Embrace TDD in cookbook authoring is a must.
● Roles days numbered?

12. Some references:
http://berkshelf.com/
http://www.opscode.com/blog/chefconf-talks/the-berkshelf-
way-jamie-winsor/
http://alluvium.com/blog/2013/05/03/the-application-
cookbook-pattern-berkshelf-and-team-chef-workflow/
http://realityforge.org/code/2012/11/19/role-cookbooks-and-
wrapper-cookbooks.html