fbpx

[和訳] 静的解析: Cookbook の質と一貫性の改善 #getchef

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は Static Analysis: Improving the quality and consistency of your cookbooks (2015/11/20) の和訳です。

私たちは Cookbook を変更する度に、何らかの間違いを混入してしまいます。そのリスクを減らすためにはそもそも変更しないか、さもなければ、そのリスクにうまく対処するために、lint やテストといった新しい実践手法を取り入れることができます。

lint ツールは、私たちが書くコードが一貫性、ポータビリティを保証する規定を遵守し、ベストプラクティスの実施を保証するための自動化された方法を提供します。これは、チーム全員が同様の構造化したコードを書くことを保証します。それは時間と共に、コードの発展に寄与し、協力体制を促進していきます。ソースコードの一貫性を保証することは、プロジェクトの貢献者のためになるでしょう。

2015年11月4日に開催したオンラインセミナーでは、録画の 21:45 で Foodcritic と Rubocop にフォーカスしています。これらは Chef Development Kit (ChefDK) に同梱の lint ツールなので、開発している Cookbook のリスク軽減にすぐ使うことができます。オンラインセミナーでの質疑応答、またその場でお答えする時間のなかった質問も含めて、次の録画からご覧いただけます。

  • Foodcritic の紹介 (10:00)
  • Rubocop の紹介 (21:45)
  • ツールのデモ (30:45)

Q: デリバリーパイプラインの間で pass/fail を検出するために、これらのコード分析ツールを Jenkins へ統合することは容易でしょうか?

A: Foodcritic と Rubocop を Jenkins または組織内のいかなる継続的インテグレーション(CI)ツールと統合することは大変容易ですので、強く推奨します。過去に Foodcritic と Rubocop の両方をコマンドラインからローカルで実行するような新しいビルドステップを単純に追加し、コードの最新バージョンを同期した後に実行するようにしていました。

中央システムでこれらのツールを実行する利点は、チームの全員が書くコードが全員で定義したポリシーに確実に遵守させるということです。中央システムがなければ、個々のチームメンバーによって実行されなかったり、結果が個々のマシンによって変わってしまうでしょう。

A: 現在、Foodcritic と Rubocop の両方の lint ツールは警告として使用していますが、変更の可能性がないレガシーコードを除いて、いくつかのコードは実際にビルドが失敗となるよう設定する予定があります。除外するための最良の方法は何でしょうか? Cookbook 中の .rubocop.yml ファイルと .foodcritic でしょうか?

Q: はい。それぞれの Cookbook は、適用したいルールとそうでないルールを設定できるファイルの両方を持っているはずです。

Q: Data Bag を lint するために Foodcritic と Rubocop を使うべき、あるいは使うことが可能なのでしょうか?

A: Data Bag はローカルファイルシステムに JSON として記憶されています。Chef Server にそれらの Data Bag をアップロードするために knife を使用するとき、knife ツールが正確性のためにデータの検証を行うでしょう。

しかしながら、内容を更新した Data Bag を Chef Server にアップロードする際、ただちに knife が使用されないかもしれません。

ワークフローが、

  1. JSON を変更する
  2. ソースコードレポジトリに変更をコミットする
  3. 中央のコードレポジトリに変更をプッシュする
  4. 継続的インテグレーション(CI)環境がそれらの変更を読み取り、Chef Server にそれらをアップロードするかどうかを決定する

ということとします。この環境において、CI システムに提出する前に、ローカルマシンで JSON を検証するツールを持つことは大変有用です。こちらは急ぎで見つけたコマンドラインから JSON を検証することのできるいくつかのツールです:

Ruby または JSON サポートを持つ他のプログラミング言語を使えることも覚えておいてください。単純に正しく読み込むことを保証するためには、すべての JSON ファイルを読み込んでみるスクリプトを書いてみてください。これ は Ruby で行っている一例です。

Q: Foodcritic と Rubocop 用の Atom テキストエディタの linter パッケージを使ってみましたか? 役に立ちますか?

A: 最近、Atom をフルタイムのエディターとして使うようにしてみました。というのも、これらのツールが一番の理由の一つでした。Atom は、これらのツールの両方のプラグインをサポートしています。

以前、重大な開発をしていた時は、Guard というすべてのファイル保存に関して、バックグラウンドでファイルを監視する Ruby ツールを使っていました。

Q: Atom テキストエディタの lint パッケージの質問と同様に、Chef と Chef の lint に RubyMine を使ってみましたか?

A: 私は JetBrains の大ファンです。以前 C# を使った仕事をしていた時、ワークフローを促進するために ReSharper を使っていました。RubyMine は、いくつかの並外れた特徴を持っている、Ruby の最も洗練された統合開発環境 (IDE) です。

Q: Chef 社は Test Kitchen やこれらの lint ツールを基にしたトレーニングを行っていますか?

A: 新しい Chef Essentials Training では、Test Kitchen を使ったデモをしています。

Q: 複数の Cookbook に対してすべての人が同意する .rubocop ルールを得るためのプロセスはどのようになりますか?

A: 私の通常のプロセスは、1つの Cookbook とその最初の .rubocop ファイルを定義することを含んでいます。まずはほとんどの Recipe、ヘルパー、テストなどを持っている最も大きな Cookbook をターゲットにします。それぞれのファイルに対して Rubocop を実行し、チームが同意する変更に修正し、設定ファイルに適用したくないルールを追加します。

それぞれの Cookbook に完全なファイルを配布する方法は、すべての Cookbook のための単一の Chef-Repo を使っているか、Cookbook ごとに 1つのレポジトリを使っているかに依存します。

すべて含む単一のレポジトリならば、Chef-Repo のルートディレクトリに に.rubocop ファイルを置くだけでよいでしょう。Rubocop は現在のディレクトリで設定ファイルを探し、そして見つかるまでディレクトリを上がっていきます。

現在、1 Cookbook / 1 レポジトリでも同じことができます。親ディレクトリにファイルを保存し、別のコードレポジトリを通してチームの各メンバーに配布します。もっとも、私はしばしば私たちが維持するすべての Cookbook にこのファイルを追加しています。

Cookbook を作成する度にこの設定ファイルをコピーすることを回避する一つの方法は、Chef Development Kit (ChefDK)に含まれているジェネレータツールを利用することです。望ましい共通の設定ファイルをすべて含んでいる Cookbook を自動的に生成するためのテンプレートを設定することができます。

Q: Foodcritic は、特定の著作権の宣言文や他の企業の特定の習慣を強いるようなことを支援するのでしょうか? それとも、そのような機能性を調べるためのより良いツールがあるのでしょうか?

A: Foodcritic はデフォルトでは行いません。しかしながら、Foodcritic はあなた自身のルールを生成する能力を提供します。ウェブサイトで例をご覧になることができます。

Rubocop はルールを定義し、コード、名前、タグを与え、何のファイルを調査し、それぞれのコードの行を調査するときに何をするかを許可する ドメイン固有言語(DSL)を提供します。特別な Ruby のプログラミングスキルは必要ありません。

Q: ウェブセミナー中に使用されたターミナルプロンプトは何でしたか?

A. 私の Mac では、Powerline Patched Fonts の Agnoster Theme と iTerm2 を使用しています。

新規CTA