Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Berkshelf.lock usage pattern

Goal

We'd like changes to our Cookbooks to be automatically tested and deployed using our CI system. Additionally, these Cookbooks must also be automatically propagated to our end-users (developers).

Workflow (today)

Our current workflow is as follows:

  1. Jim, the developer, commits a change to the webapp Cookbook, and pushes that change to Github.
  2. Jenkins, the Continuous Integration system, checks-out the updated webapp Cookbook repo and runs its tests using test-kitchen.
  3. Jenkins, upon successful completion of the webapp Cookbook tests, creates a tag using thor-scmversion and pushes the tag to Github.
  4. Jenkins, also upon successful completion of the webapp Cookbook tests, checks-out the infra repository and runs its tests using test-kitchen.
  5. Jenkins, running the infra tests, checks-out the latest tag of the webapp Cookbook from Github.
  6. Jenkins, upon successful completion of the infra tests, uploads the latest version of the webapp Cookbook to our Chef Server.
  7. Jenkins, also upon successful completion of the infra tests, runs chef-client on our staging server.

Problems

There's a few problems with our current workflow:

  1. If we check the infra repo's Berkshelf.lock into Github, we can easily propagate Cookbook version changes to our end-users.
  2. If we check the infra repo's Berkshelf.lock into Github, we cannot easily integrate Cookbook version changes into our infra repo using out CI system (that is, we wouldn't want the CI system running berks update && git commit -av 'berks update' would we?)
  3. If we do not check the infra repo's Berkshelf.lock into Github, we cannot easily propagate Cookbook version changes to our end-users, as they may have stale at-rest Berkshelf.lock files.
  4. If we do not check the infra repo's Berkshelf.lock into Github, we can easily propagate Cookbook version changes into our infra repo witout having the CI make any git commits or run berks update (the CI system automatically deletes the workspace directory when it starts to build a job).

Essentially, if we check Berkshelf.lock into the infra repo, it's easy for us to propagate updates out to our end-users, however, this makes it difficult for upstream CI tests to propagagte their changes without having the CI system create an additional commit or run berks update.

Metadata

github/infra/Berkshelf looks like this:

cookbook 'webapp', github: ampledata/webapp

What do you think?

Input is welcome! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment