Skip to content

Instantly share code, notes, and snippets.

@dougireton
Last active February 7, 2017 16:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dougireton/48e7bc95767f17c1a1e6 to your computer and use it in GitHub Desktop.
Save dougireton/48e7bc95767f17c1a1e6 to your computer and use it in GitHub Desktop.
We met with an app team today. Here's the advice we gave them on getting started with Chef...
Per our discussion today we have the following recommendations:
1. Pick a single easy server “role” to automate, e.g. my_web_server.
Get that cookbook installing a single package a single Windows Feature, across all of your environments, including Prod.
2. Then rapidly iterate on that cookbook adding features and deploying through all environments, including Prod.
Build a regular habit of code review. Every change should be reviewed by another engineer.
Feel free to include Chef team engineers on Pull Requests.
3. Ideally you start writing simple tests with the cookbook, which our Cookbook Pipeline will execute on every Git push and merge.
4. Once you are pretty happy with the one cookbook, repeat the steps above with a second role,
taking the lessons learned and applying them to the second cookbook.
5. Don’t worry too much about planning out everything in advance.
Chef and Ruby are easy to change and it’s better to make fast forward progress, even if you have to change it later.
Focus on writing small, testable recipes and using composition instead of creating monolithic recipes.
You are really trying to build a habit of small continuous improvement. This is the path to success.
Thanks,
Doug Ireton
Nordstrom Chef team
@MarkGibbons
Copy link

Thanks. I'll use this list.
#2 - Rapid iteration is possible. I've been urging a sane, manageable rate.

@dougireton
Copy link
Author

Glad to see this has been helpful.

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