[和訳] Sous ChefsとのQ&Aセッション #getchef

本稿は Q&A with the Sous Chefs (2018/7/25) の和訳です。

去る夏、私たちはSous ChefsというChef Cookbookのメンテナが集うコミュニティのメンバーであるDan Webb氏とQ＆Aセッションを行いました。Dan氏はこれまでのChefコミュニティへの貢献と指導力を評価され、2018年のAwesome Community Chefアワードを受賞しました（次の回答は、明確さを考慮し編集および要約しています）。

Sous Chefsとは何ですか？

およそ20～30人のChefユーザから成るグループで、Cookbookのメンテナンス、モダナイズ、更新などを行っています。私たちは、カスタムリソースの利用から、よいREADMEを書くまでに至る、ベストプラクティスに従っています。活動を始めておよそ4年にまります。

どのようなCookbookをメンテナンスしているのですか？

皆さんがご存知かもしれないものとしては、haproxy、 line、 samba、 postgresql、 mongodbなどがすべてSous ChefsによるCookbookです。他にも、先日のChefConfではPostgreSQL Cookbook のバージョン7をリリースしたばかりです。これは、Chefで行える部分をさらに推し進めたものです。すべてのRecipeを完全に廃止し、カスタムリソースに移行しました。Cookbookで当てにできない部分をすべて削除したのです。

Cookbook以外では何をメンテナンスしているのですか？

最近では2つの言語パックをエディタに追加しました。そのうち1つはChef language pack for Atom（Atom用Chef言語パック）です。これは、カスタムリソースとRecipeの両者を書く際に役立つ言語パックで、文法を明確に記憶していなくても、リソースの入力を開始することができます。例えば、file と入力します。すると、Visual Studio Codeのようなドロップダウンリストがポップアップで表示されます。さらにドキュメントを直接参照したい場合はそのリンクを開くことができます。

Sous ChefのメンバーとしてCookbookのリファクタリングなどを行ってきた経験から、お勧めのベストプラクティスを教えてください。

わかりました。もしあなたが、アプリケーションのCookbookを書いているなら、カスタムリソースはとても便利です。きれいなAPIと、あなたとあなたがインストールしようとしているアプリケーションの間の抽象レイヤを、ユーザに提供できるからです。PostgreSQLの事例では、postgresql_databaseと入力し、次にdo/endブロックを入力するだけです。まるでfileリソースに対して行う場合と同じように、多くのプロパティを与えることができます。それをラッパーCookbook内で繰り返すことで、データべ―スを管理することができます。きれいで使いやすい方法です。

また、すべてのヘルパーメソッドをライブラリに抽出しました。つまり、あなたがこれまで見てきたdefという文字列は、ライブラリに行っています。私たちはRSpecでリソースとライブラリをテストしています。なぜならRSpecは平易で枯れたRubyコードだからです。おかげでテストがより簡単に行えます。

私たちはInSpecにかなり力を注いできました。実際、私たちはカスタムリソースと、Cookbookを特定の方法で実行するテスト用Cookbookの組み合わせを作ってきたので、双方に利益があるドキュメントとしてのテスト用Cookbookをユーザに紹介できます。テストとドキュメントはすべて同じ場所に置いてあるのです。そのテストを見た誰もが、何を行っているかを即座に理解することができます。

テストと言えば、他にどのようなツールを使っていますか？ CI（継続的インテグレーション）などですか？

インテグレーションテストでは、Test Kitchenを使ってCookbookをテストしています。そして検証にはInSpecを使います。InSpecは私たちが使用するすべてのCookbookにおけるデファクトスタンダードです。あなたが見てきたBATSテストスイートは、おそらく削除することになると思います。たとえInSpecでまったく同じテストを水面下ですることになるとしても、です。

私たちは非常に多くのCIツールを持っています。現在は、ほとんどすべてのテストにTravis CIを使っています。WindowsにはAppveyorを使っています。Dangerというツールの通知用にCircleCIを使っています。DangerはCookbook内の人為的ミスの検知に役立ちます。例えば、"あなたは400行以上ものコードのPRを作成しましたが本当にそんなに大きな変更を加えていいのですか？" などと聞いてくれます。このような場合、答えはたいてい "いいえ" です。つまり人間が行うものと同じレベルから、ベストプラクティスを構築することを助けてくれるのです。Dangerは、"テストをパスできませんでした" と教えてくれるほどには洗練されていません。教えてくれるのは、"おそらくあなたはそこで変更履歴のエントリを作成したかったのでは？"といったようなことに留まります。リリースしたくなったときに2か月前からの100のコミットを選り分けるよりも、コミットを作成するときに変更履歴を書くほうが簡単です。

Sous Chefsに参加するにはどうしたらよいですか？もっとも助けが必要なものは何ですか？

Sous Chefsウェブサイトには、 "Get Involved（参加しよう）"というセクションがあります。私たちにCookbookを転送したい場合は、専用のセクションがあります。しかし私たちとしては、皆さんには、今ご紹介したことをする前にまず、コミュニティに気軽にご連絡いただきたいと思っています。Chef Community Slackで、Sous Chefsのチャンネルに入ってください。またはGitHubで連絡してください。Sous Chefsではメタプロジェクトがあり、例えば私たちにCookbookを転送することについて相談できる場があります。

私たちは膨大な数のCookbookを抱えており、人員は不足しているためバス因子を減らしたいと考えています。Aaron Kalin、Tim Smith、そして私の3人で、おそらく50％から80％ほどのCookbookをメンテナンスしています。私たち3人は過去にも多くのCookbookを自らメンテナンスしてきた経験があるためです。ほとんどすべてのCookbookについて、もしあなたがメンテナンスしたいものがあれば、私たちはあなたをメンテナとして受け入れます。過去にすべてのCookbookで起きたように、1人に任せたはいいが、忙しくなりすぎて半年後に姿を消してしまうようなメンテナよりも、10人のメンテナを抱え、とても長いリリースプロセスと、どのように進めていくべきかの長い対話を要する方が、ずっといいのです。これこそまさに、Sous Chefsという組織ができた理由なのです。

他に何か、皆さんに知ってほしいことはありますか？

Sous Chefsのウェブサイトが、技術者のための技術者によるサイトでなくなるように、グラフィックデザイナーの参加もお待ちしています。私にはデザインの血が流れていないものですから。ウェブサイトをご覧になって、UI担当者を手助けしてくれる人がいらっしゃればとてもありがたいです。