インフラストラクチャ展開のテスト駆動開発？

私は、インフラストラクチャの展開にpuppetを使用してきましたが、私が行う作業のほとんどは、Webアプリケーションのテスト駆動開発に熱心なWeb 2.0企業での作業です。サーバー構成の開発にテスト主導のアプローチを使用している人はいますか？これを行うためにどのツールを使用しますか？テストの深さは？

テスト駆動開発を使用できるとは思わない。ただし、新しいサーバーで単体テストを試してみることもできます。

基本的に、サーバーを展開し、サービスをテストモードで起動してから、別のサーバー（または一連のサーバー）からサービスに対してテストを実行する必要があります。その後、最終的にそれらを実稼働に投入します。

たぶん、Pythonスクリプトを使用してデータベース、Webページ、およびsshサービスに接続します。そして、PASS / FAILを返します。あなたにとって良いスタートになるでしょう。

または、これをZenoss、Nagios、Muninなどの監視ソリューションにロールアップすることもできます。その後、展開中にテストできます。生産中に監視します。

ジョセフ・カーンは監視ツールに関して正しい軌道に乗っていると思います。典型的なTDDサイクルは次のとおりです。失敗する新しいテストを作成し、既存のすべてのテストに合格するようにシステムを更新します。これは、Nagiosに簡単に適応できます。失敗したチェックを追加し、サーバーを構成し、すべてのチェックを再実行します。考えてみると、私は時々これを正確に行いました。

本当にハードコアを取得したい場合は、サーバー構成の関連するすべての側面をチェックするスクリプトを作成してください。Nagiosのような監視システムは、それらの一部に関連しない場合があります（たとえば、OSバージョンを「監視」しない場合があります）が、必要に応じて組み合わせることができない理由はありません。

私はまだPuppetマニフェストでTDDを行うことができませんでしたが、テストを行わずに変更が実稼働に入るのを防ぐためのかなり良いサイクルがあります。2つの操り人形マスターが設定されています。1つは本番操り人形マスターで、もう1つは開発操り人形マスターです。Puppetの「環境」を使用して、以下を設定します。

• 開発環境（Puppetマニフェストで作業する人ごとに1つ）
• テスト環境
• 本番環境

アプリケーション開発者は、開発Puppetmasterの「テスト」環境からPuppet構成を取得する仮想マシンで作業を行います。Puppetマニフェストを開発するとき、通常、開発プロセス中にテストクライアントとして機能するようにVMをセットアップし、それを個人開発環境に向けます。マニフェストに満足したら、アプリケーション開発者がVMの変更を取得するテスト環境にプッシュします。通常、何かが壊れると大声で文句を言います:-)

実稼働マシンの代表的なサブセットには、noopモードで実行され、テスト環境を指す2番目のpuppetdがあります。これを使用して、マニフェストがプロダクションにプッシュされる前に潜在的な問題をキャッチします。

変更が渡されると、つまり、アプリケーション開発者のマシンを破壊せず、本番マシンの「noop」puppetdプロセスのログに望ましくない出力を生成しない場合、新しいマニフェストを本番にプッシュします。ロールバックメカニズムが用意されているため、以前のバージョンに戻すことができます。

私は、TDD運用モデルへの移行プロセス中の環境で働いていました。監視スクリプトなどのいくつかの場合、これは非常にうまく機能しました。buildbotを使用してテスト環境をセットアップし、テストを実行しました。この場合、「レガシーコード」の観点からTDDにアプローチします。TDDでは、「レガシーコード」はテストのない既存のコードです。したがって、最初のテストは失敗せず、正しい（または予想される）操作を定義します。

多くの構成ジョブの最初のステップは、サービスが構成を解析できるかどうかをテストすることです。多くのサービスは、これを行うための機能を提供します。Nagiosにはプリフライトモードがあり、cfagentにはact、apache、sudo、bindがなく、他の多くには同様の機能があります。これは基本的に、構成のlint実行です。

たとえば、異なるパーツにapacheと個別の構成ファイルを使用する場合、パーツをテストするだけでなく、テストマシンで実行するために異なるhttpd.confファイルを使用することもできます。次に、テストマシン上のWebサーバーが正しい結果を提供することをテストできます。

あなたが同じ基本パターンに従う方法に沿ったすべてのステップ。テストを書き、テストに合格し、行った作業をリファクタリングします。前述のように、このパスをたどると、受け入れられたTDD方式でテストが常に失敗するとは限りません。

リック

次のリンクが興味があると思う

1. 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-nagios

2. http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.phpの物事のPuppet / Python側にもいくつかの努力があり ます。