コードおよびTDDとしてのインフラストラクチャ
コードとしてのインフラストラクチャは、ビルドを自動化するツールを使用するように指示します。すごい。ansible、chef、puppet、salt stackなどのツールは、違いを解決しながら、インフラストラクチャがどのように見えるかを書くように私たちを促しています。 ソルトスタックでは、これらのビットは状態と呼ばれます。状態が現実と一致しない場合、ツールはそれを解決します。つまり、インフラストラクチャのテストを作成しており、テストが失敗した場合は、ツールが独自に修正します。少なくともそれは考えです。 XPはTDDの使用を教えてくれますが、問題はそれがインフラストラクチャに適用可能かどうかです。ツールはそれを示唆しています。 非常に役立つテストの種類はほとんど想像できません。 デプロイされたサービスにバンドルされているスモークテストを記述して、デプロイされたサービスが期待どおりに機能し、実行されることを確認します。これは、API呼び出しまたは/およびsystemctlチェックで、デプロイしたばかりのものが機能することを確認します。ansibleのようなツールには、サービスが実行されていることを確認するための状態があるため、この機能の多くは同じ状態でカバーできます。 dockerまたは別の一時的な仮想化エンジンに対して（ansibleがその状態を呼び出すときに）個々のロールを実行できるプロジェクトMoleculeがあります。これにより、役割の分離が強制され、作業中にプレイブックから分離して実行することができます。テストでは、ほとんどの場合、ロールが機能するはずの変数をモックできます。他の例は、ansibleエンジンの複製のように見えます（ファイルがユーザーに属していることをアサートします...）。 ThoughtWorksのハイテクレーダーは、今のようなツール賞賛INSPEC、serverspecやゴスをサーバーが仕様を満たしていることを検証するため。しかし、私たちはスペックを書いていますね？ インフラストラクチャを州/役割で説明している場合、インフラストラクチャをさらにテストすることに意味がありますか？これは、1つのチームが仕様を提供し、他のチームが従う大規模な組織でより必要になるか、または役割の大きなセットがある場合、それらのサブセットを実行してテストから速度のメリットを得たいと思うかもしれません。同じ質問に対する役割/状態が考えられるのに、なぜテストを書くのかを理解するのに苦労しています。