----
Q&A with the Sous Chefs
// Chef Blog
Chef sat down with Dan Webb of the Sous Chefs organization recently for a Q&A session. Dan is a winner of a 2018 Awesome Community Chef award for all of his contributions and mentorship to the Chef community. (These answers have been edited and condensed for clarity.)
Who are the Sous Chefs?
We're a group of about 20 or 30 Chefs who maintain Chef cookbooks, modernize them, and keep them up to date. We keep to best practices, which could be anything from using custom resources to writing good READMEs. We've been around for about four years.
What are some cookbooks that you maintain?
haproxy, line, samba, postgresql and mongodb are all Sous Chefs cookbooks that you might have heard of. We just released version 7 of the PostgreSQL cookbook at ChefConf, for example. That one really pushed the edges of what Chef can do. We've completely dropped recipes everywhere and moved to custom resources. All the unreliable parts of that cookbook have been removed.
What else do you maintain that aren't cookbooks?
We just brought in two language packs for editors, one of which is the Chef language pack for Atom. It helps you write both custom resources and recipes, so if you don't quite remember the syntax, you can just start typing a resource – say, file – and it will pop up a drop-down list much like Visual Studio Code, and links you to the documentation if you want to go straight there.
Can you talk about some of the best practices that you would recommend as you've on-boarded and refactored cookbooks?
Yes. If you're writing an application cookbook, custom resources are fantastic, as you give the user a good clean API and abstraction layer between you and the application you're installing. In the PostgreSQL example, you just write postgresql_database and then do/end blocks and you give us a bunch of properties as you do for the file resource. You can loop over that in a wrapper cookbook to manage all your databases. It's nice and clean.
We also extract all helper methods into libraries. So if you ever see the word def, that's going in a library. We're now testing resources and libraries with just RSpec because it's just plain old Ruby code. It makes testing much easier.
We've gone pretty hard on InSpec. Actually, because we've got a set of custom resources and a test cookbook that exercise the cookbook in certain ways, we can then point users to the test cookbook for documentation which is a double win there. We've got tests and documentation all in the same place. If anyone ever looks at the tests, it should be easy to spot what's going on.
Speaking of testing, what other tools are you using, say, for continuous integration?
For integration testing we spin the cookbook up with Test Kitchen. Then we use InSpec to verify. InSpec's a standard default across all the cookbooks we use. If you ever see any BATS we'll probably be removing that even if we end up doing the very same thing underneath with InSpec.
We have a plethora of CI tools. Right now, we've got Travis CI for most of the testing. We use Appveyor for Windows. We also use CircleCI for reporting back to a tool called Danger. Danger helps us look for human errors in the cookbook. For example, "Hey, you've made a PR with more than 400 lines of code. Did you really want to make a big change like that?" Usually, the answer is no. It helps develop good practices from a human level as well. Danger isn't as sophisticated as, "Hey, you've missed a test." It's stuff like, "Hey, you probably wanted to make a changelog entry there," and things like that. It's easier to write the changelog when you make the commit rather than having to sift through a hundred commits two months later when you want to release it.
How can people get involved with Sous Chefs? What do you most need help with?
There's a big "Get Involved" section on the Sous Chefs website. If you're interested in transferring a cookbook to us, there's a section about that. We really like people to engage with the community first of all, before doing any of these things. Either pop into the Sous Chefs channel on Chef Community Slack, or you can also talk with us on GitHub. There's a meta project on Sous Chefs where you can discuss transferring cookbooks to us for example.
We have a ton of cookbooks and less active people than cookbooks, so we'd like to reduce the bus factor. I think between Aaron Kalin, Tim Smith, and myself, we probably maintain 50% to maybe 80% of the cookbooks, mostly because we have historically maintained a lot of cookbooks ourselves anyway. Pretty much any cookbook you want to help maintain, we will take you in as a maintainer. I would rather have ten maintainers and have a very long release process and many conversations about how to do things than have one person who disappears for six months as they get busy, which is historically what happened with all of these cookbooks. That's what Sous Chefs the organization is designed to avoid actually.
Is there anything that I didn't ask you that you want people to know?
We can use some graphic designers, so our Sous Chefs website doesn't look like it was designed by engineers for engineers. I have no design blood flowing in my body, so if anyone's looking at the website we would appreciate you asking a UI person to come along & help out.
The post Q&A with the Sous Chefs appeared first on Chef Blog.
----
Read in my feedly
No comments:
Post a Comment