masterの更新フィードとCircieCIでOSS用プラグインの結合テストを回しつづける - Qiita
プラグイン機構をそなえて、機能を追加しやすくするOSSがある。わかりやすいのはfluentdあたりだろうか。 で、何かのプラグインを作っており、かつ現役でしっかり使っているなら、元のプロダクト(コア)の更新時には自動で結合テストをしておくとよいという話。 プラグイン自体は単体テストをやってても、コア側に非互換の変更が入ったり、リファクタリングで機能に退行があると、結局バージョンアップ時に寝耳に水のようなエラーに会う。 結合テストを常にmasterのHEADで回しておくとコア側のアップデートを追いやすいし、もしかするとコア側でも『この変更で、既存プラグインは大丈夫だろうか(※)？』という不安が減るかもしれない。 ※ そういう心配をするとこならある程度プラグイン用のテストも用意してくれていたりするが しくみ 定期的に実行でもまあ悪くないけど、できれば細かい単位で回しておきたい。 サンプルとして
Mackerelでsensuのメトリクスを送る、rvmで専用gemset。 - Qiita
この記事は最終更新から1年以上経過しています。 気をつけてね。 @matsumotoryがMackerelを申し込み、inviteされたのでエージェントを入れてみた。 【ベータテスター募集中】Mackerel: 新しいアプリケーションパフォーマンスマネジメント Mackerel-Agentの設定ファイルを見るとsensu形式の出力も送信できるとなっていたのでやってみた。 -- snip -- # Configuration for Sensu Plugins # Sensu checks (ref. http://sensuapp.org/docs/0.12/adding_a_check) # Currently, metric type command can be used # [sensu.checks.vmstat] # command = "ruby /etc/sensu/plu
ChefのReport, Exeptionハンドラを使う - Qiita
この記事は最終更新から1年以上経過しています。 気をつけてね。 Chefのクライアント(ChefSolo/ChefClient)を実行して、締めの処理をなにかしら行いたい。 詳細はこちら。 Chef Docs: About Exception and Report Handlers 2つのハンドラ exception handler: 例外発生がトリガ report handler: 正常終了がトリガ Chef_runの実行結果によって、このどちらか一方のみトリガされます。 同じ物を指定するのも構いません。 ハンドラ仕様 ハンドラについてはこんな感じです。 Chef::Handlerを継承したクラス reportメソッドを持つ run_statusを持っているので中身を適当に処理 トリガ原因がexceptionでもreportでも、reportメソッドが実行されます。 サンプルハンドラ で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
