インフラストラクチャ展開のためのテスト駆動開発？
私はインフラストラクチャのデプロイにpuppetを使用してきましたが、私が行う作業のほとんどは、Webアプリケーションのテスト駆動開発に熱心に取り組んでいるWeb2.0企業との仕事です。ここの誰かがサーバー構成を開発するためにテスト駆動アプローチを使用していますか？これを行うためにどのツールを使用しますか？テストはどのくらい深くなりますか？
テスト駆動開発を使用できるとは思いません。しかし、新しいサーバーでnit-testingを試すことはできます。
基本的には、サーバーを展開し、テストモードでサービスを起動してから、別のサーバー（または一連のサーバー）からサービスに対してテストを実行する必要があります。そしてついにそれらを生産に移しました。
たぶんpythonスクリプトを使用して、データベース、Webページ、およびsshサービスに接続します。次にPASS/FAILを返します。これはあなたにとって良いスタートです。
または、これをZenoss、Nagios、Muninなどの監視ソリューションにロールアップすることもできます。次に、展開中にテストできます。そして、生産中に監視します。
次のリンクが興味深いと思います
cucumber-nagios Cucumber スイートをNagiosプラグインに変換し、SSH、DNS、Ping、AMQP、および一般的な「コマンド実行」タイプのタスクのステップ定義が付属するプロジェクト
http://auxesis.github.com/cucumber-nagios/
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagiosPuppet/Python側にもいくつかの努力があります http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php
Puppetマニフェストを使用してTDDを実行することはまだできていませんが、テストなしで変更が本番環境に移行するのを防ぐためのかなり良いサイクルがあります。 2つのパペットマスターがセットアップされています。1つは本番パペットマスターで、もう1つは開発パペットマスターです。 Puppetの「環境」を使用して、以下を設定します。
- 開発環境（Puppetマニフェストで作業する人ごとに1つ）
- テスト環境
- 本番環境
私たちのアプリケーション開発者は、開発Puppetmasterの「テスト」環境からPuppet構成を取得する仮想マシンで作業を行います。 Puppetマニフェストを開発するときは、通常、開発プロセス中にテストクライアントとして機能し、個人の開発環境を指すようにVMを設定します。マニフェストに満足したら、アプリケーション開発者がVMの変更を取得するテスト環境にそれらをプッシュします-通常、何かが壊れたときに大声で不平を言います:-)
本番マシンの代表的なサブセットには、noopモードで実行され、テスト環境を指す2番目のパペットがあります。これを使用して、マニフェストが本番環境にプッシュされる前に、マニフェストの潜在的な問題をキャッチします。
変更が通過すると、つまり、アプリケーション開発者のマシンが破損したり、本番マシンの「noop」puppetdプロセスのログに望ましくない出力が生成されたりしないようになったら、新しいマニフェストを本番環境にプッシュします。以前のバージョンに戻すことができるように、ロールバックメカニズムが用意されています。
私は、TDD運用モデルに移行する過程にある環境で働いていました。スクリプトの監視など、これは非常にうまく機能しました。 buildbotを使用してテスト環境をセットアップし、テストを実行しました。この場合、「レガシーコード」の観点からTDDにアプローチします。 TDDでは、「レガシーコード」はテストのない既存のコードです。したがって、最初のテストは失敗せず、正しい（または期待される）操作を定義します。
多くの構成ジョブの場合、最初のステップは、サービスが構成を解析できるかどうかをテストすることです。多くのサービスは、まさにこれを行うためのいくつかの機能を提供します。 Nagiosにはプリフライトモードがあり、cfagentには動作がなく、Apache、Sudo、bind、および他の多くの機能に同様の機能があります。これは基本的に、構成のリントランです。
例としては、Apacheを使用し、異なるパーツに個別の構成ファイルを使用する場合、パーツをテストするだけでなく、異なるhttpd.confファイルを使用してテストマシンで実行するためにそれらをラップすることもできます。次に、テストマシンのWebサーバーが正しい結果を提供することをテストできます。
途中のすべてのステップで、同じ基本パターンに従います。テストを作成し、テストに合格し、行った作業をリファクタリングします。上記のように、このパスをたどる場合、テストは受け入れられたTDDの方法で常に失敗するとは限りません。
リック
ジョセフ・カーンは監視ツールで正しい方向に進んでいると思います。典型的なTDDサイクルは、失敗する新しいテストを作成してから、既存のすべてのテストに合格するようにシステムを更新することです。これはNagiosに簡単に適応できます。失敗したチェックを追加し、サーバーを構成し、すべてのチェックを再実行します。そういえば、私は時々これを正確にやったことがあります。
本当にハードコアになりたい場合は、サーバー構成の関連するすべての側面をチェックするスクリプトを作成するようにしてください。 Nagiosのような監視システムは、それらの一部には関係がない場合があります（たとえば、OSバージョンを「監視」しない場合があります）が、適切に組み合わせることができなかった理由はありません。