Cookbook Best Practices

If we're adopting a cookbook and trying to bring it up to scratch, these are likely the first things people will expect.

Platform Support

We will attempt to support all operating systems releases currently supported by the OS vendor except where there is a compelling reason not to.

Current major operating system support lies in the following:

  • Centos
  • Ubuntu
  • Redhat
  • Amazon Linux 2
  • macOS
  • Windows

Some cookbooks are not designed to support all of these operating systems. For a full list of supported operating systems please refer to the kitchen.yml in the cookbook in question

Custom Resources over Attribute Driven

Our cookbooks are application cookbooks, and therefore designed to only manage a single type of application at a time. For example, a PostgreSQL server.

All configurables should be surfaced through a easy to understand, custom resource (opens in a new tab) interface.

For example the postgresql_client_install resource (opens in a new tab), surfaces a version property. Which is obvious to the user. Much like a template, or file resource.

postgresql_client_install 'Client install' do
  version '9.5'

Resource Documentation

README docuemntation can get very long and hard to navigate. Splitting information down into easily digestable information is crucial in users being able to effectively use the cookbook.

Example structure:
── documentation
│   ├──
│   ├──
│   ├──
│   ├──
│   ├──
│   ├──
│   └──
  • The should have links to both resource documents
  • The resource documentation should have the following headings:
    • resource title
    • a table of available properties
    • a set of examples using the resource


Our cookbooks follow semver guidelines. See the semver spec (opens in a new tab) for an overview. Semver allows allows cookbook consumers to better understand what version increments mean and plan their testing regiment accordingly